Hallo zusammen!
Ich möchte gerne ein vorhandenes Controller-Board mit einem AT91RM9200,
8MB FLASH und 16MB RAM für andere Dinge zweckentfremden. Das Ding lehnt
sich zu einem guten Teil an das alte AT91RM9200DK an, hat aber keinen
Dataflash, sondern Parallel-FLASH.
Das darauf laufende Linux 2.4 wurde whkl mit ELDK erstellt, aber mit
letzterem komme ich irgendwie nicht gut zurecht. Alle Doku dazu bezieht
sich halt mehr auf MIPS und Kollegen.
OpenEmbedded und Angström werden hauptsächlich für Systeme mit Grafik
verwendet.
Also back to basics und buildroot scheint mein Favourit. Leider ist auf
www.at91.com sehr wenig los und der einzige wirkliche Helfer bislang
lebt in der USA. Ich kann also heute posten und habe mit etwas Glück
morgen eine Antwort...
Folgende Aufgabe soll gelöst werden ( mein persönliches Ziel)
Unter Ausnutzung des vorhandenen u-boot 1.1.5 oder 1.1.3 einen Kernel
via TFTP booten, der mind. dem Stand 2.6.24 entspricht.
Ursprünglich wollte ich gleich den latest-greatest verwenden ( 2.6.27.7)
da ich mich dabei wohl in recht viele Dinge einarbeiten muss. Also
gleich das aktuelle lernen. Allerdings scheint der 2.6.24 sehr viel
ausgereifter, weil vieles danach umgestellt wurde. Also Sollte mit
2.6.24 etwas zügiger ein Erfolgserlebnis zu erreichen sein.
Es gilt, ein rootfs zu erzeugen, dass im FLASH liegt und das online
schreiben erlaubt. Also kein RAMFS für die normalen Dateien. Logs und
alles andere sollten in einem RAMFS liegen.
Später soll eine/zwei Platte(n) ( IDE-Port ist vorhanden) angeschlossen
werden und das Dings als HTTP, SMB und SVN-Server genutzt werden.
Ich bekomme aktuell verschiedene Kernel gebacken, der TFTP Boot kommt
aber trotz richtiger Image Identifizierung nur bis 'Booting Linux.'
Als Besonderheit habe ich noch folgendes:
- DBGU steht nicht zur Verfügung, Console und Early Debug Messages
müssen über TTYS0,96008N1, was ich auch so in den builds vorgegeben
habe.
- Mit dem aktuellen buildroot kann ich kein JFFS mehr erzeugen, da ihm
eine acl.h fehlt. Diese hat mit den POSIX Berechtigungen zu tun, aber
wenn ich diese im kernel aktiviere, dann nützt das auch nix. Das gilt
aber nur für Kernel 2.6.27.7.
- Ich habe kein JTAG, wenn jemand weiß, wie ich mit dem OpenOCD-USB
Dongle den AT91RM9200, resp. sein angeschlossenes Flash neu
programmiere, dann immer her mit der Info, das wäre klasse um einen
u-boot-1.3.x mit Patch für meine Hardware drauf zu flashen. Sonst habe
ich leider nur einen Versuch...
Öh, ja, es muss Kernel 2.6 sein, da ich dort Treiberentwicklung machen
möchte, und daher fange ich nicht mehr mit dem ollen Kram an. Es hängt
aber kein Projekt dran, sondern persönlicher Ehrgeiz und der Wille zu
lernen und zu experimentieren.
So, es darf gepostet werden.
Gruß, Ulrich
Ok, das wohl zu allgemein...
Ich habe inzwischen für mein Board eine eigene board.c angelegt und alle
Besonderheiten wie Schnittstellen, Flash, LEDs und so weiter dort
angelegt und initialisiert.
Leider geht es nicht weiter als is dort:
1
=> boot
2
TFTP from server 10.201.49.43; our IP address is 10.201.49.129
................................................................... done, booting the kernel.
Ich habe auch angegeben, die LEDs per default auf ON zu initialisieren
und, um ganz sicher zu gehen, die LEDs abwechselnd auf Active_Low und
Active_High gesetzt. Ich weiß aber nicht, wann diese Initialisierung
durchgeführt wird. Die LEDs an meinem Board bleiben jedenfalls komplett
aus.
Hilfe... :(
Gruß, Ulrich
Spontan würde ich sagen, dass die Konsole nicht (richtig) initialisiert
ist, denn normalerweise kommen nach der Meldung "booting the kernel"
Nachrichten vom Bootprozess.
Sollte etwa so aussehen (unterer Bereich der Seite)
http://www.joernonline.de/dw/doku.php?id=projects:sam9_eval:1_sam9eval
Ich schau heute Abend in meiner Buildroot Konfiguration nach.
Viel Erfolg
Jörn
Hallo Jörn!
Ich habe inzwischen eine eigene Board-Datei gemacht, bei der ich die
physikalischen UARTs so vertausche, dass der USART0 im ARM dem ttys0
entspricht, der DBGU dem ttyS4, dazwischen die anderen verfügbaren
USARTs 1..3.
Was mir aber aufgefallen ist, ist das meine Initialisierung scheinbar
völlig an dem Kernel vorüber geht. Der Code wird compiliert und er
meckert auch Fehler darin an. Aber er wird bei der Initialsierung nicht
aufgerufen.
Beim Kernel-Build erhalte ich Warnungen, dass _init Funktionen
definiert, aber nicht zuegordnet werden können. Das ist mir bisher nicht
aufgefallen, weil es nur Warnungen sind, die nicht zum Abbruch führen.
Und ein > log 2>&1 habe ich noch nicht gemacht.
Ich nehme an, dass es durch die großen Umstellungen von 2.6.24 -> 2.6.27
im Kernel zu einem Problem kommt. Ich habe leider keine bereits auf
2.6.27 umgebaute Referenz gefunden.
Das YL9200er Board ist relativ spät dazu gekommen, daher habe ich mich
in weiten Teilen bei desem bedient. Aber vermutlich ist es immer noch
nicht aktuell genug für einen erfolgreichen 2.6.27er Build.
Da ich aber gerade neu einsteige in das Thema, wollte ich mich auf das
vorbereiten, was mich erwartet, nicht auf das, was mal war.
Ich zippe mal mein board.c, villeicht hilfts.
Ulrich
Gibst du dem Kernel die Konsole als Parameter mit? Lass dir mal von
UBoot die bootargs ausgeben und schau nach ob etwas von der Konsole drin
steht:
-->.... console=ttyS0,115200n8 ....
Jep, daran habe ich schon gedacht. Ich übergebe
console=ttyS0,$(baudrate)
im u-boot und auch als Kernelparameter irgendwo im make linux26-config
Wie gesagt, ich habe das auch entsprechend der ATMEL Idee bei der
Initialisierung so gedreht, dass der DBGU hinten ansteht und USART0 auch
ttyS0 ist.
Es wird vermutlich nicht daran liegen, sondern schon vorher schief
gehen, denn die LEDs leuchten nicht.
So. Ich hab hab grad mal meine Kernelconfig offen.
Unter "System Type"-> "Atmel AT91 System-on-Chip" -> Select a UART for
early kernel messages (DBGU) --> DBGU ausgewählt
Das war die einzige Einstellung, die ich zum Thema UART gefunden habe,
ab gesehen von dem Kernelparameter
Im Anhang noch meine Boarddatei.
Hi!
Mit der MachID bin ich noch nicht ganz durch. Ich hatte die manuell
eingetragen. Scheint aber, als würde die noch anderweitig auftauchen und
da fehlt sie, z.B. in der head-at91rm9200.S. Darin gibt es einige
Assembler Fetzen...
1
#include <asm/mach-types.h>
2
3
.section ".start", "ax"
4
5
@ Atmel AT91RM9200-DK : 262
6
mov r3, #(MACH_TYPE_AT91RM9200DK & 0xff)
7
orr r3, r3, #(MACH_TYPE_AT91RM9200DK & 0xff00)
8
cmp r7, r3
9
beq 99f
Ich vermute, da gibt es ein Script oder einen Leitfaden, wo und wie man
das machen muss. Ich neu, ich raten...
Mir ist auch aufgefallen, dass ATMEL immer die MT48er RAMs einsetzt, ich
habe aber IS42S16400B drauf. Könnte also noch ein Problem mit dem SDRAM
Controller sein.
Ist das eigentlich richtig, dass der alte 2.4.x Kernel vom u-boot als
komprimiert erkannt wird, dann ausgepackt und gestartet wird:
> Mit der MachID bin ich noch nicht ganz durch. Ich hatte die manuell> eingetragen. Scheint aber, als würde die noch anderweitig auftauchen und> da fehlt sie, z.B. in der head-at91rm9200.S. Darin gibt es einige> Assembler Fetzen...>
1
#include <asm/mach-types.h>
2
>
3
> .section ".start", "ax"
4
>
5
> @ Atmel AT91RM9200-DK : 262
6
> mov r3, #(MACH_TYPE_AT91RM9200DK & 0xff)
7
> orr r3, r3, #(MACH_TYPE_AT91RM9200DK & 0xff00)
8
> cmp r7, r3
9
> beq 99f
10
>
>> Ich vermute, da gibt es ein Script oder einen Leitfaden, wo und wie man> das machen muss. Ich neu, ich raten...
Ich glaube bei der MachID liegt der Hund begraben.Hol dir am besten eine
hier: http://www.arm.linux.org.uk/developer/machines/?action=new
Schau dir mal in der Kerneldoku (/Documentation/arm/) die Datei booting
an.
> Mir ist auch aufgefallen, dass ATMEL immer die MT48er RAMs einsetzt, ich> habe aber IS42S16400B drauf. Könnte also noch ein Problem mit dem SDRAM> Controller sein.
Auf meinem Board sind Qimonda Chips drauf. Mit denen tuts.
> Ist das eigentlich richtig, dass der alte 2.4.x Kernel vom u-boot als> komprimiert erkannt wird, dann ausgepackt und gestartet wird:>
Kann ich keine Aussage darüber treffen. Ich habe erst mit einem 2.6.X
Kernel angefangen und noch keinen 2.4.Xer benutzt.
> Und wie kann man im Buildroot nur den Kernel neu kompilieren... Das geht> bei einem 2.6.24er irgendwie anders als bei einem 2.6.27er...
Ich habe meinen Kernel in einem Projekt und benutzt aus der Buildroot
die zusammengebaute Toolchain.
Ok, dann warte ich jetzt mal darauf, dass arm.linux.org mir ein Login
schickt. Muss aber auch mal mit denen sprechen, die den alten Kernel
gebaut haben. Während die Modifikationen für das u-boot sauber zurück an
DLUG geflossen sind, wurde das beim Kernel etwas verpennt. Das würde ich
gerne ändern.
Ups... Die MachID gibt es tatsächlich schon:
1
cmc_pu2 MACH_CMC_PU2 CMC_PU2 600
Jetzt muss ich meine Sachen wohl nur noch diesem MACH_TYPE zuordnen...
Das gleiche Ergebnis diesmal mit dem 2.6.27.7 und dem Boardfile, dass
ich hier eingestellt hatte. Nur die MACH_TYPE wurde geändert auf
CMC_PU2, so wie sie aufgeführt wurde.
......................................................... done, booting the kernel.
Aber danke schon mal, ich bin sicher, dass ich jetzt schon ein Stück
weiter bin, auch wenn man es nicht sieht. Habe wieder was gelernt!
Gruß und gute Nacht, morgen mache ich weiter :)
WARNING: arch/arm/kernel/built-in.o(.text+0x26a4): Section mismatch in reference from the function cpu_init() to the function .init.text:dump_cpu_info()
5
The function cpu_init() references
6
the function __init dump_cpu_info().
7
This is often because cpu_init lacks a __init
8
annotation or the annotation of dump_cpu_info is wrong.
und noch einer
1
Wirft mir der Build aus. Da klemmt doch was in der init...
2
CC arch/arm/mach-at91/leds.o
3
LD arch/arm/mach-at91/built-in.o
4
WARNING: arch/arm/mach-at91/built-in.o(.data+0x21e4): Section mismatch in reference from the variable cmcpu_flash_data to the (unknown reference) .init.data:(unknown)
5
The variable cmcpu_flash_data references
6
the (unknown reference) __initdata (unknown)
7
If the reference is valid then annotate the
8
variable with __init* (see linux/init.h) or name the variable:
Kann es sein, dass das u-boot 1.1.3 / 1.1.5 noch keine MACH-ID an den zu
startenden Kernel meldet? Laut Doku ist das erst ab einem gewissen
Zeitpunkt Mandatory.
Kleines Update:
ES GEHT!
Die Lösung brachte ein Kontakt zu den Entwicklern des 2.4er Kernels und
der dezente Hinweis, dass der u-boot in der Version wohl noch einen
anderen ARCH_TYPE weitergibt. Ich habe das jetzt nicht verstanden, weil
ich dachte, dass der ARCH_TYPE die CPU und der MACH_TYPE das Board
definiert, aber nach auskommentieren des MACH_TYPE CMC_PU2 600 und dem
Austausch der AT91RM9200 251 gegen CMC_PU2 251 bootet das Teilchen und
fährt auch meine board.c ab, denn ich initalisiere darin die LEDs in
einem bestimmten Muster, und das liegt nun an.
Also bitte klärt mich mal auf, was da mit MACH und ARCH bei mir
durcheinander ist.
Ich versuche jetzt mal das Flash zu strukturieren und ein
Root-Filesystem hin zu bekommen.
Ich habe noch einen Kommentar zu Openocd.
Ich benutze einen AT91SAM9260 das ist nicht ganz das gleiche.
Vielleicht hilft dir dieser Trick:
Ich lade mit openocd mit dem Debugger uboot in dem RAM an die Adresse
0x20000000 und starte U-Boot im Ram und lade mit dem RAM gestartem
U-boot das gleiche U-boot.bin nach und schreibe das nachgeladene U-boot
in den Flash.
Das U_Boot hat sich im Grunde erst einmal erledigt. Ich hatte halt das
Problem, dass ich nicht wusste, warum mein Kernel nun so garnix macht.
Dann bekam ich den Tip von demjenigen, der das Uboot für unser Teil
geändert hat. Es war nicht die erwartete ARM CPU ID im Uboot. Nachdem
ich das wusste, und den Kernel entsprechend geändert hatte,
funktionierte der Kernel nahezu sofort.
Aber ich werde da noch einmmal drauf zurück kommen. Momentan liegt das
alles aus zeigründen etwas auf Eis. Der Kernel bootet durch, aber das
lokale und in buidlroot erzeugte FileSystem wird nicht akzeptiert. Wenn
ich per NFS das FS aus dem ELDK anspreche, funktioniert alles.
Ich komm noch mal drauf zurück.
Gruß, und Danke
Ulrich
U-boot intialisiert den Flash nicht. Zumindest ist das in der
Standardeinstellung für den AT91SAM9260 so.
Du musst im Static memory controller dein Flash anmelden.
Ich habe eine eigene Board.c geschrieben für mein Modul und die Flash
Sektionen werdem einwandfrei erkannt. Es werden auch die Dateien in den
Sektionen erkannt und gelesen. Es ist vielmehr ein Problem, dass
Buildroot die libc gegen einen anderen Kernel linkt, als den, den man
angibt. Jedenfalls kann ich im buildroot output immer wider was von
einem Kernel 2.6.8 lesen, dabei nutze ich den Kernel 2.6.28.
Das ganze Spiel endet damit, dass der Kernel einen Panik macht, weil der
consolen Prozess stirbt. Ist schon alles ein paar Tage her, daher hatte
ich das alles nicht mehr griffbereit.
Das uBoot selbst muss die CPU schon soweit initialisieren, dass es den
Flash lesen kann. Und das tut es auch. Aber beim Schreiben ist das bei
uns genutzte uBoot seeeehhhrr langsam. Das lässt auf ein größeres
Optimierngspotential schließen. Je länger ein Update-Prozess dauert,
desto größer die Gefahr, dass etwas schief geht. Und 10min für 3.5MB
sind viel zu viel.
Aber zuerst muss mal das Dateisystem, repektive die libc funktionieren.
Dann kommt der nächste Schritt. Und ein Kabel für JTAG auf Basis
openocd-usb ist auch schon in der Mache. Aber alles aktuell auf
kleinerer Flamme.
Ich bleib drann und melde hin und wieder den Status. Wer aber schon was
weiß oder einen Tip hat, immer her damit ich lese hier regelmäßig und
habe den Thread auch im abo.
Gruß, Ulrich
Ich habe gerade versucht auf meinen externen Flash mit openocd den
hinteren Speicherbereich zu beschreiben.
Im Configfile den Arbeitsspeicher openocd zur Verfügung stellen.
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x20000000
-work-area-size 0x010000000 -work-area-backup 1
Schreibschutz entfernen
flash protect 0 off
löschen
flash erase_sector 0 64 127
flash write bank 0 xa.bin 0x00800000
fängt an und bricht zumindest mit einer Fehlermeldung ab. Ich kann noch
nicht nachvollziehen wieviel geschrieben worden ist.
Thread beobachten
Seitenaufteilung abschalten