ARM7 und Ubuntu?

...falls nicht alle Linien von der Flut verwischt wurden, könnten sich auch einige Bugs eingeschlichen haben ...

mfG Leo

Reply to
Leo Baumann
Loading thread data ...

Am 28.08.2009, 20:34 Uhr, schrieb Marte Schwarz :

Hm, also ich würde mal auf

formatting link
vorbeischauen und nach dem ELDK für ARM suchen. Da drin gibt es Linux-Portierungen für diverse ARM-Prozessoren. Wir selber haben das für den Intel PXA250 bzw. 255 (XScale) genutzt. Keine Ahnung, wie das für Deinen ARM7 aussieht, aber die Chancen stehen gut, denke ich. Guckstdu:
formatting link

Ansgar

--
*** Musik! ***
Reply to
Ansgar Strickerschmidt

Hi Ansgar

ich will nicht wirklich ein LINUX für den ARM7 portieren, unter Linux einfachere Sachen für den ARM7 zu stricken reicht mir noch lange

Marte

Reply to
Marte Schwarz

Am 15.09.2009, 15:15 Uhr, schrieb Marte Schwarz :

Du musst da nix neu portieren (wenn Du Glück hast). Da gibt es für etliche ARMs bereits fertige Embedded-Linux-Umgebungen, mit denen Du arbeiten kannst. Also fertiger Kernel zum Kompilieren samt Entwicklungsumgebung, samt Cross-Compile-Tools etc. Auch U-Boot als Bootloader ist dabei. Musst nur ggf. mit "make menuconfig" das Passende zusammenstellen.

Ansgar

--
*** Musik! ***
Reply to
Ansgar Strickerschmidt

Marte Schwarz schrieb:

binutils für arm kompileren: (ob arm7...12, ist hier noch wurscht, kann man hinterher beim kompilieren als Option angeben)

auspacken: tar -xjf binutils-xyz.bz2 ./configure --target=arm-elf make make install

gcc/g++ auspacken ABER NOCH NICHT kompilieren!!! tar -xjf gcc-xyz.bz2

Dann suche man sich eine C-Library aus, z.B. newlib Diese entsprechenden Pfade werden in die Verzeichnisstruktur des GCC kopiert oder verlinkt (ln -s)

dann erst! ./configure --target=arm-elf make make install

und eigentlich sollte sich dann arm-elf-g++ main.cpp -o machdoch ausführen lassen. Wie jetzt arm7 code rauskommt, müßte ich nochmal nachschauen. -mmcu=?? Findest Du sicherlich auch in der gcc- Doku.

Zum debuggen dann open-ocd mit z.B. einem Olimex jtag Adapter benutzen. Als Oberfläche verwende ich üblicherwiese DDD.

Soweit sollte das eigentlich funktionieren. Probleme gibts ggf. beim Download des Code/Daten ins Target, wenn open-ocd das Flash nicht kennt. Da musste dann selber 'nen Flashtreiber stricken. Sollte aber bei den üblichen Flasches nach AMD- oder Intel- Standard kein Problem werden. STM und andere haben nach meiner Erfahrung immer eines der oben genannten Kommando-Sets zum Programmieren/Löschen. Ggf. Speichermapping anpassen (Seitengröße/Partitionen der Flashes)

Und das Du ein entsprechendes Linkerscript an Dein Speichermapping schreiben must, ist eigentlich klar. Denn woher soll der Linker wissen, wo bei dir RAM/ROM/IO usw. liegt.

Ganz einfach, wenn man weiß, wie es geht :-)

Hoffe es hilft für den Einstieg.

Reply to
Klaus Rudolph

Hi Klaus,

OK, der Urlaub lief auch ohne µC und eigentlich auch fast komplett ohne PC. Auch gut.

Ganz ehrlich, beim Lesen wird mir schon fast schwindlig, ich nehm dann doch lieber was fertiges ;-)

Marte

Reply to
Marte Schwarz

Marte Schwarz schrieb:

Na wenn es genauso einfach ist, würde ich das auch machen ;) Du kannst uns ja mal berichten!

Reply to
Klaus Rudolph

Am 15.09.2009, 15:39 Uhr, schrieb Klaus Rudolph :

Das ist bei den BSP's im erwähnten ELDK von DENX bereits drin; wenn keines davon passt, kann man sich ja ein weitgehend passendes als Vorlage nehmen und relativ leicht an eigene Bedürfnisse anpassen.

Wir verwenden hier @work übrigens den Abatron BDI2000 als BDM-Tool; ich finde den für diese Zwecke ganz brauchbar, da einfach über ein Textfile zu konfigurieren, wo die Speicherbereiche sein sollen. Es gibt da freilich auch noch anderes Werkzeug. Aber vielleicht hat ja $OP Zugriff auf sowas.

Ansgar

--
*** Musik! ***
Reply to
Ansgar Strickerschmidt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.