mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Start-Hilfe zu buildroot für AT91RM9200 auch hier?


Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
=> boot
TFTP from server 10.201.49.43; our IP address is 10.201.49.129
Filename 'at91rm9200df-linux-2.6.27.7.gz'.
Load address: 0x20800000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##########################################################
done
Bytes transferred = 2624500 (280bf4 hex)
## Booting image at 20800000 ...
   Image Name:   Linux-2.6.27.7
   Created:      2008-12-10  11:20:42 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2624436 Bytes =  2.5 MB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux......................................................................
................................................................... 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

Autor: Jörn Kaipf (joern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:...

Ich schau heute Abend in meiner Buildroot Konfiguration nach.

Viel Erfolg
Jörn

Autor: Ulrich P. (uprinz)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörn Kaipf (joern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ....

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörn Kaipf (joern)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörn Kaipf (joern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Idee: Übergibst du die MachID an den Kernel?

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
#include <asm/mach-types.h>

    .section  ".start", "ax"

    @ Atmel AT91RM9200-DK : 262
    mov  r3,  #(MACH_TYPE_AT91RM9200DK & 0xff)
    orr  r3, r3, #(MACH_TYPE_AT91RM9200DK & 0xff00)
    cmp  r7, r3
    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:
U-Boot 1.1.3 (Jul  4 2005 - 14:13:57)
U-Boot code: 20F00000 -> 20F1A880  BSS: -> 20F1EE60 RAM Configuration: Bank #0: 
20000000 16 MB Board: CMC-PU2 (Rittal GmbH) Flash:  8 MB 
In:    serial Out:   serial Err:   serial 
Hit any key to stop autoboot:  0 no DHCP ## Booting image at 10030000 ... Image Name:   ARM Linux-2.4.27
   Created:      2006-01-30  12:41:09 UTC
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    716596 Bytes = 699.8 kB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Starting kernel ...
Linux version 2.4.27-vrs1 (mkr@tq-sewsrv-4) (gcc version 3.3.3 (DENX ELDK 3.1. 13.3.3-9)) #42 Mon Jan 30 13:37:49 CET 2006

während der 2.6.x als unkomprimiert erkannt wird und sich dann nach dem 
Start selber auspackt?:
Bytes transferred = 1121896 (111e68 hex)
## Booting image at 20800000 ...
   Image Name:   Linux-2.6.24.7
   Created:      2008-12-10  20:59:00 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1121832 Bytes =  1.1 MB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux...............................................................
........... done, booting the kernel.

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...

Autor: Jörn Kaipf (joern)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...
>
#include <asm/mach-types.h>
> 
>     .section  ".start", "ax"
> 
>     @ Atmel AT91RM9200-DK : 262
>     mov  r3,  #(MACH_TYPE_AT91RM9200DK & 0xff)
>     orr  r3, r3, #(MACH_TYPE_AT91RM9200DK & 0xff00)
>     cmp  r7, r3
>     beq  99f
> 
>
> 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:
>
U-Boot 1.1.3 (Jul  4 2005 - 14:13:57)
> U-Boot code: 20F00000 -> 20F1A880  BSS: -> 20F1EE60 RAM Configuration:
> Bank #0:
> 20000000 16 MB Board: CMC-PU2 (Rittal GmbH) Flash:  8 MB
> In:    serial Out:   serial Err:   serial
> Hit any key to stop autoboot:  0 no DHCP ## Booting image at 10030000
> ... Image Name:   ARM Linux-2.4.27
>    Created:      2006-01-30  12:41:09 UTC
>    Image Type:   ARM Linux Kernel Image (gzip compressed)
>    Data Size:    716596 Bytes = 699.8 kB
>    Load Address: 20008000
>    Entry Point:  20008000
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
> Starting kernel ...
> Linux version 2.4.27-vrs1 (mkr@tq-sewsrv-4) (gcc version 3.3.3 (DENX
> ELDK 3.1. 13.3.3-9)) #42 Mon Jan 30 13:37:49 CET 2006
>
> während der 2.6.x als unkomprimiert erkannt wird und sich dann nach dem
> Start selber auspackt?:
>
Bytes transferred = 1121896 (111e68 hex)
> ## Booting image at 20800000 ...
>    Image Name:   Linux-2.6.24.7
>    Created:      2008-12-10  20:59:00 UTC
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    1121832 Bytes =  1.1 MB
>    Load Address: 20008000
>    Entry Point:  20008000
>    Verifying Checksum ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing
> Linux...............................................................
> ........... done, booting the kernel.
> 

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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
cmc_pu2      MACH_CMC_PU2    CMC_PU2      600
Jetzt muss ich meine Sachen wohl nur noch diesem MACH_TYPE zuordnen...

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Scheint, als hätte ich es noch nicht ganz geschafft...
Bytes transferred = 1136404 (115714 hex)
## Booting image at 20800000 ...
   Image Name:   Linux-2.6.24.7
   Created:      2008-12-10  23:01:28 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1136340 Bytes =  1.1 MB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux......................................
..................................... done, booting the kernel.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
## Booting image at 20800000 ...
   Image Name:   Linux-2.6.27.7
   Created:      2008-12-10  23:29:35 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1677548 Bytes =  1.6 MB
   Load Address: 20008000
   Entry Point:  20008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux...................................................
......................................................... 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 :)

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einen hab ich noch :)
  CC      arch/arm/kernel/module.o
  CC      arch/arm/kernel/io.o
  LD      arch/arm/kernel/built-in.o
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()
The function cpu_init() references
the function __init dump_cpu_info().
This is often because cpu_init lacks a __init 
annotation or the annotation of dump_cpu_info is wrong.
und noch einer
Wirft mir der Build aus. Da klemmt doch was in der init...
  CC      arch/arm/mach-at91/leds.o
  LD      arch/arm/mach-at91/built-in.o
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)
The variable cmcpu_flash_data references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* (see linux/init.h) or name the variable:
*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, 
*_console, 
Das hat vielleicht was mit der init für das NOR Flash zu tun?
  LD      drivers/mtd/devices/built-in.o
  CC      drivers/mtd/maps/physmap.o
drivers/mtd/maps/physmap.c:264:2: warning: #warning using PHYSMAP compat code
  LD      drivers/mtd/maps/built-in.o
Die ersten beiden tauchen dann bei
  AR      lib/lib.a
  LD      vmlinux.o
  MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x2b84): Section mismatch in reference from the function cpu_init() to the function .init.text:dump_cpu_info()
...
WARNING: vmlinux.o(.data+0x34c8): Section mismatch in reference from the variable cmcpu_flash_data to the (unknown reference) .init.data:(unknown)
The variable cmcpu_flash_data references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* (see linux/init.h) or name the variable:
*driver, *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, 

  GEN     .version
 wieder auf...
Wenigstens kann ich mit den letzteren beiden schon mal was anfangen, da 
steht ja was dabei, denke ich...

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Uncompressing Linux......................................................................
.......................................... done, booting the kernel.
Linux version 2.6.27.7 (de13798@de13798-laptop) (gcc version 4.2.4) #23 Thu Dec 11 21:08:25 CET 2008
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
Machine: Rittal CMC PU2
Memory policy: ECC disabled, Data cache writeback
Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4064
Kernel command line: root=/dev/nfs rw nfsroot=192.168.10.116: ethaddr=00:d0:93:1c:3c:65 ip=192.168.10.22:192.168.10.116::
  :CMC-TC-PU2::off console=ttyS0,9600 mtdparts=cmc_pu2:128k(uboot)ro,64k(environment),768k(linux),4096k(root),-
AT91: 96 gpio irqs in 3 banks
...
Danke an alle, die noch grübeln und Jörn, der auch geschrieben hat :)

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
10800350: 480f5594 00000403 08250855 d1f485db    .U.H....U.%.....
10800360: 41ed7465 00000000 00000000 55900000    et.A...........U
10800370: 5590480f 5590480f 0000480f ffff0000    .H.U.H.U.H......
10800380: ffffffff ffffffff ffffffff ffffffff    ................
10800390: ffffffff ffffffff ffffffff ffffffff    ................
108003a0: ffffffff ffffffff ffffffff ffffffff    ................
108003b0: ffffffff ffffffff ffffffff ffffffff    ................


es wurde bis 0x37f geschrieben.

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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