www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik iMX6 Board neu entwickeln


Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Hallo zusammen

Ich habe hier: Beitrag "Suche SoC wie auf dem Raspberry Pi"
Nach einem SoC gefragt.

Nach langem Überlegen, ist es wohl das sinnvollste, ein eigenes Board 
auf basis eines iMX6 zu erstellen.

Folgende Gründe sprechen für mich dafür:

- Lerneffekt
- Niedrigere Kosten als ein RaspberryPi Compute modul
- Flexibilität bei der Hardware

Da ich bisher noch nie ein Design (Schema) mit einem Prozessor entworfen 
habe, hätte ich dazu aber einige Fragen.

Um bereits den Wind aus den Segeln zu nehmen, die Layoutanforderungen 
sind klar und da ist Erfahrung vorhanden. Die unbekannte ist das Schema, 
und da kann ein Forum vermutlich helfen.

Nun denn...

Folgende Punkte sind für mich offen:

Ich habe mich mal für einen iMX6 ULL entschieden, da es in erster Linie 
darum geht, erfahrungen zu Sammeln und sich mit der Thematik vertraut zu 
machen. Die Applikation welche dann auf Linux laufen wird, ist nicht 
wirklich anspruchsvoll.

http://www.nxp.com/products/microcontrollers-and-p...

MPN: MCIMX6Y2DVM05AA

Laut der Webseite von NXP steht da bei Memory:
    16-bit LP-DDR2, DDR3/DDR3L
    8/16-bit Parallel NOR FLASH / PSRAM
    Dual-channel Quad-SPI NOR FLASH
    8-bit Raw NAND FLASH with 40-bit ECC

Wie wähle ich ein passendes Flash aus?
Ich habe mir mal dieses hier ausgesucht:

MPN: IS43TR16128B-125KBL, DDR3 2G, 1.5V, 1600MT/s 128Mx16 DDR3 SDRAM
Datasheet: 
http://www.mouser.com/ds/2/198/43-46TR16128B-82560...

Meiner Meinung nach müsste dieses passen. Was gibts zu beachten?


Ich möchte dass das Grundsystem auf einem On-Board Flash liegt.
Dazu habe ich mit folgenden NAND Speicher gesucht:

MPN: S34ML02G100TFI000, Flash-Speicher 2Gb 3V 25ns NAND Flash
Datasheet: 
http://www.mouser.com/ds/2/100/002-00676_S34ML01G1...

Ist ein NAND mit 8bit Datenbus. Aus meiner sicht passt dieses an den 
iMX6
Was gibt es hier zu beachten?

Alle anderen Dinge sind denke ich ziemlich gut mit dem Hardware Guide 
von NXP abgedeckt was ich auf den ersten Blick gesehen habe:

http://www.nxp.com/assets/documents/data/en/user-g...

Daher vermute ich mal, dass dies die beiden grössten Knackpunkte sind.



Es gibt ja ein BoardSupportPackage (BSP) von NXP für die iMX6.
Mit Yocto kann man ja offenbar sein eigenes LinuxImage erstellen.
Ist dies zwingend notwendig? Oder in welchem Fall ist dies notwendig?

Bisher habe ich noch nicht sehr viel Erfahrung in Bezug auf Linux.
Habe mir ein gutes Buch gekauft und auch die relevanten Punkte gelesen.
Wenn ich das richtig verstehe ist am Anfang nach dem iMX Bootloader der 
u-Boot welcher den Linux kernel startet.

Genügt es, wenn ich den uBoot anpasse um mein eigenes Board zu 
supporten?

Wie viel Speicher benötigt ein Grundsystem in etwa?
Ich würden den Speicher dann mit einem USB Stick als Hauptlaufwerk 
erweitern. Daher auf dem 128MB NAND wäre nur das Grundsystem.

Fragen über fragen. Ich hoffe jemand kann die eine oder andere 
beantworten.

Danke eure Krähe.

Autor: Herr Rausforderung (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Das ist ein ganzschön großer Schuh, den Du dir da anziehen willst. Aber 
das Hobby wäre ja nix, wenn es nicht auch eine Herausforderung wäre.

Schau dir mal dieses Board an:

http://wandboard.org/

Dort sind auch Schaltpläne und Co verfügbar. Davon kann man sich ja mal 
inspirieren lassen.

Autor: Wolfgang R. (mikemcbike)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Machst Du die impedanzoptimierten differentiellen Leiterbahnen für das 
DDR3 mit Eagle? Respekt!

Autor: Frank K. (fchk)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nimm kein NAND-Flash, wenn es keine guten Gründe dafür gibt, sondern 
eMMC oder µSD-Karten. Die Fehlerkorrektur bei NAND ist etwas, womit Du 
Dich nicht beschäftigen möchtest, vor allem wenn das Board gerade zu 
leben beginnt.

EMMC ist standardisiert, da kannst Du alles nehmen. Das ist quasi eine 
aufgelötete SD-Karte mit doppelter Datenbusbreite plus einigen anderen 
Extras wie separate Bootbereiche (ab EMMC 4.3) und minus dem ganzen 
DRM-Krempel.

Wenn Du mit SD-Karten arbeitest, dann nimm ein SPI-NOR-Flash fürs UBoot. 
Das macht das Handling nachher einfacher, weil Du dann nicht auf jedes 
Bootmedium den UBoot draufpraktizieren musst, sondern die Karten einfach 
nur am PC formatieren und befüllen brauchst. SPI-NOR-Flash gibts bis 
32MB, und da passt auch ein kleines Rettungssystem mit rein.

fchk

Autor: No Y. (noy)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Und günstiger wird es nie im Leben...
Kauf dir eines der vielen iMX6ULL Module...
Glaub mir du willst nicht Sachen machen wo in Firmen ganze Teams HW  
SW dran sitzen...

Zu Inspirationszwecken:
http://www.phytec.de/produkt/system-on-modules/phy...

Autor: Dergute Weka (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> Nimm kein NAND-Flash,

Frank K. schrieb:
> Wenn Du mit SD-Karten arbeitest, dann nimm ein SPI-NOR-Flash fürs UBoot.
> Das macht das Handling nachher einfacher, weil Du dann nicht auf jedes
> Bootmedium den UBoot draufpraktizieren musst, sondern die Karten einfach
> nur am PC formatieren und befüllen brauchst. SPI-NOR-Flash gibts bis
> 32MB, und da passt auch ein kleines Rettungssystem mit rein.

Seh' ich auch so. SPI fuers U-Boot, SD-Card fuer rootfs. Dann ist man 
recht flexibel.

Holger K. schrieb:
> Genügt es, wenn ich den uBoot anpasse um mein eigenes Board zu
> supporten?

Den Kernel wohl auch. Oder du musst irgendein Board so dermassen 1:1 
nachbauen, dass es voellig sinnlos wird.

Gruss
WK

Autor: No Y. (noy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
Und Linux Treiberanpassungen usw. sind auch nicht mal so eben über ein 
Buch zu erlernen..
Vielleicht die Devicetree Anpassung  aber alles danach wird schon 
aufwändig...
Kauf dir ein Modul und mach erstmal dein "Basisboard" da hast du erstmal 
genug zu tun und kannst BSP Anpassung üben und das Grundsystem sollte 
vom Supplier angeboten werden und laufen.
Wenn das geht, kannst du immernoch dir vornehmen das Modul zu 
ersetzten...

: Bearbeitet durch User
Autor: rk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Genügt es, wenn ich den uBoot anpasse um mein eigenes Board zu
> supporten?
Neben der uBoot-Anpassung ist ein eigener Kernel-Device Tree fällig. 
Klingt aber komplizierter als es ist.
Der Einstieg in die Yocto-Geschichte ist etwas holprig, aber wenn man's 
mal raus hat, klappt's recht gut.



Wolfgang R. schrieb:
> Machst Du die impedanzoptimierten differentiellen Leiterbahnen für das
> DDR3 mit Eagle? Respekt!

Geht alles - so ein Board liegt hier neben mir. i.MX6DL mit 64-bit DDR3 
neben einem FPGA mit 128-bit DDR3 auf 10 Lagen mit Eagle 6 erstellt. 
Dazu noch ein PCIe Gen2 dazwischen und diverse andere Signale > 
5Gbit/s...
Funktioniert bestens, der Umstieg auf OrCAD ist dennoch im Gange ;-)

Ausserdem ist hier die Rede von 16-bit DDR3, also nur Punkt-zu-Punkt 
Verbindungen zu einem einzigen RAM Baustein.

Autor: rk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Mich würde interessieren, wie viele hier so etwas schonmal 
probiert haben, bevor sie "geht nicht" sagen. Irgendwann ist immer das 
erste Mal...
Klar ist das Vorhaben nicht einfach, aber eben auch nicht unmöglich.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Herr Rausforderung schrieb:
> http://wandboard.org/
>
> Dort sind auch Schaltpläne und Co verfügbar. Davon kann man sich ja mal
> inspirieren lassen.

Vielen Dank, werde ich mir anschauen.

Wolfgang R. schrieb:
> Machst Du die impedanzoptimierten differentiellen Leiterbahnen für das
> DDR3 mit Eagle? Respekt!

Nein, ganz bestimmt nicht! Wobei dies durchaus machbar wäre mit dem 
richtigen Raster. Wir verwenden Altium auf der Arbeit. Ich bin Layouter 
von Beruf und habe bereits viel anspruchsvollere Boards gelayoutet.

Layouten, kein Problem. Aber Schaltung entwickeln, bisher noch nicht.

Frank K. schrieb:
> Nimm kein NAND-Flash

Guten Hinweis Danke!

Frank K. schrieb:
> Wenn Du mit SD-Karten arbeitest, dann nimm ein SPI-NOR-Flash fürs UBoot.
> Das macht das Handling nachher einfacher, weil Du dann nicht auf jedes
> Bootmedium den UBoot draufpraktizieren musst, sondern die Karten einfach
> nur am PC formatieren und befüllen brauchst.

Perfekt, so habe ich mir das vorgestellt!

No Y. schrieb:
> Und günstiger wird es nie im Leben...

Wenn man die Zeit nicht Rechnet dann schon.
Bestückung geht auf eigener Linie.

No Y. schrieb:
> Zu Inspirationszwecken:
> 
http://www.phytec.de/produkt/system-on-modules/phy...

Gefällt mir, Danke!

Dergute W. schrieb:
> Den Kernel wohl auch. Oder du musst irgendein Board so dermassen 1:1
> nachbauen, dass es voellig sinnlos wird.

Gut, also muss ich doch mit Yocto ein Image compilieren?
So ganz den Durchblick was die Software anbelangt habe ich noch nicht 
ganz.

No Y. schrieb:
> Und Linux Treiberanpassungen usw. sind auch nicht mal so eben über ein
> Buch zu erlernen..

In dem Buch von mir gibt es zwar einen Abschnitt genau darüber.
Natürlich nicht bis ins letzte Detail aber man bekommt ein Gefühl dafür.



Bezüglich Software.

Vielleicht bin ich ja einfach zu doof um es zu verstehen aber...
Ich brauche doch einen Linux Kernel welcher meinen Prozessor unterstützt 
also Cortex A7. Den gibts ja bereits.

Mit uBoot lasse ich den Kernel starten. Zudem kennt uBoot meine 
Speicher.

Nun... Treiber... Was für Treiber soll ich denn benötigen?
z.B. für Ethernet. Ein Treiber für einen BroadCom WLAN gibt es doch 
bereits. Den müsste man dann wohl im schlimmsten Fall neu Compilieren.
Aber für die meiste Hardware gibts es doch bereits Treiber.
Oder übersehe ich da etwas?

Danke

: Bearbeitet durch User
Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
rk schrieb:
> Neben der uBoot-Anpassung ist ein eigener Kernel-Device Tree fällig.
> Klingt aber komplizierter als es ist.
> Der Einstieg in die Yocto-Geschichte ist etwas holprig, aber wenn man's
> mal raus hat, klappt's recht gut.

Danke für deinen Input.
Gibt es alternativen zu Yocto? Ich habe mich da noch nicht festgelegt.
Yocto habe ich einfach immer mal wieder im Zusammenhang mit iMX6 
gelesen.
Habe aber gesehen dass die erzeugung der Patchfiles mittels GIT doch 
etwas "umständlich" sind.

Was ist der "reguläre" weg?


Gerne würde ich den Weg von der IDEE bis zum Board später irgendwo 
festhalten damit auch andere davon profitieren können.

: Bearbeitet durch User
Autor: Dergute Weka (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Holger K. schrieb:
> Oder übersehe ich da etwas?

Naja, prinzipiell kann's auch vielleicht mit irgendeinem Kernel von der 
Stange klappen. Es sind halt so Sachen wie z.B.:
* mit welchem UART auf welchen Pins kommt die Konsole raus
* an welchen Pins haengen irgendwelche LEDs, die den Bootfortschritt 
visualisieren koennen?
* Was haengt da fuer ein Ethernet-PHY dran, wie sind da die LEDs in der 
Netzwerkbuchse verdrahtet, was sollen die anzeigen?
* Wie ist das SPI-Flash partitioniert? - wenn das der Kernel weiss, kann 
u-boot leichter upgedatet werden, man kann in dem SPI ein Notfall rootfs 
reinbauen; irgendwelche Softwarelizenzen zum Freischalten von Featueres, 
etc.
* Wie laeuft das mit der dyn. Einstellung der Corespannung; ist da der 
richtige Spannungswandler drauf, der dann mit dem Kernel 
zusammenarbeiten kann?

Ob man jetzt yocto, buildroot, oder yet-another-sau-durchs-dorf 
hernimmt: Eigentlich egal, man sollte wissen, was da im Hintergrund 
passiert. Denn diese ganze Crosscompilier-Scriptshice fliegt einem immer 
mal um die Ohren wenn man's nicht brauchen kann.

Gruss
WK

Autor: Don Kanaille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> - Niedrigere Kosten als ein RaspberryPi Compute modul


Auch wenn der Rest möglich sein dürfte - niedrigerer Preis wirst Du kaum 
schaffen - ich geh mal von Stückzahlen < 30 aus. Auch nicht mit eigener 
Bestückung (ganz Umsonst?! Maschinenzeit und Schablonen kosten auch. OK 
falls nicht ausgelastet...) und ohne Arbeitszeit zu rechnen, die 
Bauteile in kleinen Stückzahlen sind nicht so günstig wie man meinen 
mag.
Da kommt man sehr sehr schnell auf 30 Euro.


Und ja ich habe schonmal ein Board mit einer ähnlichen CPU in kleinen 
Stückzahlen gemacht (auf Details kann ich nicht eingehen da es beruflich 
war).

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Naja, prinzipiell kann's auch vielleicht mit irgendeinem Kernel von der
> Stange klappen. Es sind halt so Sachen wie z.B.:
> * mit welchem UART auf welchen Pins kommt die Konsole raus....

Danke für deine Antwort.
Das sind in der Tat Dinge, mit welchen ich mich noch nicht beschäftigt 
habe.

Dergute W. schrieb:
> Ob man jetzt yocto, buildroot, oder yet-another-sau-durchs-dorf
> hernimmt: Eigentlich egal, man sollte wissen, was da im Hintergrund
> passiert.

Das kann ich gut nachvolziehen.
Habe gestern mit buildroot ein rootfs inkl u-boot für den Raspberry Pi B 
erstellt. Buildroot unter Ubuntu.

Dergute W. schrieb:
> Denn diese ganze Crosscompilier-Scriptshice fliegt einem immer
> mal um die Ohren wenn man's nicht brauchen kann.

Und dann blieb der Buildprozess immer an einem bestimmten ort hängen.
Die Meldung war "no recipe for oldconfig". Nach ein paar Stunden Google 
etc dann der kleine aber feine Hinweis. Man sollte bei u-boot als Board 
Name "rpi" eingeben. Aus meiner Sicht war das einfach irgendein 
wählbarer String. Scheinbar nicht.

Also ich werde langsam Warm mit der Geschichte.
Nun muss ich noch herausfinden, wo genau z.B. die Treiber für die GPU 
abgespeichert sind, bzw wo diese zum rootfs / kernel hinzukommen, so 
dass ich die Treiber später für imx auch selbst anpassen kann.

Don Kanaille schrieb:
> Auch wenn der Rest möglich sein dürfte - niedrigerer Preis wirst Du kaum
> schaffen

Also rechnen wir mal überschlagsmässig.

Don Kanaille schrieb:
> ich geh mal von Stückzahlen < 30

Eher 100+

Don Kanaille schrieb:
> Auch nicht mit eigener
> Bestückung (ganz Umsonst?!)

Ja ist umsonst. Die Maschine ist abgeschrieben.

Don Kanaille schrieb:
> Schablonen kosten auch

18 USD pro Schablone. Es wird nur eine benötigt.
Also kurze Kostenrechnung, nur ganz Grob.

- CPU 5 EUR
- NOR Flash für uboot und minimal rootfs 3 EUR
- RAM 3 EUR
- Speicher SD-Karte (Nicht dabei)
- Speisung 5 EUR
- Vogelfutter 5 EUR
- PCB 2.50 EUR
- Schablone 0.18 EUR
- Paste 0.20 EUR

ca. 24 EUR. Ich gebe zu, ich komme bereits nahe an die 30EUR heran.
Aber dies bei kleinststückzahlen. Immerhin bei 100 Stück ist das bereits 
eine Ersparnis von etwa 600 EUR

: Bearbeitet durch User
Autor: Dergute Weka (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Bau unbedingt Ethernet (muss nicht unbedingt GBit sein, 10/100 reicht 
auch) dran, das kostet dich dann zwar einen PHY und den MagJack extra 
aber sonst wird das niemals laufen. Die noetigen Wechselzyklen haelt 
sonst kein SD-Kartenslot aus ;-) Musste ja in der Serie nicht mehr 
bestuecken, wenn du schwaebischer Schotte bist. Ueblicherweise hilfts 
bei der Entwicklung enorm, wenn man dem Linux sein rootfs via nfs gibt 
und nicht fuer jeden Furz die SD-Karte raus- und reinklabustern muss.

2.50 fuers PCB klingt ambitioniert, wie gross soll's denn werden und auf 
wieviele Lagen willst du das quetschen?

A propos: Hast du dich schon mal damit beschaeftigt, wie das Board zum 
ersten Mal in seinem Leben bootet, d.h. wenn im NOR-Flash noch kein 
u-boot usw. drinnensteht?
Ueblicherweise haben SoCs ein paar GPIOs, die beim /RESET gesampled 
werden und dann die bootreihenfolge von verschiedenen Devices vorgeben. 
Damit solltest du dich laenglich beschaeftigen.

Bezgl. Buildsystemen: Du siehst, was eben schon beim Bau eines 
"Allerweltssystems" schiefgeht. Wenn das bei deinem Board passiert, dann 
gibts nix zu googlen. Das hat vor dir noch keiner gemacht.

Gruss
WK

Autor: Hurra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe vor kurzem beruflich eins durchziehen müssen.

Ich kann dir sagen:
Generell ist der i.MX6 eine recht gute Wahl, weil er gut dokumentiert 
ist und es gute (komplett offene) Referenzdesigns gibt. Diese 
Sabre-Boards. Da bekommt man sogar die CAD-Daten.

Aber:
Du unterschätzt das Problem massiv. Wir haben hier alleine schon eine 
10-Layer-LP gebraucht. Die kannst du nicht "mal schnell" bei ELECROW 
durchlaufen lassen.
Du wirst auch 0201 benötige, die Kondensatoren unter dem i.MX6 benötigen 
diese Baugröße zwingend. Die KANN man von Hand bestücken, Spasss macht 
es nicht.

Und das Layout ist nicht mehr trivial. Mit Eagle halte ich das für 
unmöglich. Wir haben glücklicherweise eine Layouter-Abteilung hier, mit 
erfahrenen Mitarbeitern und entsprechenden Tools.

Trotz langjähriger Erfahrung mit Impedanzkontrollierten Designs haben 
die lange dran gesessen ;-)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Da ich bisher noch nie ein Design mit einem Prozessor entworfen habe
Ambitioniert, dann gleich mit einem richtigen Boliden zu beginnen. Aber 
man wächst bekanntlich an der Aufgabe.

> Nach langem Überlegen, ist es wohl das sinnvollste, ein eigenes Board
> auf basis eines iMX6 zu erstellen.
Dann ist es logischerweise das Sinnvollste, auf EVAL-Boards des 
Herstellers zu setzen:
http://www.nxp.com/products/microcontrollers-and-p...

> Nach langem Überlegen, ist es wohl das sinnvollste, ein eigenes Board
> auf basis eines iMX6 zu erstellen.
Dann würde ich mal empfehlen, andere Boards genauer anzuschauen. Klar 
kostet das ein paar Tausender und einiges an Zeit, aber die sparst du 
hinterher ja sicher wieder ein.

> Folgende Gründe sprechen für mich dafür:
> - Lerneffekt
> - Niedrigere Kosten als ein RaspberryPi Compute modul
> - Flexibilität bei der Hardware
Wenn du jetzt noch irgendwas von Stückzahlen jenseits der 100k 
geschrieben hättest. In diesem Bereich oder deutlich drüber wirkt (wenn 
man es realistisch betrachtet) dann das "niedrigere 
Kosten"-Argument...

: Bearbeitet durch Moderator
Autor: rk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Naja, prinzipiell kann's auch vielleicht mit irgendeinem Kernel von der
> Stange klappen. Es sind halt so Sachen wie z.B.:
> * mit welchem UART auf welchen Pins kommt die Konsole raus
> * an welchen Pins haengen irgendwelche LEDs, die den Bootfortschritt
> visualisieren koennen?
> ...

Und genau dafür gibt es den Device Tree...


Dergute W. schrieb:
> Bau unbedingt Ethernet (muss nicht unbedingt GBit sein, 10/100 reicht
> auch) dran

Ja.


> aber sonst wird das niemals laufen.

Nein. Was soll eigentlich immer diese Schwarzmalerei?


> Die noetigen Wechselzyklen haelt
> sonst kein SD-Kartenslot aus ;-) Musste ja in der Serie nicht mehr
> bestuecken, wenn du schwaebischer Schotte bist. Ueblicherweise hilfts
> bei der Entwicklung enorm, wenn man dem Linux sein rootfs via nfs gibt
> und nicht fuer jeden Furz die SD-Karte raus- und reinklabustern muss.

Am Anfang muss man ein paar mal die SD-Karte stecken, aber das sollte 
jeder Sockel überleben. Wenn's dann um Softwareentwicklung geht, läuft 
das zwar über's Netzwerk, aber nfs braucht man dafür nicht unbedingt. 
gdbserver und ssh/scp sind vollkommen ausreichend. Nettwerweise liefert 
yocto alles notwendige dafür mit.


Dergute W. schrieb:
> A propos: Hast du dich schon mal damit beschaeftigt, wie das Board zum
> ersten Mal in seinem Leben bootet, d.h. wenn im NOR-Flash noch kein
> u-boot usw. drinnensteht?

Beim i.MX6 geht das recht einfach über USB mit dem mfgtool. Also USB OTG 
oder Device auf dem Board vorsehen.


> Ueblicherweise haben SoCs ein paar GPIOs, die beim /RESET gesampled
> werden und dann die bootreihenfolge von verschiedenen Devices vorgeben.
> Damit solltest du dich laenglich beschaeftigen.

Zustimmung. Aber man kann sich an einem der Reference Designs 
orientieren.


> Bezgl. Buildsystemen: Du siehst, was eben schon beim Bau eines
> "Allerweltssystems" schiefgeht. Wenn das bei deinem Board passiert, dann
> gibts nix zu googlen. Das hat vor dir noch keiner gemacht.

Das Problem bei rpi ist genau, dass es ein Allerweltssystem mit 
miserablem Support ist. Jeder meint Bescheid zu wissen und posaunt das 
in die Welt hinaus, aber echte Unterstützung mit richtig Ahnung gibt es 
kaum.
Beim i.MX6 gibt es die NXP Community, in der Leute mit Ahnung (teilw. 
von NXP selbst) Fragen beantworten.
Im Gegensatz zum Broadcom-SoC beim rpi bekommt man beim i.MX6 auch 
Support vom Hersteller ohne Millionenstückzahlen abzunehmen.


Hurra schrieb:
> Du wirst auch 0201 benötige, die Kondensatoren unter dem i.MX6 benötigen
> diese Baugröße zwingend. Die KANN man von Hand bestücken, Spasss macht
> es nicht.

Nö. Läuft hier wunderbar mit 0402 und 0603. Für große Automotive-Kunden 
gibt/gab es angeblich auch ein Referenzdesign mit 0402, das habe ich 
aber noch nicht zu Gesicht bekommen.

Autor: Hurra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rk schrieb:
> Nö. Läuft hier wunderbar mit 0402 und 0603. Für große Automotive-Kunden
> gibt/gab es angeblich auch ein Referenzdesign mit 0402, das habe ich
> aber noch nicht zu Gesicht bekommen.

Wenn man ein Serienprodukt bauen muss, muss man sich schon 
tiefergehender mit der Stromversorgung beschäftigen, als "läuft 
wunderbar". Das klingt nach "beim mir am Tisch ist das nie was passiert" 
oder "der Kunde hat noch nicht gemeckert".

Solche Sachen machen dann gerne diese sporadischen Aussetzer, die dann 
gerne auf Softwarefehler geschoben werden.

Man kann das natürlich simulieren. Wir hatten keine passenden Tools 
dafür, und auch nicht die Zeit dazu.

Für eine einzelne Selbstbauplatine kann man es natürlich riskieren, und 
wird damit vermutlich keine Probleme haben.
Aber wenn man zigtausende davon im Feld hat, holt einen jedes kleine 
Zipperlein irgendwann ein. Und dann wird Schlamperei möglicherweise 
sehr, sehr teuer.

Autor: Don Kanaille (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für den UL (kleineres Package als die normalen i.MX6) und nur ein 16 Bit 
DDR3 reichen 0402 - und 10 Lagen braucht man da auch definitiv nicht.
Das ist nicht das Problem.


Ausschuss (das ist nicht unwahrscheinlich, gerade für die erste Serie) 
fehlt mindestens noch in der Kostenrechnung.
Impedanzkontrolle für die Platine ist vermutlich auch nicht 
einkalkuliert.

Du musst auch einkalkulieren, dass Du Prototypen brauchst - weil wenn 
was falsch ist willst Du ja nicht gleich 100 Stück in die Tonne kloppen?
Das alleine kostet aber locker einige hundert Euro weil geringe 
Stückzahlen...


Naja und wenn man auch nur einen geringfügigen Stundenlohn und reale 
Bestückungskosten annehmen würde, wär die Rechnung eh nicht ansatzweise 
realistisch aber das weisst Du ja sicher ;-)

Autor: Hurra (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Don Kanaille schrieb:
> Du musst auch einkalkulieren, dass Du Prototypen brauchst - weil wenn
> was falsch ist willst Du ja nicht gleich 100 Stück in die Tonne kloppen?
> Das alleine kostet aber locker einige hundert Euro weil geringe
> Stückzahlen...

Danke für den Hinweis, die "Kostenrechnung" habe ich glatt übersehen.

Naja, ich werde dann mal von jeder weiteren Kommentierung Abstand 
nehmen. Das Projekt hier ist hoffnungslos, soviel steht fest.

Autor: GHD (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich muss mich da leider bei den Schlechtmachern mit reinhauen. Ich würde 
mir das sehr sehr gut überlegen ob es sich lohnt das wirklich zu machen. 
Es gibt viele offene Designs für den IMX6. Wenn du wirklich was lernen 
willst, dann nimm ein fertiges Modul und mach dazu erstmal ein Baseboard 
mit der Peripherie (Ethernet, USB3.0,...) und tu einen eigenen NAND 
dazu. Ich habe das mal mit einem Wandboard Quad gemacht. Bei dem ist 
beispielsweise das NAND, PCIe, Ethernet, USB3.0, LVDS etc. rausgeführt.

Kleiner 6 Lagen schaffst du auch das nicht. Für die 90 / 100 Ohm 
Diffpairs brauchst du GND-Innenlagen die nah bei der Signalleitung 
liegen sonst musst du Ruck-Zuck Leiterbahnbreiten von 1,x mm bei abartig 
geringer Distanz führen. (z.B. 100 Ohm Diffpair bei 0,5mm Abstand zur 
GND-Lage ergeben 0,97mm) - nur mal so blöd in einen Rechner eingetippt. 
Und mit so breiten Leiterbahnen kommst du nirgendwo mehr durch.

Nächstes Problem Kosten: Weisst du was in Prototypen ein einfach 
6-lagige Platine mit Diffpairs kostet? Ich habe mal vorsichtig bei 
Multi-CB für 4 Lagen Impedanzkontrolliert 4 Diffpairs für Gigabit 
Ethernet bei 50x50mm angefragt - 360 €.

Bestückung: Von Hand löten - OK, geht mit 0403 noch easy, 0201 (brauchst 
du) wird es schon kniffliger. Teilbestücken lassen musst du in jedem 
Fall den IMX6 und vermutlich ein paar Power ICs (Sequencer usw). Darfst 
davon ausgehen, dass das auch nochmal 150-200€ kostet nur die ICs 
draufmachen zu lassen.

Zeit: Der Kernel ist ja nicht mehr das Thema dank Device-Tree Einführung 
bei Kernel >3.1
Hast du schonmal da was gemacht im Device-Tree? Schonmal versucht nur 
LVDS in Betrieb zu nehmen, wenn es die Distribution noch nicht 
unterstützt? Generell fürchte ich, dass du das zeitlich ein bisschen 
unterschätzt? Ehrlich - das wird vermutlich 1/2 Jahr Vollzeit benötigen 
bis du nur ein Layout fertig hast und dein Board auch nur irgendwas tut. 
Bis dann das Linux vernünftig läuft wird sicher nochmal 3-4 Monate 
vergehen. Dann willst du das ganze auch noch so dokumentieren dass es 
jeder Anwender versteht und ohne ein vernünftiges Marketing wirst du 
genau 0,00 verkaufen. Ist eben die Frage ob es lohnt - es gibt doch 
schon so viele Boards.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Bau unbedingt Ethernet (muss nicht unbedingt GBit sein, 10/100 reicht
> auch) dran

Guter Input.
Die Idee ist, Board der Grösse eines Compute Moduls zu bauen.
Der PHY wäre somit auf dem Trägerboard und nicht auf dem Compute Modul.

Dergute W. schrieb:
> 2.50 fuers PCB klingt ambitioniert, wie gross soll's denn werden und auf
> wieviele Lagen willst du das quetschen?

Grösse eines SODIMM 200 Riegels. 4 Lagen sind angedacht, da die meisten 
Pins nur herausgeführt werden müssen.
Leider kann da der Lagenaufbau nicht perfekt gewählt werden.

Dergute W. schrieb:
> Ueblicherweise haben SoCs ein paar GPIOs, die beim /RESET gesampled
> werden und dann die bootreihenfolge von verschiedenen Devices vorgeben.

Das war mir bekannt. Danke trozdem für den Hinweis.

Dergute W. schrieb:
> A propos: Hast du dich schon mal damit beschaeftigt, wie das Board zum
> ersten Mal in seinem Leben bootet, d.h. wenn im NOR-Flash noch kein
> u-boot usw. drinnensteht?

Ich würde vermutlich mittels Jumper zuerst uboot von der SD-Karte Laden 
und dann versuchen innerhalb des Linux uBoot aufs NOR zu schreiben.

Dergute W. schrieb:
> Bezgl. Buildsystemen: Du siehst, was eben schon beim Bau eines
> "Allerweltssystems" schiefgeht. Wenn das bei deinem Board passiert, dann
> gibts nix zu googlen.

Das ist mir bewusst. Deshalb versuche ich in möglichst kleinen, 
nachvollziehbaren Schritten voranzugehen. Zuerst ein Build für rPI dann 
kleine Anpassungen. Dann ein Build fürs gekaufte iMX6 Dev Board und so 
weiter...

Hurra schrieb:
> Du unterschätzt das Problem massiv. Wir haben hier alleine schon eine
> 10-Layer-LP gebraucht. Die kannst du nicht "mal schnell" bei ELECROW
> durchlaufen lassen.

Das ist korrekt, dass dies nicht schnell bei Elecrow machbar ist.
Es stellt sich aber die Frage, was für einen Chip ihr verbaut habt.
Nimmt man jenen mit 0.5mm Pitch wirds schnell eng und blind / burried 
vias werden nötig. Bei 0.8mm siehts ein wenig lockerer aus.

Wenn man nicht die vorgabe hat, alle GPIOs/Pins zu verwenden wird gleich 
nochmals einfacher.

Hurra schrieb:
> Du wirst auch 0201 benötige, die Kondensatoren unter dem i.MX6 benötigen
> diese Baugröße zwingend. Die KANN man von Hand bestücken, Spasss macht
> es nicht.

Nun, die Thematik mit den Kondensatoren ist etwas für sich. Wenn man ein 
vernünftiges Powersystem hat, dann brauchts die praktisch nicht mehr.
Aber das ist eine andere Diskussion. Grundsätzlich ja, die brauchts, und 
0201 ist denke ich nicht unbedingt notwendig 0402 oder gar 0603 ist 
sicher machbar. Viele dieser Kondensatoren sind "Angst-Kondensatoren".

Von hand mache ich das nicht. Mir steht eine Bestückungsanlage zur 
freien Verfügung.

Hurra schrieb:
> Und das Layout ist nicht mehr trivial. Mit Eagle halte ich das für
> unmöglich. Wir haben glücklicherweise eine Layouter-Abteilung hier, mit
> erfahrenen Mitarbeitern und entsprechenden Tools.

Ich bin beruflich Layouter mit den entsprechenden Tools.

Lothar M. schrieb:
> Ambitioniert, dann gleich mit einem richtigen Boliden zu beginnen. Aber
> man wächst bekanntlich an der Aufgabe.

Richtig. Zudem ist es ja nur zu teilen Neuland. Layout ist kein Neuland.

Lothar M. schrieb:
> Dann ist es logischerweise das Sinnvollste, auf EVAL-Boards des
> Herstellers zu setzen:

Habe ich mir besorgt.

Lothar M. schrieb:
> Dann würde ich mal empfehlen, andere Boards genauer anzuschauen. Klar
> kostet das ein paar Tausender und einiges an Zeit, aber die sparst du
> hinterher ja sicher wieder ein.

Das stimmt. Ich habe bereits einige Embedded Linux boards hier und habe 
bereits stunden mit dem Studium derer Technik/Software verbracht.

rk schrieb:
> Und genau dafür gibt es den Device Tree...

Das muss ich dann wohl googlen. Bin gerade dabei mich mit buildroot zu 
beschäftigen. Frage, wo muss ich den device tree einordnen innerhalb des 
build prozesses? An welcher Stelle kommt dies zum tragen und wo finde 
ich z.B. den DeviceTree vom rpi?

rk schrieb:
> Beim i.MX6 geht das recht einfach über USB mit dem mfgtool. Also USB OTG
> oder Device auf dem Board vorsehen.

Wird gemacht. Habe von diesem tool bereits gelesen.
Ist glaube ich auch recht gut dokumentiert in deren PDFs

rk schrieb:
> Nö. Läuft hier wunderbar mit 0402 und 0603.

Hab ich mir gedacht.

Don Kanaille schrieb:
> Ausschuss (das ist nicht unwahrscheinlich, gerade für die erste Serie)
> fehlt mindestens noch in der Kostenrechnung.

Das ist korrekt.
Ein gewisses Lehrgeld gehört dazu.

Don Kanaille schrieb:
> Du musst auch einkalkulieren, dass Du Prototypen brauchst - weil wenn
> was falsch ist willst Du ja nicht gleich 100 Stück in die Tonne kloppen?

Korrekt

Don Kanaille schrieb:
> Das alleine kostet aber locker einige hundert Euro weil geringe
> Stückzahlen...

Warum? Des Bestückungsautomat macht auch nur ein Stück.
Der steht im Nebenraum und ist zur freien Verfügung.

Don Kanaille schrieb:
> Naja und wenn man auch nur einen geringfügigen Stundenlohn und reale
> Bestückungskosten annehmen würde, wär die Rechnung eh nicht ansatzweise
> realistisch aber das weisst Du ja sicher ;-)

Ja das ist mir bewusst.

Ich rechne es halt so: Ich würde das Projekt ja ohnehin durchführen da 
es hier um die Ausübung eines Hobbys geht. Auch wenn es ein 
ambitioniertes und hochgestecktes Ziel ist und obwohl ich beruflicher 
Layouter bin mit ET-Studium ist es ein "Hobby"Projekt da es keinen 
Wirtschaftlichen Hintergrund hat.

Die Kosten für die Bestückung sind nicht eingerechnet da es sich um eine 
eigene, abgeschriebene Maschine handelt.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da das Thema ja recht interessant ist: Mal eine generelle Frage zu so 
embedded-Linux Hardware, sprich SoC, DDR3, Flash, etc...


Ab welchen Stückzahlen lohnt es sich generell, eine komplett eigene 
Hardware zu entwickeln, oder auf SoMs zu setzen?

Hat da jemand Erfahrungen?

Gibt es Beispiele, vlt auch aus dem Consumer/Automotive Bereich, wo die 
Stückzahlen nicht groß genug waren, sodass man auf SoMs setzt?

Autor: Holger B. (vilu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein erstes Design in meiner Berufslaufbahn war ein Embedded-Board mit 
einem Blackfin, da hab ich mich auch noch selbst um 
Schaltung/Layout/Linux-BSP gekümmert. Der Aufwand lag im Bereich eines 
Mannjahres bis zum Funktionsmuster, war also überschaubar.

Aktuell sitze ich (als Teil eines Teams) auch an einem i.MX6Q-Design und 
ich kann dir sagen, dass das in jeglicher Hinsicht eine ganz andere 
Hausnummer ist. Der Boom der SoM-Module hat schon seinen Grund, mit 
eigenen Designs sind nicht wenige, auch durchaus erfahrene 
Entwicklerteams auf die Nase gefallen...

Wenn du das alleine in endlicher Zeit und zu vernünftigen Kosten zum 
Laufen bekommst, dann bist du ein Universalgenie und für einen 
Layouter-Job mit Sicherheit überqualifiziert :-)

Hab den Thread auf jeden Fall mal abonniert und drück dir die Daumen, 
vielleicht kann ich dir ja den ein oder anderen Tipp geben oder selbst 
was interessantes für mich mitnehmen.

: Bearbeitet durch User
Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger B. schrieb:
> Wenn du das alleine in endlicher Zeit und zu vernünftigen Kosten zum
> Laufen bekommst, dann bist du ein Universalgenie und für einen
> Layouter-Job mit Sicherheit überqualifiziert :-)
>
> Hab den Thread auf jeden Fall mal abonniert und drück dir die Daumen,
> vielleicht kann ich dir ja den ein oder anderen Tipp geben oder selbst
> was interessantes für mich mitnehmen.

Vielen Dank für deinen Kommentar.

Die Hardware macht mir weniger Sorgern. Es geht mir mehr um die 
Software.
Aktuell versuche ich herauszufinden, was alles zu einem erfolgreichen 
Build gehört.

Aktuell weiss ich folgendes:

SoC Lädt code von bestimmter Quelle abhängig von GPIO
uBoot startet Kernel
Kernel muss für imx6 kompiliert werden
Kernel schaut sich Device Tree an und weiss was wo dranhängt und kann 
die Treiber starten

rootfs liegt auf dem Speicher.
rootfs ist eine zusammenstellung verschiedener Software zu einem 
funktionierenden System.


Offene fragen:

Kernel, kann ich den vanilla kernel (also unveränderter code) von 
Linux.org verwenden und für imx6 compilieren oder muss dieser zuvor 
modifiziert werden? bzw brauche ich einen für imx6 modifizierten kernel?

Wenn ja, was wurde modifiziert?

Treiber: wo befinden sich die Treiber? Handelt es sich dabei lediglich 
um treiber Module welche unabhängig vom Kernel compiliert werden können?

Beispiel für WLAN, lade ich mir die sourcen für den WLAN Treiber 
herunter welche es z.B. für Debian gibt und compiliere diese für imx6 
und kopiere das modul dann wohin?

Es fehlt mir momentan noch an übersicht.
Wenn jemand gute Literatur, Kurse oder Youtube videos dazu kennt, bitte 
nennt diese.

Autor: Holger B. (vilu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:

> Ab welchen Stückzahlen lohnt es sich generell, eine komplett eigene
> Hardware zu entwickeln, oder auf SoMs zu setzen?

Das hängt auch von der Umgebung des SoM ab. Liegt die Komplexität 
ausschließlich im SoM und der Rest ist alles Primitivtechnik auf 4 
Lagen, dann wird man eher zu einem SoM greifen als wenn man außenrum 
weitere anspruchsvolle Elektronik mit DSPs/FPGAs sitzen hat, für die man 
ähnliche Technologien benötigt wie beim SoM selbst.

Als Zwischending gibt es von Freescale Single Chip Module, wo Power 
Management und Speicher schonmal integriert sind bzw. als PoP montiert 
werden: 
http://www.nxp.com/products/single-chip-modules:SI...
Dann hat man schon einmal zwei Hürden weniger, günstig sind die aber 
auch nicht und man kommt um HDI auch nicht herum.

Autor: rk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hurra schrieb:
> Wenn man ein Serienprodukt bauen muss, muss man sich schon
> tiefergehender mit der Stromversorgung beschäftigen, als "läuft
> wunderbar". Das klingt nach "beim mir am Tisch ist das nie was passiert"
> oder "der Kunde hat noch nicht gemeckert".

Du darfst mir glauben, dass "läuft wunderbar" etwas mehr bedeutet, als 
nur "läuft an meinem Tisch" und dass es um mehr als nur um eine Hand 
voll Boards geht.

Laut einem NXP (bzw. damals Freescale) Mitarbeiter könnte man die Anzahl 
der Bypass-Kondensatoren gegenüber dem Reference-Design sogar halbieren 
(https://community.nxp.com/thread/312070). Er gibt als Faustregel ein 
Bypass-Kondensator pro zwei Pads an, was mit 0402 auf jeden Fall möglich 
ist (nicht einfach, aber möglich).

Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:

> Ab welchen Stückzahlen lohnt es sich generell, eine komplett eigene
> Hardware zu entwickeln, oder auf SoMs zu setzen?
>
> Hat da jemand Erfahrungen?

Mein erstes Design war n X86 mit i855 Chipsatz. Klassisch 
CPU-Northbridge-Southbridge. Die Kalku ging damals von mindestens 15k 
aus als break even. Insgesamt plumpste dieses Modul fast sechsstellig 
vom Band. Hat sich gelohnt.

Bei 100 Stück im Jahr ist es Liebhaberei. Viel spass beim 
eol-management. Aktuell NOR-Flashes mit <128M.

Autor: rk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Offene fragen:
>
> Kernel, kann ich den vanilla kernel (also unveränderter code) von
> Linux.org verwenden und für imx6 compilieren oder muss dieser zuvor
> modifiziert werden? bzw brauche ich einen für imx6 modifizierten kernel?

Es sind wohl schon einige Anpassungen in den Mainstream-Kernel 
geflossen. Ich würde Dir aber raten das Community-BSP zu verwenden. 
Warum sich selbst die Arbeit machen, wenn das andere für einen schon 
erledigt haben?


> Wenn ja, was wurde modifiziert?

Um das herauszufinden könntest Du die entsprechenden repositories 
durchforsten, das könnte aber dauern.


> Treiber: wo befinden sich die Treiber? Handelt es sich dabei lediglich
> um treiber Module welche unabhängig vom Kernel compiliert werden können?

Kernelmodule brauchen zum bauen zumindest die header des entsprechenden 
Kernels, dazu die entsprechende cross-toolchain, etc.
Wenn das entsprechende Modul aber im Kernel schon verfügbar ist, wäre es 
nur notwendig, es in der config zu aktivieren und sein yocto neu bauen 
zu lassen.


> Beispiel für WLAN, lade ich mir die sourcen für den WLAN Treiber
> herunter welche es z.B. für Debian gibt und compiliere diese für imx6
> und kopiere das modul dann wohin?

Sicher, dass es sourcen sind? Durch die Distributionsabhängigkeit klingt 
das irgendwie nach binary - das würde natürlich nicht gehen. Ansonsten 
würde ich ebenfalls das Community-BSP nehmen, nach einem ähnlichen 
Treiber suchen und das zugehörige "recipe" kopieren, anpassen und neu 
bauen.

Autor: Dergute Weka (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Also ich seh' das Unterfangen nicht so negativ. Mit dem Background kann 
das schon klappen. Fuer vernuenftige Linux-Kentnisse auch und gerade 
fuer embedded, empfehl' ich mal www.linuxfromscratch.org/
‎Wenn man mal ein paar (B)LFSse gebaut hat, dann weiss man ziemlich 
genau, wo der Frosch die Locken bzw. der Kernel die WLAN Treiber hat.

Klaro wird man mit solchen Dingern in noch-viel-billiger totgeworfen; 
erst heute wieder:
https://www.heise.de/newsticker/meldung/Neue-Baste...

Aber im Vergleich zu den Leuten, die sich unbedingt ein 30V5A 
Labornetzteil selber zusammenschustern muessen, was monetaer aehnlich 
hoffnungslos ist, find ich sowas doch ganz reizvoll.
Obwohl ich auch leise Zweifel hab' bei einem 4 Lagendesign mit DDR.

Gruss
WK

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rk schrieb:
> Laut einem NXP (bzw. damals Freescale) Mitarbeiter könnte man die Anzahl
> der Bypass-Kondensatoren gegenüber dem Reference-Design sogar halbieren
> (https://community.nxp.com/thread/312070). Er gibt als Faustregel ein
> Bypass-Kondensator pro zwei Pads an

#OffTopicSTART

Diese Aussage ist ziemlich gegenstandslos. Es kommt vor allem darauf an 
wie Niederimpedant deine Speisung ist. Und zwar breitbandig!

Ein Kondensator ist immer auch eine Induktivität. Bei grossen bzw 
schnellen Stromänderungen (dI/dt) kommt diese Induktivität sehr schnell 
zum tragen.
Wenn man dies einmal in Lt-Spice simuliert oder auch nur ausrechnet wird 
man schnell merken, dass das vermeintlich gute C doch eher eine nutzlose 
Spule geworden ist und in Wirklichkeit sehr hochohmig.
Doch genau in diesem Moment (grosses dI/dt) braucht man bzw möchte man 
die Energie aus dem C haben. Doch genau dann versagt jenes.

Mögliche Abhilfe: low ESR Caps, mehrere paralell, low inductance Caps
Besser: breitbandig niederimpedantes Versorgungssystem erstellen.
Wie? Mit einem korrekten Lagenaufbau und der Berechnung der Impedanzen 
an verschiedenen orten.

Wenn man dies korrekt durchführt, was einiges an knowHow benötigt, dann 
kann man die "Stützkondensatoren" alle wegkippen! Garantiert!

#OffTopicEND

rk schrieb:
> Warum sich selbst die Arbeit machen, wenn das andere für einen schon
> erledigt haben?

Um was zu lernen
Um den neusten Kernel zu haben.

Habe mir nun ein bisschen den NXP Kernel angesehen.
Da ist einiges an iMX spezifischem code enthalten.
z.B. ein eigenes device tree file (*.dts) welches die CPU beschreibt und 
deren Speisung. Zudem gibts noch ettliche andere modifikationen z.B. für 
den DMA etc.

ABER: auf deren Seite ( https://community.nxp.com/docs/DOC-100847 ) 
gibts ne Anleitung zum compilieren des Kernels. Da wird auch auf den 
vanilla code verwiesen. Doch ich frage mich, warum?
Offensichtlich läuft der iMX6 auch mit dem vanilla code.
Brauchts also all diese zusätzlichen modifikationen garnicht?

Dergute W. schrieb:
> Also ich seh' das Unterfangen nicht so negativ. Mit dem Background kann
> das schon klappen. Fuer vernuenftige Linux-Kentnisse auch und gerade
> fuer embedded, empfehl' ich mal www.linuxfromscratch.org/

Vielen Dank für den Tipp und für die Zuversichtlichkeit.

Dergute W. schrieb:
> Wenn man mal ein paar (B)LFSse gebaut hat, dann weiss man ziemlich
> genau, wo der Frosch die Locken bzw. der Kernel die WLAN Treiber hat.

Was ist ein LFSse?

Dergute W. schrieb:
> find ich sowas doch ganz reizvoll

Freut mich!

Dergute W. schrieb:
> Obwohl ich auch leise Zweifel hab' bei einem 4 Lagendesign mit DDR.

Das wird sich zeigen. sicher ist nur das ich es versuchen werde.
Wenn ich merke dass es nicht machbar ist, kann ich immer noch auf 6 
Lagen wechseln.



Update:

Aktuell habe ich hier auf dem Tisch ein imx6ul evk.
Ich habe soeben mit buildroot ein Kernel, u-boot und rootfs erstellt.
Nun wird gleich getestet ob es bootet.

Laut der Buildroot config befindet sich im repo des NXP Kernels auch das 
dts file aus welchem dann das device tree blob erstellt wird welches von 
uboot gelesen wird und die daten an den kernel übergibt.

Ich werde nun versuchen das image der unveränderten config zu booten.
anschliessend schaue ich mit das dts an und versuche zu verstehen.
Danach versuche ich uboot so anzupassen, dass es das rootfs wo anderst 
sucht.

Was ich noch nicht ganz verstanden habe ist, weshalb wohl in der 
defconfig auch die sourcen für uboot custom sind und nicht eine 
untouched version verwendet wird. Hat jemand eine idee weshalb man sich 
u-boot anpassen sollte? abgesehen von der uboot.env?

: Bearbeitet durch User
Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Ein Kondensator ist immer auch eine Induktivität. Bei grossen bzw
> schnellen Stromänderungen (dI/dt) kommt diese Induktivität sehr schnell
> zum tragen.

Genau. Das ist ein Grund warum für manche Designs Cs in 0201 etc. 
vorgeschrieben werden. Denn typischerweise gilt desto kleiner die 
Bauform des C, desto kleiner dessen parasitäre Induktivität.

Und deshalb wird bei vielen Designs auch vorgegeben daß die Cs direkt 
auf der Unterseite des ICs platziert werden sollen - damit die 
Induktivität der Zuleitung so gering wie möglich ist.

> Besser: breitbandig niederimpedantes Versorgungssystem erstellen.
> Wie? Mit einem korrekten Lagenaufbau und der Berechnung der Impedanzen
> an verschiedenen orten.
>
> Wenn man dies korrekt durchführt, was einiges an knowHow benötigt, dann
> kann man die "Stützkondensatoren" alle wegkippen! Garantiert!

Du meinst die Kapazität der Lagen zueinander als Kondensator verwenden? 
Das gibt aber doch nur eine sehr begrenzte Kapazität, auch wenn sie eine 
niedrige parasitäre Induktivität hat.

Letztlich brauchst Du doch irgendwo Kondensatoren die kurzzeitig liefern 
können bis die Regelung Deines Spannungswandlers Zeit hatte zu 
reagieren.

: Bearbeitet durch User
Autor: Schnupftabak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Danach versuche ich uboot so anzupassen, dass es das rootfs wo anderst
>sucht.

Das rootfs wird per Kernel-Coammandline spezifiziert.
Dem Uboot selbst ist das egal.

Autor: Schnupftabak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hat jemand eine idee weshalb man sich
>u-boot anpassen sollte? abgesehen von der uboot.env?

Wenn das Uboot bereits alle Treiber enthält, die zum Booten notwendig
sind, ist da nix anzupassen.

Autor: ABC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Euch allen ist bewusst das es sich hier um den kleinsten imx6 handelt? 
Dem iMX 6 Ultra lite
Ein A7 mit nichtmal 600 MHz mit knapp 300 Balls und 14x14 mm.

Das Ding ist vermutlich nicht wirklich schneller als ne Himbeere.

Autor: OptimistPrime (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehr interessantes Projekt ;-) .
Ich bin da sehr optimistisch, dass der Threadersteller es irgendwann 
schaffen wird. Alle die sich hier an den Bypass Kondensatoren 
festhalten, hab vor kurzen auch ein iMX6 Board gelayoutet und habe vor 
allem durch den Lagenaufbau die notwendige Kapazität geschaffen. Dann 
wird die Impadanz simuliert und ein paar größere Cs an bestimmte Stellen 
platziert und fertig.
Mit den 4 Lagen wirst du niemals auskommen außer mit Vielleicht dem 
dreifachen Aufwand.

Außerdem wieso rechnest du mit Stückzahlen über 100? Soll das verkauft 
werden? Habe ich das irgendwo überlesen.

Beim Schaltplan unbedingt Power-Up Sequencing beachten und einplanen!

Autor: Hurra (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
OptimistPrime schrieb:
> Sehr interessantes Projekt ;-) .
> Ich bin da sehr optimistisch, dass der Threadersteller es irgendwann
> schaffen wird. Alle die sich hier an den Bypass Kondensatoren
> festhalten, hab vor kurzen auch ein iMX6 Board gelayoutet und habe vor
> allem durch den Lagenaufbau die notwendige Kapazität geschaffen. Dann

Eigentlich wollte ich ja nichts mehr schreiben, aber das hier ist 
einfach nur brutal. Das ist so ein Krampf, das kann man nicht 
unwiedersprochen stehen lasssen.

Hast du schon mal BERECHNET, auf welche Kapazität dein Lagenaufbau 
kommt?
Ich tippe auf ein paar 100pF, wenn es hoch kommt. Mit viel Fläche. Man 
hat aber mehrere hundert nF bis µF.
Somit hast du um Faktor 1000 - 100000 zu wenig Kapazität.

Ja, der Lagenaufbau von VCC<> GND ist wichtig, man macht die Planes eng 
zusammen. Was man aber tut, ist zu versuchen einen niedrigen 
WELLENWIDERSTAND zu erreichen, nicht eine hohe Kapazität.

Rechne dein Layout nach. Nur grob Überschlagsmässig. mehrere 100nF hat 
das nicht. Geschweige denn µF.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schnupftabak schrieb:
> Das rootfs wird per Kernel-Coammandline spezifiziert.
> Dem Uboot selbst ist das egal.

Richtig
Aber uboot übergibt dies dem Kernel

ABC schrieb:
> Das Ding ist vermutlich nicht wirklich schneller als ne Himbeere.

Das ist kein Problem.
Irgendwo muss man halt mal beginnen.

OptimistPrime schrieb:
> Sehr interessantes Projekt ;-) .
> Ich bin da sehr optimistisch, dass der Threadersteller es irgendwann
> schaffen wird.

Danke

OptimistPrime schrieb:
> Mit den 4 Lagen wirst du niemals auskommen außer mit Vielleicht dem
> dreifachen Aufwand.

Es wird bestimmt mehr Aufwand sein als mit 6 Lagen.
Es ist schwierig so etwas im vornherein ohne Schema abzuschätzen.
Deshalb ist es vorerst mal ein grobes Ziel 4 Lagen zu erreichen.

OptimistPrime schrieb:
> Außerdem wieso rechnest du mit Stückzahlen über 100? Soll das verkauft
> werden? Habe ich das irgendwo überlesen.

Nein das hat bisher kein komerzieller Aspekt.
Ich könnte mir vorstellen ein paar dieser Boards später an interessierte 
kostenlos abzugeben.

Wenn sich dann noch einige finden die das zu den aufwandskosten 
abnehmen, kämen evtl. 100 zusammen. Aber um Gewinn gehts nicht.

OptimistPrime schrieb:
> Beim Schaltplan unbedingt Power-Up Sequencing beachten und einplanen!

Danke, das ist ein guter Hinweis!
Bei irgendeinem Beispielschema habe ich bereits ein entsprechendes 
Sequencing gesehen. Ich glaube es war beim imx6 Rex board.

Hurra schrieb:
> ist zu versuchen einen niedrigen
> WELLENWIDERSTAND zu erreichen, nicht eine hohe Kapazität.

Richtig, die eigentliche Energie kommt dann aus den

OptimistPrime schrieb:
> ein paar größere Cs an bestimmte Stellen
> platziert



Update:

Gestern habe ich die unveränderte Buildroot Config fürs ulEVK laufen 
lassen und den entstandenen Kernel + rootfs + uboot auf die Karte 
geschrieben. Hat erwartungsgemäss gebootet.

Habe dann in der config lediglich die Kernel Header, und den Kernel auf 
die aktuellste version 4.9 umgestellt. Zudem habe ich die erzeugung des 
dtb deaktiviert da im neuen KernelSource kein passendes dts vorhanden 
war.

Erzeugt, auf sd kopiert -> läuft nicht.
uboot sagt nur "kein dtb gefunden" starte kernel -> und das wars dann.

Es sieht für mich aus, als würde uboot den kernel garnicht finden.
Das sdimage.bin ist auch nur 40MB im vergleich zu den knapp 90MB mit 
original config.


Habe mir zudem noch die imx Kernel Sourcen angeschaut.
Da ist sehr viel imx spezifisches drinn. Ich frage mich wirklich, 
weshalb die in ihrer Anleitung auch auf den vanilla code verweisen.

Die uboot sourcen habe ich auch durforstet. Da sind ettliche configs für 
die verschiedenen freescale boards enthalten. Vorallem aber sind dort in 
den configs die parameter fürs DDR3 Ram enthalten und von wo der kernel 
gebootet wird.

Ist doch ne ganze menge verknüpfter dinge vorhanden.
Das war mir nicht bewusst, da ich eher auf der Hardware Seite 
angesiedelt bin. Nichts desto troz bin ich der Meinung, dass das Projekt 
nach wie vor durchführbar ist.

Mir fehlt aktuell einfach noch der gesamtüberblick wo was anzupassen 
ist.
Falls jemand informationen dazu kennt/hat bitte her damit.

Was ich bisher weiss:

Kernel:
- Treiber integrieren
- dts file erstellen welches die Hardware beschreibt

Das dts File ist ziemlich komplex. Da werden offensichtlich auch die 
Ports umgestellt, indem direkt die Register beschrieben werden, 
jenachdem welche Hardware aktiviert wird. Gibts dafür ein Tool oder 
schreibt man das von hand? Wo gibts informationen dazu wie genau das für 
den imx6 gemacht wurde. Da gibts viele Defines und ich denke dass diese 
nicht alle "üblich" sind sondern einige von NXP/freescale so benannt 
wurden.

uboot:
- Board Configuration erstellen
- DDR3 Configuration
- Treiber integrieren welche zum Booten nötig sind

: Bearbeitet durch User
Autor: Hurra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Danke, das ist ein guter Hinweis!
> Bei irgendeinem Beispielschema habe ich bereits ein entsprechendes
> Sequencing gesehen. Ich glaube es war beim imx6 Rex board.

Tu dir einen Gefallen und nimm einen PMIC.
Einen PF0100 oder PF0200 von NXP zum Beispiel. Die programmierst du 
entweder selber, oder kaufst ihn vorprogrammiert mit der passenden 
OTP-Variante.

Lass dich nicht davon stören, dass die Hälfte der Regler dann unbenutzt 
vor sich hin dümpelt.

Aber der PMIC ist schon eine große Erleichterung, er nimmt dir eine 
Menge Arbeit ab. Der ganze Sequencing Kram passt damit, und Geld und 
Platinenfläche spart man damit auch.

Bevor du mit irgenwas weitermachst:
Mach dir ein Blockschaltbild, recherchiere die Bauteile, deren Kosten, 
den schaltungstechnischen Aufwand und überleg dir, wie du die einzelnen 
Blöcke grob umsetzen willst. Erst wenn dir das alles klar ist, kannst du 
den Aufwand überhaupt beurteilen. Plane nicht ein 4-Lagen Design, bevor 
dir der Aufwand überhaupt klar ist.

Um die Software kümmerst du dich, sobald das NOR-Flash bootet. Vorher 
nicht. Sich jetzt Gedanken um den Lagenaufbau oder Treiber zu machen, 
ist verfrüht.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hurra schrieb:
> Tu dir einen Gefallen und nimm einen PMIC.
> Einen PF0100 oder PF0200 von NXP zum Beispiel

Danke für den Tipp.
Ich denke das macht absolut Sinn!

Hurra schrieb:
> Lass dich nicht davon stören, dass die Hälfte der Regler dann unbenutzt
> vor sich hin dümpelt.

Danke, das hätte mich vermutlich wirklich etwas irritiert.

Hurra schrieb:
> Mach dir ein Blockschaltbild, recherchiere die Bauteile, deren Kosten,
> den schaltungstechnischen Aufwand und überleg dir, wie du die einzelnen
> Blöcke grob umsetzen willst. Erst wenn dir das alles klar ist, kannst du
> den Aufwand überhaupt beurteilen. Plane nicht ein 4-Lagen Design, bevor
> dir der Aufwand überhaupt klar ist.

Das wird wohl der nächste Schritt sein.

Hurra schrieb:
> Um die Software kümmerst du dich, sobald das NOR-Flash bootet. Vorher
> nicht. Sich jetzt Gedanken um den Lagenaufbau oder Treiber zu machen,
> ist verfrüht.

Meinst du jetzt das NOR Flash auf meinem Evaulation Board oder jenes auf 
meinem fertigen Board?

Mir war es wichtig zu prüfen, wie gross denn der Aufwand für die 
Software ist. Das war für mich überhaupt nicht abschätzbar. Nun habe ich 
langsam ein Bild davon.


Update:

Im aktuellsten Mainline Kernel befindet sind bereits die config für die 
verschiedenen imx6. folglich gehe ich davon aus, dass der Mainline 
Kernel doch funktionieren müsste. Also hab ich wohl doch irgendwo einen 
Bock im uboot oder im sdcardimage.

Hier nochmal eine Webseite welche dies bekräftigt: 
https://community.nxp.com/docs/DOC-1468

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hurra schrieb:
> Somit hast du um Faktor 1000 - 100000 zu wenig Kapazität.
Das ist lustigerweise egal, solange das Ding nicht komplett mit allen 
Hardwareeinheiten (Grafik+Netzwerk+pipapo) unter Vollast läuft...

OptimistPrime schrieb:
> Dann wird die Impadanz simuliert und ein paar größere Cs an bestimmte
> Stellen platziert und fertig.
Du hättest die Simulation auch weglassen können und die Cs irgendwo 
platzieren können. Mit sehr hoher Wahrscheinlichkeit "funktioniert" das 
durchaus. Probier einfach mal aus, die Cs einen nach dem anderen runter 
zu löten und zu testen, ob es noch läuft. Du wirst staunen...

Ich habe diesen Test schon öfter gemacht (das letzte Mal bei einem 
Beckhoff EtherCAT ASIC, der auf einen 4 lagigen Design sogar noch ganz 
ohne Kondensatoren über den gesamten Temperaturbereich lief) und mache 
sowas auch mal gerne im Layout zum Abschaätzen, wie weit man in der 
Praxis von irgendwelchen (Hersteller-)Vorgaben abweichen könnte.

Holger K. schrieb:
> die Register beschrieben werden, jenachdem welche Hardware aktiviert
> wird. Gibts dafür ein Tool oder schreibt man das von hand? Wo gibts
> informationen dazu
Im Datenblatt des i.MX6. Das ist letztlich nur ein uC, wenn auch ein 
recht komplexer. Aber du kannst dort nachlesen, wie der Clocktree 
konfiguriert und dynamisiert werden kann, wie man Hardwarekomponenten 
ein- und ausschaltet, wie man irgendwelche Timer oder EA anspricht. Die 
SPI oder der CAN ist da z.B. nicht ein virtuelles "Ding", für das man 
unbedingt einen Treiber braucht. Nein, man kann die paar Register 
durchaus auch selber in die Finger nehmen und das Ding so zum Laufen 
bekommen.
Es ist sogar eher so, dass ein OS mit seiner eigenen Komplexität diese 
"einfachen" Dinge verkompliziert...

: Bearbeitet durch Moderator
Autor: Hurra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Das ist lustigerweise egal, solange das Ding nicht komplett mit allen
> Hardwareeinheiten (Grafik+Netzwerk+pipapo) unter Vollast läuft...

Es gehört aber klargestellt, dass das Layout trotzdem kein Ersatz für 
Kapazitäten ist. Und das war der Punkt meines Beitrages. Ein Layout kann 
keine Pufferkondensatoren ersetzen, weil das Layout niemals Kapazitäten 
im nF-Bereich bereitstellen kann (außer man mach gigantisch große 
Platinen mit vielen Lagen).

PS:
Das die Meinungen in diesem Punkt (Kondensatoren) auseinandergehen ist 
mir klar. Aber eigentlich ist das so
- Entweder man macht eine Power-Intigrity Simulation, und optimiert die 
Kondensatoren aufgrund einer physikalischer Grundlage weg
- Oder man hält sich an das Referenzdesign

Blind irgenwelche Kondensatoren aufgrund "Bauchgefühls" weglassen ist 
schlicht dumm. Die BOM-Kosten der kleinen Pufferkondensatoren (bei einem 
mir bekannten Design) liegen bei <0,3% der Gesamtkosten für die 
Bauteile.
Die Diskussion haben wir hier auch geführt, mit dem Ergebnis, dass die 
Diskussion über die Pufferkondensatoren bei unseren Stückzahlen teurer 
war, als man jemals sparen könnte, selbst wenn man alle (kleinen) 
Kondensatoren weglässt.

Autor: il Conte (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Holger K. schrieb:
> Es wird bestimmt mehr Aufwand sein als mit 6 Lagen.
> Es ist schwierig so etwas im vornherein ohne Schema abzuschätzen.
> Deshalb ist es vorerst mal ein grobes Ziel 4 Lagen zu erreichen.

Wenn man diesen Thread aufmerksam verfolgt gewinnt man den Eindruck dass
es ich bei dir um einen Star-Layouter handelt,
der sich mittendrin in einer 'Metamorphose' zum Star-Designer befindet.😟

Aber das hier??
bei 4 (vier) Lagen verbraucht man schon mindestens 2 Lagen für VDD und 
GND.
Da bleiben eigentlich nur 2 Signal-Lagen übrig?🤔🤔

Mich macht sowas stutzig:-((.
Da erübrigen sich für mich alle Nachfragen.👎

Autor: Hurra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
il Conte schrieb:
> Aber das hier??
> bei 4 (vier) Lagen verbraucht man schon mindestens 2 Lagen für VDD und
> GND.
> Da bleiben eigentlich nur 2 Signal-Lagen übrig?🤔🤔

Hmm. Ich hatte 20 unteschiedliche Versorgungen anzuschließen.

Davon 7 unterschiedliche Spannungen, und eine Menge verschiedener 
Planes. Weiß nimmer, >6 oder so. Hat der E-Cadler gemacht nicht ich.

Mein Board war allerdings sehr minimalistisch, da habe ich viel sparen 
könnnen bei den Spannungen. Ein komplexes Board kommt sicher auf mehr.

So schlimm wirds beim TO vielleicht nicht, der hat ja nur den kleinen, 
aber mit einem einzelnen VCC <> GND - Modul ist es nicht getan, das ist 
mal sicher :-)

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
il Conte schrieb:
> Wenn man diesen Thread aufmerksam verfolgt gewinnt man den Eindruck dass
> es ich bei dir um einen Star-Layouter handelt,
> der sich mittendrin in einer 'Metamorphose' zum Star-Designer
> befindet.😟

Interessante auffassung :)
Aber ein Star-Layouter bin ich gewiss nicht.
Wenn dann einfach ein erfahrener Layouter mit dem nötigen know-how im 
entsprechenden Bereich (High-speed design)

il Conte schrieb:
> Aber das hier??
> bei 4 (vier) Lagen verbraucht man schon mindestens 2 Lagen für VDD und
> GND.
> Da bleiben eigentlich nur 2 Signal-Lagen übrig?🤔🤔

Nun, DDR3 Memory kann man in einem gewissen Rahmen so anschliessen dass 
es möglichst günstig ist fürs Layout.

Zudem muss ich nicht alle 289(?) Balls des imx6 verbinden, da ich nicht 
alle Peripherie benötige.

Deshalb sehe ich das zwar sportlich aber noch nicht ganz hoffnungslos.
Zudem ist die anzahl der Layer ja kein k.O. kriterium. Das ist was dass 
man dann halt einfach mit ein paar klicks erhöht.
Klar erhöht das dann auch die Kosten.

Für mich ist das Layout wie gesagt nicht der Stolperstein.
Wenn dann eher das Schema. Wobei ich auch das Handeln können sollte.

Für mich ist vorallem die Software neuland.
Deshalb versuche ich derzeit abzuschätzen ob es für mich machbar sein 
wird einen eigenen Kernel für mein künftiges Board zu erstellen.

Wenn ich dass als nicht machbar erachte, dann brauche ich auch keine 
Hardware zu erstellen.

Deshalb beschäftigte ich mich vorerst mehr mit Linux als mit der 
Hardware.
Da die Hardware mehr oder minder klar ist.

- Speisung
- iMX6
- RAM
- Speicher

- Peripherie wird dann wohl auf dem Baseboard zu finden sein und nicht 
auf dem Modul selbst. Da bin ich mir aber noch nicht sicher.

Vielleicht mache ich auch zuerst ein Testboard welches meine Hardware 
enthält ohne direkt mit einem Modul und Baseboard zu starten.
Ist vermutlich der einfachere und schnellere Weg für den Einstieg.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hurra schrieb:
> So schlimm wirds beim TO vielleicht nicht, der hat ja nur den kleinen,
> aber mit einem einzelnen VCC <> GND - Modul ist es nicht getan, das ist
> mal sicher :-)

Ein Versorgungssystem wird vermutlich nicht reichen.
Aber das sind Probleme die Lösbar sind.

Autor: il Conte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Ein Versorgungssystem wird vermutlich nicht reichen.
> Aber das sind Probleme die Lösbar sind.

mit mehr Lagen :-) (>4;-)

Autor: Michael X. (Firma: vyuxc) (der-michl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hurra schrieb:
> Lothar M. schrieb:
>> Das ist lustigerweise egal, solange das Ding nicht komplett mit allen
>> Hardwareeinheiten (Grafik+Netzwerk+pipapo) unter Vollast läuft...
>
> Es gehört aber klargestellt, dass das Layout trotzdem kein Ersatz für
> Kapazitäten ist. Und das war der Punkt meines Beitrages. Ein Layout kann
> keine Pufferkondensatoren ersetzen, weil das Layout niemals Kapazitäten
> im nF-Bereich bereitstellen kann (außer man mach gigantisch große
> Platinen mit vielen Lagen).

Das ist schlicht eine Frage der Philosophie. Mark Montrose empfiehlt 
eben diese 100pF, weil die extrem breitbandig sind. Ein 0603 hat bei 
etwa 25MHz Resonanz, die 0201 entsprechend höher. Keiner von denen kann 
die 600MHz bedienen. Das kann nur diese Plane. Und damit die Plane 
'nachgeladen' wird wirft man eine Handvoll 100n auf die Leiterplatte.
Er hat damit etliche Boards zum laufen bekommen und durch alle EMV-Tests 
geprügelt.

Autor: Hurra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael X. schrieb:
> Das ist schlicht eine Frage der Philosophie. Mark Montrose empfiehlt
> eben diese 100pF, weil die extrem breitbandig sind. Ein 0603 hat bei
> etwa 25MHz Resonanz, die 0201 entsprechend höher. Keiner von denen kann
> die 600MHz bedienen. Das kann nur diese Plane. Und damit die Plane
> 'nachgeladen' wird wirft man eine Handvoll 100n auf die Leiterplatte.
> Er hat damit etliche Boards zum laufen bekommen und durch alle EMV-Tests
> geprügelt.

Den Frequenzgang eines Kondensators gibt der Hersteller im Datenblatt 
an. Um eine Sichtung dessen kommt man ohnehin nicht herum, wenn man die 
kleinen Kerlchen auswählt.
Ich bezweifle, dass ein 100p den gleichen Frequenzgang hat wie eine 
100nF ;-)

Generell ist das aber so:
Man versucht, am PIN eine niedrige Quellimpedanz für die Stromversorgung 
über einen breiten Frequenzbereich zu erreichen.
Das geht immer nur mit einer Kombination aus Plane und Kondensatoren. 
Und wer schon mal diverse Simulationen gemacht hat, weiß, dass die 
Kombination 47µF Elko am Ende der Platine und Powerplane die ganzen 
vielen kleinen Kondensatoren nicht restlos ersetzen kann.

Man kann EINIGE Kondensatoren kübeln oder versetzen, wenn man berchnet, 
an welcher Stelle der Plane man welchen Frequenzgang der Impedanz hat.

Weil sich ein Hobbybastler (naja, nicht nur der ;-)) diesen blöden 
Mistkram nicht antun will, baut er das Referenzdesign nach und nimmt die 
gleiche Anzahl Kondensatoren.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> No Y. schrieb:
>> Zu Inspirationszwecken:
>>
> 
http://www.phytec.de/produkt/system-on-modules/phy...

http://www.variscite.com/products/system-on-module...

Das lag, angefragt vor etwa einem Jahr, in der Variante mit 512 MiB RAM, 
G2 (6UL mit 2x CAN, 2x ETH, Crypto etc.), 512 MiB Flash (NAND, eMMC 
gibt's ab 4 GB), Audio, Ethernet-Phy, WLAN + Bluetooth 4.1/LE bei etwa 
$60 bei Einzelstücken

Edit:
Die Artiks von Samsung gehen in dieselbe Richtung:
Artik 710 etwa $52 (Digikey bei 5 Stück) allerdings 1.4 GHz Octacore 
A53, 1 GiB LPDDR3, 4 GB eMMC, WLAN, BT/LE, Zigbee etc.
https://www.artik.io/modules/artik-710/

GHD schrieb:
> Bei dem ist beispielsweise das NAND, PCIe, Ethernet, USB3.0, LVDS etc.
> rausgeführt.

Der 6UL(L) hat weder USB3.0, noch LVDS, noch PCIe

Dergute W. schrieb:
> Bau unbedingt Ethernet (muss nicht unbedingt GBit sein, 10/100 reicht
> auch) dran,

Der "Controller" hat nur 10/100

> A propos: Hast du dich schon mal damit beschaeftigt, wie das Board zum
> ersten Mal in seinem Leben bootet, d.h. wenn im NOR-Flash noch kein
> u-boot usw. drinnensteht?

Steht im Reference Manual ;)
Boot from Fuses, Serial (USB), Internal (der "Controller" hat für sowas 
ein Boot-ROM)

Wenn's nicht unbedingt der 6ULL werden muss, würde ich mir die etwas 
"kleineren" RZ/A von Renesas ansehen:
400 MHz Cortex A9 (dürfte etwa die selbe Leistung haben wie der A7 im 
6UL(L)), bis zu 10 MiB RAM intern, mehr Schnittstellen und gibt's noch 
im QFP
https://www.renesas.com/en-eu/products/microcontro...
Linux: https://github.com/renesas-rz

: Bearbeitet durch User
Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Kommentare.
Ich habe aber nicht vor die Diskussion bezgl. Kondensatoren zu fördern.
Deshalb dazu von mir keine Bemerkungen.

Update:

So ein kurzes Update von meiner Seite.

Der vanilla mainline Linux Kernel läuft auf meinem Demoboard.
Es musste lediglich die config umgestellt werden. Neu ist diese jetzt
imx_v6_v7

Ich frage mich noch, ab wann denn Linux wirklich läuft.
Kann man das vollständige Booten des Kernels und den Übergang in den 
Userspace als Erfolg ansehen? Oder bedeutet dies noch garnichts?
Ich konnte auch die busybox nutzen.

Das u-boot läuft mit dem unbearbeiteten Code noch nicht auf dem Board.
Es scheint so als ob einige Treiber erweitert wurden. Grundsätzlich 
kennt uboot den imx6 und auch mein evk aber. Es hat also bereit die 
entsprechenden configs etc in den ordnern.

Nun, das ich momentan noch auf das modifizierte U-Boot setzen muss stört 
mich nicht so sehr. Habe allerdings begonnen, die fehlenden Dateien ins 
neue U-Boot zu mergen. Fragt sich, wie ich das am besten sichere wenns 
denn läuft. Soll man da einen pull request ans offizielle git repo 
machen?

Nächste Schritte:

- Device Tree Source (DTS) ein wenig anpassen und mal die Änderungen 
sehen. z.B. Uart vertauschen etc.

Dazu eine Frage, in dem Device Tree stehen oft solche Codeteile:
 pinctrl_i2c2: i2c2grp {
    fsl,pins = <
      MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
      MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
    >;
  }; 

Oft mit PAD.
Ich vermute dies ist freescale spezifisch und das hat da jemand so 
definiert.

Weiss jemand, ob es zu deren DTS Files bzw zu dem ganzen Konstrukt 
welches sie da aufgebaut haben auch eine Doku gibt?

Wenn ich späte meine eigenen DTS Files schreiben muss, würde ich gerne 
wissen, was bereits vorhanden ist und was ich noch selbst schreiben 
muss.

Danke schonmal

: Bearbeitet durch User
Autor: Gerd E. (robberknight)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Ich frage mich noch, ab wann denn Linux wirklich läuft.
> Kann man das vollständige Booten des Kernels und den Übergang in den
> Userspace als Erfolg ansehen? Oder bedeutet dies noch garnichts?
> Ich konnte auch die busybox nutzen.

Von diesem Level aus weiteren Userspace-Code zum Laufen zu bekommen ist 
nicht schwer. Am einfachsten bedienst Du Dich bei einer fertigen 
Distribution, Du kannst das aber natürlich auch selbst machen. Wirkliche 
Showstopper sind auf dieser Ebene für Dein Projekt eigentlich nicht mehr 
zu erwarten.

Spannender ist dagegen ob Du alle von Dir benötigte Peripherie 
ansprechen kannst. Also ob die Treiber vorhanden sind, richtig 
konfiguriert sind (device tree) und sie dann auch sauber funktionieren. 
Das kann schon kniffeliger werden, vor allem wenn da irgendwo Bugs drin 
sind.

Mach Dir also ne Liste was da für Dich wichtig ist (z.b. USB-Host, UART, 
I2C, PWM,...) und teste Punkt für Punkt ob das funktioniert.

Hier musst Du Dir auch Gedanken über die Alternate Functions der 
einzelnen Pins machen und wohin Du welche Pins routest. Daher würde ich 
mich in diesen Punkt einarbeiten bevor Du mit dem Schaltplan anfängst.

Auch wenn Du später Dein eigenes Layout am Laufen hast willst Du solche 
Tests schon fertig haben und mit den Ergebnissen vom Evalboard 
vergleichen.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Ich frage mich noch, ab wann denn Linux wirklich läuft.
> Kann man das vollständige Booten des Kernels und den Übergang in den
> Userspace als Erfolg ansehen? Oder bedeutet dies noch garnichts?
> Ich konnte auch die busybox nutzen.

Den hässlichen Teil hast du dann schon mal geschafft. Bootmeldungen vom 
Kerne und dann eine Shell. Dann hast du ordentliche Debugmöglichkeiten.

Holger K. schrieb:
> Nun, das ich momentan noch auf das modifizierte U-Boot setzen muss stört
> mich nicht so sehr. Habe allerdings begonnen, die fehlenden Dateien ins
> neue U-Boot zu mergen. Fragt sich, wie ich das am besten sichere wenns
> denn läuft. Soll man da einen pull request ans offizielle git repo
> machen?

Ja, das ist der beste Weg. Bedingt aber die Bereitschaft sich mit der 
Community auseinanderzusetzen und sich an deren Regeln zu halten.

Holger K. schrieb:
> Dazu eine Frage, in dem Device Tree stehen oft solche Codeteile:
>  pinctrl_i2c2: i2c2grp {
>     fsl,pins = <
>       MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
>       MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
>     >;
>   };
> Oft mit PAD.
> Ich vermute dies ist freescale spezifisch und das hat da jemand so
> definiert.
>
> Weiss jemand, ob es zu deren DTS Files bzw zu dem ganzen Konstrukt
> welches sie da aufgebaut haben auch eine Doku gibt?

https://git.kernel.org/cgit/linux/kernel/git/stabl...

Ich könnte dich im Bereich Hardware (Schaltplan) als auch im Bereich 
Software unterstützen. Näheres gerne per PN.

Gruß
Matthias

Autor: Andi B. (andi_b2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> ...
> Dazu eine Frage, in dem Device Tree stehen oft solche Codeteile:
>  pinctrl_i2c2: i2c2grp {
>     fsl,pins = <
>       MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
>       MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
>     >;
>   };
> Oft mit PAD.
> Ich vermute dies ist freescale spezifisch und das hat da jemand so
> definiert.
> ...

Da gibt's ein Pins Tools von Freescale um das Pin mapping, drive 
strength, pull up/downs ... zu definieren. Für den i.MX7 spuckt das dann 
ein .dtsi file aus. Die i.MX6 Varianten werden auch unterstützt. Ich 
nehme an, dass ist das was du da brauchst. Und deren BSP und die Treiber 
darin werden wohl da drauf aufbauen.

Händisch würde ich da die ganzen Register nicht beschreiben wollen. 
Zumindest nicht beim 7er. 6er kenn' ich nicht darum mit Vorbehalt. HTH

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andi B. schrieb:
> Da gibt's ein Pins Tools von Freescale um das Pin mapping, drive
> strength, pull up/downs ... zu definieren. Für den i.MX7 spuckt das dann
> ein .dtsi file aus.

Genial!

Andi B. schrieb:
> Händisch würde ich da die ganzen Register nicht beschreiben wollen.
> Zumindest nicht beim 7er. 6er kenn' ich nicht darum mit Vorbehalt.

Dacht ichs mir schon, dass dies ja extremst Fehleranfällig wäre.
Ich schaue mir mal das Pin Tool an. Danke für den Input.

Evtl. lohnt es sich, wenn ich der NXP Community mal anfrage, welches der 
beste/effizienteste Ansatz ist, um ein eigenes, neues Board zu 
integrieren und die zugehörigen Dinge wie Device Tree zu erstellen.

Update:
Aktuell weiterhin studium der Software.
Armbian sieht noch interessant aus. Wäre eventuell eine Portierung wert.
Dürfte nicht all zu kompliziert werden, da bereits andere imx6 
unterstützt werden.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So wieder ein Update:

Aktuell beschäftige ich mich intensiv mit Linux und der ganzen 
Infrastruktur. Ich habs hinbekommen, dass das Display es EVK mit dem 
mainline Kernel läuft. Nun wollte ich uboot dazu bringen, von tftp zu 
booten, damit ich nicht immer alles auf die SD kopieren muss.

Leider hats bei der defaultconfig massig einstellungen fürs uboot dazu.
Alls ich diese ändern wollte und mit buildroot make uboot-rebuild 
angebe, ignoriert buildroot leider meine Änderungen. Ein make clean; 
make geht zwar dauert aber gut 20 Minuten. Deshalb ist diese Baustelle 
vorerst on-Hold.

Paralell dazu habe ich mich begonnen zu informieren, wie man denn Apps 
für die Platform schreiben kann. Es braucht natürlich eine eigene 
Toolchain. Also hab ich hurtig die von buildroot heruntergeladene 
toolchain linaro in ein fixes Verzeichnis kopiert und buildroot 
angewiesen diese zu verwenden. Leider musste ich wieder make clean und 
make machen. Hat aber geklappt.

Nun wollte ich ein paar kleinere Programme erstellen um diese auf dem 
Board laufen lassen zu können. QT-Creator scheint ja sehr verbreitet zu 
sein. Also nach einem tutorial gesucht. Und schwups sind wieder zig 
Stunden weg. Bisher kein Erfolg. habe hier einen neuen Thread mit den 
Problemen eröffnet. Beitrag "glibc mit Linaro toolchain für ARM"

Langsam kommt das Gesamtbild. Es sind ettliche Baustellen welche 
bearbeitet werden müssen. Aber ich bin drauf und dran den Karren zum 
laufen zu kriegen!

Nächste Ziele:
 - QT Umgebung erfolgreich einrichten
 - QT Programm schreiben und testen
 - uboot abstrippen und nur das nötigste behalten
 - uboot für tftp konfigurieren
 - uboot mit kernel ins Flash
 - rootfs auf karte
 - Neues Board mit einer Aufnahme für das jetzige i.MX6 ComputeModul
   Dies dient dazu als erstes mit einer funktionierenden Hardware 
(Prozessorboard) eine neue Peripherie (andere Phys etc) zu unterstützen.
   Das bedeutet auch neue dts Files etc erstellen

 - Am ende dann ein neues Board Layouten
 - Änderungen wie dts files etc in den mainline kernel  uboot  QT 
aufnehmen lassen

 - Dokumentation veröffentlichen. Diese erstelle ich übrigens für mich 
selbst paralell dazu. Dies dient für mich als Nachschlagewerk da ich bei 
so enorm viel neuem Wissen auf einmal ansonsten den Überblick verlieren 
würde.

Autor: Mw En (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uboot ist doch eigentlich recht einfach.
Erstmal mit "make <deine_plattform>" die Plattform einstellen, dann make 
all.
Dann uboot auf das System kopieren und Booten, die Einstellungen dann 
über die serielle Konsole vornemen:
U-Boot> setenv autoload yes
U-Boot> setenv autostart yes
U-Boot> setenv bootfile <kernelimage_datei>
U-Boot> setenv serverip <server_IP>
U-Boot> setenv loadaddr <adresse_wo_platz_ist>
U-Boot> saveenv

Idealer wäre ein DHCP Server welcher direkt TFT IP und Kernelimage 
Dateiname announced.

Autor: Robert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> uboot ist doch eigentlich recht einfach.
> Erstmal mit "make <deine_plattform>" die Plattform einstellen, dann make
> all.
> Dann uboot auf das System kopieren und Booten, die Einstellungen dann
> über die serielle Konsole vornemen:
> U-Boot> setenv autoload yes
> U-Boot> setenv autostart yes
> U-Boot> setenv bootfile <kernelimage_datei>
> U-Boot> setenv serverip <server_IP>
> U-Boot> setenv loadaddr <adresse_wo_platz_ist>
> U-Boot> saveenv
>
> Idealer wäre ein DHCP Server welcher direkt TFT IP und Kernelimage
> Dateiname announced.

Der Spaß mit U-Boot fängt genau dann an, wenn man Custom Hardware am 
Start hat und kein fertiges Dev-Board.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der Spaß mit U-Boot fängt genau dann an, wenn man Custom Hardware am
> Start hat und kein fertiges Dev-Board.

Aktuell habe ich aber noch ein fertiges Dev-Board

Mw E. schrieb:
> uboot ist doch eigentlich recht einfach.
> Erstmal mit "make <deine_plattform>" die Plattform einstellen, dann make
> all.

Das hab ich versucht. Hatte aber damals noch nicht geklappt.
Kann aber sein, dass ich einen Fehler gemacht habe. Werde ich auf 
jedenfall wiederholen.


Update:

Aktuell kämpfe ich weiterhin mit der Erzeugung der QT-Libraries für das 
Dev-Board. Es ist unglaublich wie viel Zeit für eine solch banale 
Aufgabe gebraucht wird. Immer wenn man meint es geht weiter, kommt ein 
ERROR...

Hier ist der aktuelle Problem Thread: 
Beitrag "QT für ARM unter Ubuntu compilieren. Linker fehler."

Autor: Robin R. (elec-lisper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Es ist unglaublich wie viel Zeit für eine solch banale
> Aufgabe gebraucht wird. Immer wenn man meint es geht weiter, kommt ein
> ERROR...

Das ist leider ganz normal, und überhaupt nicht banal.  Ich arbeite 
Hauptberuflich mit sowas, und es geht gut und gerne mal 2-3 volle Tage 
in sowas. Hab schon mal 1 Tag in die Kompilierung des 
Oracle-Datenbank-Backends von Qt gesteckt. Oder fast eine ganze Woche 
bislang um Boost und POCO unter Windows so kompiliert zu bekommen wie 
wir das Brauchen.  Qt ist zwar sehr gut, und prinzipiell macht es fast 
weniger Probleme als sagen wir mal Boost, aber letztendlich ist Qt eine 
große Bibliothek mit vielen kleinen komplexen stellen die gerne mal 
rumzicken.

Gerade weil das alles Arbeit ist gibt es ja Linux Distributionen mit 
binären Paketen (apt-get usw. usf.). Da wird die Arbeit von den 
Maintainern gemacht.  Auch wenn es mit Build-Systemen wie qmake, cmake 
und autotools/autoconf "configure" einfacher ist ein Projekt zu 
übersetzen, so muss man immer noch für seine Plattform/Umgebung die 
richtigen Optionen finden.  Und manchmal gibt es dann eben noch Fehler, 
die einfach nicht behebbar sind, weil man gerade über einen echten 
Fehler in der Bibliothek gestolpert ist.

Ist immer auch ganz abhängig davon, wie oft der jeweilige Pfad 
(X86/Linux, X64/Windows/MSCV, ARM ...) schon beschritten wurde. Dann 
wurden nämlich die ganzen Probleme, über die man unter einer bestimmten 
Umgebung stolpert, schon in das "configure"-Script bzw. das cmake-File 
eingebaut und abgefangen.


Ist Qt für dich ein so wichtiges Ziel, oder reicht es nicht erstmal aus
wenn du ne glibc, C++ und bspw. SDL übersetzt bekommst? Damit kann man
später auch schon ne Menge machen und Qt läuft dir ja prinzipiell
erstmal nicht weg. Dein Ziel ist doch ein eigenes Board?

Autor: Laowhy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welches EVB verwendest Du da eigentlich? Das imx6rex board?

http://www.imx6rex.com/

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin R. schrieb:
> Das ist leider ganz normal, und überhaupt nicht banal.

Das ist leider so.

Robin R. schrieb:
> Ist Qt für dich ein so wichtiges Ziel, oder reicht es nicht erstmal aus
> wenn du ne glibc, C++ und bspw. SDL übersetzt bekommst?

Nun, es ist eines meiner Ziele, dem späteren Anwender, eine einfache 
Möglichkeit zu zeigen, wie man eigene Applikationen mit GUI entwickeln 
kann. Es ist zudem etwas das ich selbst noch nicht gemacht habe und 
daher gerne versuchen würde.

Ansonsten gibt es aus meiner Sicht nicht mehr sehr viele Anwendungen bei 
welchen der einsatz eines solch leistungsfähigen Board sinnvoll ist, 
wenn man keine optische Ausgabe in Form eines Displays (welcher Art auch 
immer, also auch HDMI etc) hat. Oder kennt jemand Anwendungen wo ein 
solches Board Sinn macht ohne ein TFT o.ä.?

Ich habs übrigens hinbekommen QTbase zu kompilieren. Es war ein banaler 
pfad fehler. Nun werde ich heute Abend weiter machen mit der Einrichtung 
von QTCreator. Ich hoffe auf wenige Probleme, das ich dann zügig die 
Applikation auf dem Display sehen werde.

Dann gehts wieder weiter mit uboot konfig und laden aus dem Flash.
Ich hab das nochmals versucht mit uboot und tftp. Hab den kernel ins 
flash kopiert und ab adresse 0x80000000 plus 0x8000 gestartet. Ging 
leider nicht. Die Adresse hab ich aus dem Datenblatt der Offsett stand 
im Netz. Muss mich hier nochmals einarbeiten.

Robin R. schrieb:
> SDL übersetzt bekommst? Damit kann man
> später auch schon ne Menge machen

SDL kenn ich noch garnicht. Evtl. würde dies bereits genügen für 
einfache GUIs?

Robin R. schrieb:
> Dein Ziel ist doch ein eigenes Board?

Definitiv! Und das wird auch kommen. Ich fände es einfach frustrierend, 
wenn ich dann das Board habe aber überhaupt keine Ahnung davon, wie es 
inbetrieb zu nehmen ist. Daher möchte ich zuerst die notwendigen 
Grundlagen erarbeiten damit ich dann auch weiss wie es weiter geht.

Wie gesagt, die Hardware macht mir weniger sorgen, da ich mich mit 
sowas, vorallem dem Layout, auskenne.

Beim Schema wirds vermutlich noch ein paar Fragen geben können.

Laowhy schrieb:
> Welches EVB verwendest Du da eigentlich? Das imx6rex board?

Nein es ist ein offizielles von NXP.
http://www.mouser.com/images/microsites/MCIMX6UL1.jpg

Das imx6ul evk


UPDATE:
Bin dabei QT zum laufen zu bekommen.
QTBase konnte ich kompillieren. Heute abend gehts weiter mit dem 
Tutorial und der eigenen Applikation.

Dann gehts weiter mit uboot etc. wie weiter oben beschrieben.

Autor: Robin R. (elec-lisper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Robin R. schrieb:
>> Ist Qt für dich ein so wichtiges Ziel, oder reicht es nicht erstmal aus
>> wenn du ne glibc, C++ und bspw. SDL übersetzt bekommst?
[...]
> Ansonsten gibt es aus meiner Sicht nicht mehr sehr viele Anwendungen bei
> welchen der einsatz eines solch leistungsfähigen Board sinnvoll ist,
> wenn man keine optische Ausgabe in Form eines Displays (welcher Art auch
> immer, also auch HDMI etc) hat.
[...]

Ja, ich stimme dir voll zu, dass mit vernünftigen 
High-Level-Bibliotheken so ein Board erst richtig Sinn ergibt. 
Schließlich will man heute bei fast allen Embedded-Anwendungen nen 
Touch-Display oder wenigstes ein vernünftiges UI anzeigen. Da hilft Qt 
natürlich enorm.

Wenn das ein starkes Ziel ist, dann ist ja gut. In sowas kann man sich 
aber leider auch ziemlich verrennen und das Ziel aus den Augen 
verlieren.

> Robin R. schrieb:
>> SDL übersetzt bekommst? Damit kann man
>> später auch schon ne Menge machen
>
> SDL kenn ich noch garnicht. Evtl. würde dies bereits genügen für
> einfache GUIs?

SDL is wesentlich mehr Low-Level. Abstrahiert ein wenig den Zugriff auf 
Dinge wie Grafik- und Audio-Ausgabe. Hat auch Zusatzmodule zum 
Rasterisieren von TTF-Schriften und sowas. Damit kannst du praktisch 
deine eigene GUI-Bibliothek schreiben. Manche Spiele-Engines verwenden 
das. Und das wird auch von dem RF-ID-Terminal bei mir auf Arbeit, 
welches auf einem AMD Elan SC520 Chip basiert, als Hauptbibliothek für 
die Grafik-Ausgabe auf dem Punktmatrix-Display angeboten. (Da drauf 
läuft auch der Linux Kernel, so richtig mit TCP/IP und so - ist aber 
schon in die Jahre gekommen - haben wir nicht selbst gebaut, ich 
programmiere es nur).

>
> Robin R. schrieb:
>> Dein Ziel ist doch ein eigenes Board?
>
> Definitiv! Und das wird auch kommen. Ich fände es einfach frustrierend,
> wenn ich dann das Board habe aber überhaupt keine Ahnung davon, wie es
> inbetrieb zu nehmen ist. Daher möchte ich zuerst die notwendigen
> Grundlagen erarbeiten damit ich dann auch weiss wie es weiter geht.

Ja, das ist klar. Ist halt eine Frage was "inbetrieb nehmen" für einen 
bedeutet. Für mich würde es schon reichen, wenn Linux bootet und ich via 
SSH eine Shell bekomme. Qt ist halt nochmal eine Anforderung oben drauf. 
Und ich seh auch ein, dass man für ernsthafte und einigermaßen schnelle 
Softwareentwicklung für das Board eine ähnliche Bibliothek braucht - sei 
es nun Qt, Boost und/oder POCO - ohne sowas kann man halt keine 
Kundenanforderungen mit bezahlbarem Aufwand umsetzen. Alleine schon 
"eben mal in C++" ein PDF generieren oder eine HTTP-Abfrage machen wird 
da schon schnell sehr spannend (ohne Qt).

: Bearbeitet durch User
Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin R. schrieb:
> Ja, das ist klar. Ist halt eine Frage was "inbetrieb nehmen" für einen
> bedeutet. Für mich würde es schon reichen, wenn Linux bootet und ich via
> SSH eine Shell bekomme.

Klar mit einer shell über SSH ist schon gewonnen. Aber da fängts ja eben 
erst an.

Da ich mich mit der embedded linux welt noch nicht wirklich 
auseinandergesetzt habe, wollte ich das nun zuerst noch nachholen mit 
dem Eval board.

Robin R. schrieb:
> Alleine schon
> "eben mal in C++" ein PDF generieren oder eine HTTP-Abfrage machen wird
> da schon schnell sehr spannend (ohne Qt).

Da sehe ich wieder wie wenig Erfahrung ich mit diesen Dingen habe. Mir 
war noch gar nicht richtig bewusst, dass QT weit mehr als eine 
Bibliothek für das GUI ist. Es ist ja eine Bibliothek für fast alles und 
der QT-Creator die komplette Entwicklungsumgebung. Bemerkenswert was es 
da bereits alles gibt.

Autor: Dergute Weka (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Holger K. schrieb:
> Ansonsten gibt es aus meiner Sicht nicht mehr sehr viele Anwendungen bei
> welchen der einsatz eines solch leistungsfähigen Board sinnvoll ist,
> wenn man keine optische Ausgabe in Form eines Displays (welcher Art auch
> immer, also auch HDMI etc) hat. Oder kennt jemand Anwendungen wo ein
> solches Board Sinn macht ohne ein TFT o.ä.?

Da gibts schon einen Haufen Zeugs, wo man kein Display dafuer braucht. 
Wenn man z.b. Videostroeme verteilen, multiplexen, transcodieren will; 
wenn ein Webserver mal etwas mehr als nur eine statische HTML-Seite 
ausliefern soll,...usw. Es gibt durchaus Geraete, die rein per Web-GUI, 
snmp, oder sonstwie "bedient" werden und keinerlei 
Monitor(Video)anschluss brauchen.

Gruss
WK

Autor: Holger Krähenbühl (holgerkraehe)
Datum:
Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Videostroeme verteilen, multiplexen, transcodieren will;
> wenn ein Webserver mal etwas mehr als nur eine statische HTML-Seite
> ausliefern soll

Gut das stimmt.



Update:

So, habe es heute geschafft, den QT-Creator korrekt einzurichten.
gdb auf dem Board installier, ssh ebenfalls. Alle QT5 Libraries selbst 
kompiliert für arm und kopiert. Und eine erste, völlig primitive 
Anwendung erstellt. Und... es Läuft!

Proof ist im Anhang.

Morgen gehts weiter mit dem lieben uboot und tftp.
Bei uboot in der aktuell modifizierten Version, sind bereits massig 
befehle in der uboot.env enthalten. Ich möchte alles nicht benötigte 
entfernen.
Und idealerweise mit der mainline uboot arbeiten.

Wenn ich das geschaft habe, mache ich mich daran, ein neues Baseboard 
für das bestehende imx6 Modul zu erstellen. Ziel ist es zuerst die neue 
eigene HW zu  testen. Wenn ich dann soweit bin und für diese eigene dts 
files etc. geschrieben habe, dann erstelle ich das komplett neue Board.

Autor: Robin R. (elec-lisper)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> So, habe es heute geschafft, den QT-Creator korrekt einzurichten.
> gdb auf dem Board installier, ssh ebenfalls. Alle QT5 Libraries selbst
> kompiliert für arm und kopiert. Und eine erste, völlig primitive
> Anwendung erstellt. Und... es Läuft!
>
> Proof ist im Anhang.

Das is doch mal ein super Fortschritt. Woher nimmst du die
ganze Zeit? Keine Frau/Familie, Prokrastination oder Urlaub? ;-)

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robin R. schrieb:
> Das is doch mal ein super Fortschritt. Woher nimmst du die
> ganze Zeit? Keine Frau/Familie, Prokrastination oder Urlaub? ;-)

Nun das weiss ich manchmal selbst nicht so genau ;)
Man nimmt sich halt Zeit für sein Hobby. Ich arbeite nebenbei noch 100% 
und habe Frau aber keine Kinder. Und nein, die Frau fühlt sich nicht 
benachteiligt... :)

Urlaub ist bereits vorbei und einen zwanghaften Drang zum Aufschieben 
von dingen habe ich auch nicht :)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:

> Proof ist im Anhang.

Herzlichen Glückwunsch, damit hast du es ja schonmal bereits weit 
gebracht.
Je nachdem wie cool ich dein Board am Ende finde will ich vielleicht 
auch eins haben ;-)

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hattest du vor an Video I/O zu haben?
LVDS Port? Parallel RGB? HDMI? Oder doch vielleicht FPD-Link 3 (fände 
ich super cool)

Wäre schon schick aber, so ein LCD direkt vom Board zu treiben mit den 
passenden Reglern für die Hintergrundbeleichtung.

Autor: Holger Krähenbühl (holgerkraehe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Was hattest du vor an Video I/O zu haben?
> LVDS Port? Parallel RGB? HDMI? Oder doch vielleicht FPD-Link 3 (fände
> ich super cool)
>
> Wäre schon schick aber, so ein LCD direkt vom Board zu treiben mit den
> passenden Reglern für die Hintergrundbeleichtung.

Hallo Markus

Aktuell ist geplant ein SPI TFT direkt anzuschliessen.
Dieses mittels fbtft zu betreiben.


UPDATE:

Aktuell kämpfe ich noch mit der Soundausgabe auf dem eval board.
Ich habe inzwischen alle möglichen packages installier und das sdimage 
von 70MB auf über 200MB aufgeblasen. Leider hat gstreamer noch 
immernicht die richtigen plugins. Es fehlt ihm an autosink und pulsesink 
etc.

mit mpg123 konnte ich theoretisch ein File abspielen es kommt jedoch 
immer ein input/output error. gst-play-1.0 --list-devices zeigt mir aber 
mein device korrekt an.

Ich vermute es handelt sich um einen Fehler im device tree oder im 
treiber selbst.

Auf dem Evalboard ist ein wolfsn w8xxx Codec verbaut.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.