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-processors/arm-processors/i.mx-applications-processors/i.mx-6-processors/i.mx6qp/i.mx-6ull-single-core-processor-with-arm-cortex-a7-core:i.MX6ULL
MPN: MCIMX6Y2DVM05AA
Laut der Webseite von NXP steht da bei Memory:
1
16-bit LP-DDR2, DDR3/DDR3L
2
8/16-bit Parallel NOR FLASH / PSRAM
3
Dual-channel Quad-SPI NOR FLASH
4
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-82560BL-276702.pdf
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_S34ML02G1_S34ML04G1_1_Gbit_2_G-933041.pdf
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-guides/IMX6ULHDG.pdf
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.
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.
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
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
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...
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.
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.
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/phycore-imx-6-ul/?gclid=CLeT0LS0tdECFcLGGwodU8gDng
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
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.
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
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).
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
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
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 ;-)
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-processors/arm-processors/i.mx-applications-processors/i.mx-6-processors/i.mx6qp/evaluation-kit-for-the-i.mx-6ull-applications-processor:MCIMX6ULL-EVK> 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...
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.
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.
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 ;-)
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.
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.
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.
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?
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.
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.
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:SINGLE-CHIP-MODULE
Dann hat man schon einmal zwei Hürden weniger, günstig sind die aber
auch nicht und man kommt um HDI auch nicht herum.
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).
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.
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.
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-Bastelboards-mit-Allwinner-Chips-3592218.html
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
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?
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.
>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.
>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.
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.
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!
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.
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
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.
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
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...
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.
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.?
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 :-)
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.
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.
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.
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.
Holger K. schrieb:> No Y. schrieb:>> Zu Inspirationszwecken:>>> http://www.phytec.de/produkt/system-on-modules/phycore-imx-6-ul/?gclid=CLeT0LS0tdECFcLGGwodU8gDnghttp://www.variscite.com/products/system-on-module-som/cortex-a7/dart-6ul-freescale-imx-6ul
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/microcontrollers-microprocessors/rz.html
Linux: https://github.com/renesas-rz
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
1
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:
1
pinctrl_i2c2: i2c2grp {
2
fsl,pins = <
3
MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
4
MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
5
>;
6
};
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
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.
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/stable/linux-stable.git/tree/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt?id=refs/tags/v4.9.2
Ich könnte dich im Bereich Hardware (Schaltplan) als auch im Bereich
Software unterstützen. Näheres gerne per PN.
Gruß
Matthias
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
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.
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.
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.
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.
> 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."
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?
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.
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).
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.
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
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.
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? ;-)
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 :)
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 ;-)
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.
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.
Kurzes Update:
Habe zwischenzeitlich eine Pause eingelegt und bin aktuell dran, das
Schema zu zeichnen.
Alle Vorstudien mit Software auf dem Devboard sind abgeschlossen und
waren erfolgreich.
KLaus S. schrieb:> Moin,> gibt es hier schon was neues zu Berichten?>> Viele Grüße, Klaus
Hallo Klaus
Ja, inzwischen wurde ein eigenes Testboard (ähnlich dem Compute Module)
entwickelt und Software dafür erstellt.
rk schrieb:> 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.
Ich arbeite in einer Entwicklungsabteilung in der unter anderem auch
IMX6-Boards entworfen werden.
Ich denke, ich versteh ein bischen was vom Geschäft und meine Kollegen
sowieso. Wenn also brauchbare Rahmenbedingungen vorhanden sind, dann
sollte es gehen:
Zeit... viel Zeit. Rechne mit 2-3 Mannjahren @ 30h/Woche (Schaltplan,
Libs, Layout, keine Qualify-Messungen)
Software, die impedanzkontrolliertes Layout zuläßt.
Meßtechnik, mit der die Qualifymessungen am DDR3 etc durchführbar ist
SW-Leute, die derweil die Treiber schreiben und
Viel Zeit um die etlichen 1000 Seiten Doku zu dem Chip und den
angeschlossenen Bauteilen wie Speicher etc zu lesen.
Kollegen, mit denen man über die Bedeutungen dessen, was im Datenblatt
steht reden kann, die das Layout anschauen wenn es scheinbar nicht mehr
weitergeht und die auch sonst unterstützend mithelfen...
Ich will damit nicht sagen daß es für einen Hobbyisten nicht geht
aber... die Hürde ist schon sehr sehr hoch im Vergleich zu einem schon
etwas älteren AT91RM9200...
jetzt nur Gast
Hallo Holger!
Wie Siehts denn mit deinem board aus? ich denke auch über ein eigenes
iMX6 Board nach und durchlaufe gerade die gleichen schritte wie du. Hast
du deine Doku irgendwo veröffentlicht?
Simon S. schrieb:> Hallo Holger!>> Wie Siehts denn mit deinem board aus? ich denke auch über ein eigenes> iMX6 Board nach und durchlaufe gerade die gleichen schritte wie du. Hast> du deine Doku irgendwo veröffentlicht?
Hallo Simon
Das Board ist seit Juli 17 fertig und läuft.
Leider habe ich es bisher nicht geschafft, eine vollständige Doku zu
erstellen.
Gerne beantworte ich dir jedoch deine Fragen.
Gruss Holger.