www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR32 grasshopper patch für ATMEL buildroot 2.2.1


Autor: Andreas Müller (schnitzeltony)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo grasshopper Freunde,

unter http://forum.embedded-projects.net/viewtopic.php?id=458 wurde ein 
patch für Buildroot von Atmel v2.2.0 vorgestellt. Auf dieser Basis habe 
ich für die am 08.10.2008 freigegebene Version 2.2.1 eine Version 
erstellt. Ich habe sie zunächst unter TFTP/NFS gebootet (das habe ich 
nach dem Desaster - siehe NFS mit grasshopper / AVR32 - voll im 
Griff :-), getestet und für sehr schön befunden. Anschließend habe ich 
sie unter Linux ins Flash geschrieben und kann bisher nichts negatives 
vermelden.

Zu Installation:
1. Buildroot von http://www.atmel.no/buildroot/buildroot-src.html 
downloaden und auspacken.
2. Den Patch drüber kopieren
3. make grasshopper_defconfig ausführen
4. make ausführen
5. lange warten

Folgendes ist anzumerken:
1. In Ermangelung einer Hardware, die mir ein Zurück im Falle eines 
Fehlers ermöglicht, konnte ich U-Boot nicht testen. Da sich hier seit 
der letzten Version (jetzt wird U-Boot 1.3.4 verwendet) eine Menge 
geändert hat, würde mich nicht wundern, wenn U-Boot nicht ordentlich 
funktioniert (ich habe auch die Teile für LCD-Ausgabe aus der STK1000 
eingepflegt). Für Tests, Rückmeldungen oder Korrekturen wäre ich sehr 
dankbar.
2. Ich habe an einigen  Stellen 'aufgeräumt': Die Unterstützung des 
'großen' ICNova ist weitgehend raus geflogen, weil ich keine Infos zu 
diesem Board gefunden habe. Nebenbei würde ich ein Buildroot-Update von 
In-Circuit / embedded-projects als service erwarten - aber das ist 
vielleicht naiv.
3. An einigen Stellen habe ich Hardware-Unterstützung vorbereitet. Die 
konnte ich bisher auch noch nicht testen (da muss ich erst mal den 
Lötkolben schwingen).
4. Interssanter weise findet sich schon die Unterstützung des aus 
Gerüchten bekannten AP7200 (USB-Host?). Auch finden sich schon teilweise 
Patches für Kernel 2.6.27 (ich habe gehört, der bekommt eine gesonderte 
Verwaltung für das interne RAM...).

Es bleibt spannend...

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als ursprünglicher Autor des Patches auf Embedded Projects möchte ich 
mich bei Andreas für die "Fortführung des Patches" bedanken und 
folgendes zu U-Boot anmerken.
Ich bin im Kampf mit einem Patch für U-Boot v1.3.4. Die 
DRAM-Initialisierung tut nicht so wie ich will. Sobald ich auf 32-bit 
Busbreite umstelle bekomme ich im U-Boot ca. jede Minute einen Reset 
bzw. NMI. Mit dem U-Boot für das NGW100 (mit einem kleinem Patch für 
Ethernet) läuft er Problemlos, dann allerdings nur mit 32MB Ram da nur 
16-Bit breit angebunden. Hat jemand eine Idee dazu?

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Deine Vorlage war Gold wert!!!
2. Wahrscheinlich hast Du Dich bereits umgesehen: die STK1002 
Implementierung ist auch 32 Bit breit. Vielleicht hilft das weiter.
3. In Deinem buildroot hattest Du in
make linux26-menuconfig
unter 'System Type and features'->'Atmel AVR32 AP options'->'AT32AP700x 
static memory bus width (16 bit)' angegeben (ich habe jedoch keinen 
relevanten Verweis auf die Variable AP700X_32_BIT_SMC finden können)
4. Hast Du mal meine Überarbeitung ausprobiert?

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,

> die STK1002 Implementierung ist auch 32 Bit breit.
Laut Schaltplan sogar mit den gleichen SRAM Chips. Doch sobald ich auch 
nur die Parametertabelle des STK1002 verwende (und die zusätzlichen Pins 
reserviere) passiert es. Allerdings habe ich noch nicht die Zeit 
gefunden mir den Code der DRAM Initialisierung anzusehen. Schalten die 
bei 32Bit den Watchdog ein???

Zu AP700X_32_BIT_SMC: Vom Linux wird verwendet was der U-Boot 
konfiguriert. Darum ist dieser Schalter vollkommen wirkungslos (soweit 
ich herausfinden konnte).

Zum Testen deines Patches bin ich noch nicht gekommen.

Werner

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Doch sobald ich auch nur die Parametertabelle des STK1002 verwende (und die 
>zusätzlichen Pins reserviere) passiert es.
Das alleine reicht nicht: In der Funktion board_early_init_f ist der 1. 
Parameter in portmux_enable_ebi die Busbreite. Hast Du hier 32 Bit?

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gibt es eigentlich einen Grund, dass das Board nicht direkt in den 
Kernel eingepflegt wird?

Also wieso kein Patch an die Mailingsliste geschickt wird, sodass das 
Board automatisch wie auch das ATNGW100 bzw. STK1000 oder inzwischen 
auch direkt verfügbar ist?

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@gast
Frag mal Atmel Norwegen, ob die daran Interesse haben, den grasshopper 
einzubringen bzw. zu pflegen.

@Werner:
1. Mein letzter Post war wohl etwas übereilt...
2. Welchen Schaltplan hast Du? Die einzigen, die ich von Atmel gefunden 
habe sind die STK1000 und STK1002. In der STK1000 finde ich nur einen 
Baustein mit 8MB (optional 16MB) RAM 32 Bit breit.

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Schaltplan des Grasshopper (Seite 3/7) stehen zwei MT48LC16M16A2.

In atstk1000.c von U-Boot for den stk1000
...
static const struct sdram_config sdram_config = {
#if defined(CONFIG_ATSTK1005) || defined(CONFIG_ATSTK1006)
  /* Dual MT48LC16M16A2-75 (64 MB) on daughterboard */
  .data_bits  = SDRAM_DATA_32BIT,
...

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Adreas,

während der Rechner im Hintergrund compiliert, habe ich mir einmal 
deinen  U-Boot Patch angesehen. Im wesentlichen entspricht er meiner 
Version.
Was auf jeden Fall fehlt ist der Reset des Ethernet PHY. Da bin ich 
damals auch erst darauf gestoßen als ich das Board am nächsten Morgen 
wieder unter Spannung gesetzt habe .... das Netzwerk ging nicht (mehr). 
Warum der Reset des PHY nicht einfach mit am normalen CPU Reset 
angeschlossen ist ???

Vor macb_eth_initialize(0, ... muss noch rein
#define PHY_RESET_PIN GPIO_PIN_PB(29)

  /* Grasshopper/ICNova specific */
        gpio_set_value(PHY_RESET_PIN, 0);
  udelay(100);
  gpio_set_value(PHY_RESET_PIN, 1);
  udelay(1000);

Da gerade eben noch Übersetzt wird konnte ich noch nicht testen, aber
es könnte sein dass die folgenden Headerfiles dann ebenfalls noch 
benötigt werden...
#include <asm/arch/memory-map.h>
#include <asm/io.h>

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Suuuper (Froi).

Dein u-Boot Patch mit meinem PHY Reset Patch funktioniert :-))

Allerdings musste ich den PHY Patch ein wenig überarbeiten.

Das gpio2.h ist im Anhang zu finden.
#ifdef CONFIG_CMD_NET

#define PHY_RESET_PIN GPIO_PIN_PB(29)

#include "gpio2.h"
#include <asm/arch/memory-map.h>
#include <asm/io.h>

int board_eth_init(bd_t *bi)
{
  /* Grasshopper/ICNova specific */

  void *base = pio_pin_to_port(PHY_RESET_PIN); 
  uint32_t mask = 1<< (PHY_RESET_PIN & 0x1F);

  if(!base) panic("Invalid GPIO pin %u\n", PHY_RESET_PIN);

  /* Prepare pin for output */
  writel(mask, (void *)base + PIO2_PER);
  writel(mask, (void *)base + PIO2_OER);
  writel(mask, (void *)base + PIO2_OWER);

  /* Reset the PHY */
  writel(mask, (void *)base + PIO2_CODR);
  udelay(100);
  writel(mask, (void *)base + PIO2_SODR);
  udelay(1000);

  macb_eth_initialize(0, (void *)MACB0_BASE, bi->bi_phy_id[0]);
  return 0;
}
#endif

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So soll es sein. Kannst Du trotz Freudentaumel die gpio2.h anhängen ;-)

Autor: Werner B. (werner-b)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das ist das Blöde an der Vorschau. Der Anhang ist danach weg.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Werner

ja ich gebe zu es ist nicht zwingend notwendig aber...

Ich habe Deinen Patch auf den Stil umgebaut, wie ich ihn in anderen 
Implementierungen gefunden habe. Dadurch wird er etwas schlanker und 
gpio2.h überflüssig.
#ifdef CONFIG_CMD_NET
int board_eth_init(bd_t *bi)
{
  /* Grasshopper/ICNova: the PHY reset Pin is controlled by PORTB[29]!!! */
  /* Prepare pin for output and reset PHY */
  portmux_select_gpio(PORTMUX_PORT_B, 1<<29, PORTMUX_DIR_OUTPUT | PORTMUX_DRIVE_LOW);
  udelay(100);
  pio_set_output_value(GPIO_PIN_PB(29), 1);
  udelay(1000);

  /* standard init */
  macb_eth_initialize(0, (void *)MACB0_BASE, bi->bi_phy_id[0]);
  return 0;
}
#endif // CONFIG_CMD_NET
Kannst Du den mal testen? Hierbei die Bitte, folgende Funktionen zu 
testen (ich denke, das ist der minimale Satz an Befehlen, den ich 
brauche, um wieder zu einem Linux zu kommen - wenn Du noch weitere 
testen kannst, schadet das sicherlich nichts...):

setenv
printenv
tftp und/oder dhcp
bootm

Sollte Dein Test erfolgreich sein, kann ich es wagen, den Bootloader 
unter Linux zu flashen, weitere Test machen, einen neuen Patch 
vorzubereiten und mal die Fühler ausstrecken, was zu tun ist, damit 
Atmel/DENX den grasshopper in ihre Quellen aufnehmen.

Autor: Werner B. (werner-b)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,

> ...Stil umgebaut...
ist so OK. Ich hätte nur gerne die "29" als #define. Man sieht somit 
sofort dass die (1<<29) und die 29 im pio_set_output_value() 
zusammengehören und nicht nur zufällig den geleichen Wert haben. Zudem 
"wenn jemand auf die Idee kommt den Pin zu verlegen" muss man nur an 
einer Stelle ändern.

U-Boot ist auf meiner Seite in dieser Form OK.
setenv/askenv: OK, aber nicht bis auf die 64kB des ENV ausgereizt.
printenv: OKI, zeigt sogar noch die "Ur-"Einstellungen aus der Fabrik 
(soweit nicht geändert).

dhcp, tftp und nfs getestet, und ohne bootm würde ja gar nicht laufen 
;-)

Das einzige das "Müll" anzeigt ist bdinfo. Das tut es aber beim NGW100 
auch.

Und wenn du im Linux die Einstellung von
   CONFIG_MMC_BLOCK=m
in
   CONFIG_MMC_BLOCK=y
änderst, kann man auch von einer SD Karte booten.

P.S.
Vielleicht kannst du auch noch mein MAC aus der grasshopper_defconfig 
rausnehmen. Sonst hat irgendwann fast jeder GH die gleiche MAC. ;-)

PPS.
Im Anhang der  linux-2.6.27.grasshopper.1.patch. Hier schon mit 
CONFIG_MMC_BLOCK=y   ;-)

Autor: Andreas Müller (schnitzeltony)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Werner,

>Ich hätte nur gerne die "29" als #define
#ifdef CONFIG_CMD_NET
int board_eth_init(bd_t *bi)
{
  /* Grasshopper/ICNova: the PHY reset Pin is controlled by PORTB[29]!!! */
  #define PHY_RESET_PIN_NO 29
  /* Prepare pin for output and reset PHY */
  portmux_select_gpio(PORTMUX_PORT_B, 1<<PHY_RESET_PIN_NO, PORTMUX_DIR_OUTPUT | PORTMUX_DRIVE_LOW);
  udelay(100);
  pio_set_output_value(GPIO_PIN_PB(PHY_RESET_PIN_NO), 1);
  udelay(1000);

  /* standard init */
  macb_eth_initialize(0, (void *)MACB0_BASE, bi->bi_phy_id[0]);
  return 0;
}
#endif // CONFIG_CMD_NET
>CONFIG_MMC_BLOCK=y
Ist drin
>Vielleicht kannst du auch noch mein MAC aus der grasshopper_defconfig
>rausnehmen. Sonst hat irgendwann fast jeder GH die gleiche MAC. ;-)
Geändert (das ist sicherlich nicht im Sinne der Erfinder, dass ein Rudel 
von Geräten die gleiche MAC haben...)
>Im Anhang der  linux-2.6.27.grasshopper.1.patch. Hier schon mit
>CONFIG_MMC_BLOCK=y   ;-)
Habe ich im angehängten Patch mit rein genommen, kompiliert und unter 
TFTP/NFS gebootet - sieht gut aus. Nachteil hieran ist, dass die Atmel 
Patches wg. der geänderten Versionsnummer fehlen. Wenn Atmel das 
Buildroot mit dem neuen Kernel rausgibt haben wir das schon mal...

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Atmel Patches fließen schon seit längerem direkt in die 
Kernelentwicklung ein. Da der Final 2.6.27 erst wenige Wochen alt ist 
dürfte es nur sehr wenige neue Patches geben.
Jedenfalls ist im 2.6.27 ein (im Vergleich zum 2.6.25.10-Atmel) neuer 
Patch drin mit dem man endlich auch große Files auf SD schreiben kann 
ohne dass sich die MCI Schnittstelle abhängt. ;#)

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wieder was gelernt - siehe 
http://avr32linux.org/twiki/bin/view/Main/LinuxKernel (oder anderswo? - 
das Anfängersyndrom: die Dichte der eingehenden Information ist zu groß 
:-)

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo (ich schon wieder),

habe mal mit dem Kernel 2.6.27 rum gespielt (Boot aus Flash oder 
TFTP/NFS -> gleiche Symptome):
1. Im Verlauf des Boot-Vorgangs fängt die LED2 asynchron zu LED1 an zu 
blinken. Zunächst habe ich das für ein Feature gehalten aber
2. Im Verlauf von Debug-Sitzungen mit AVR32Studio (Standard wie in 
Application Note AVR32015 beschrieben-SSH/FTP) schmiert der kleine 
gnadenlos ab.
Mein Fazit: So (noch) nicht zu empfehlen.

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem kann ich hier nicht nachvollziehen.

A) Ich vermute mal du hat nicht alles von vorne herein mit dem Kernel 
2.6.27 "gebaut". Ich habe nach "grasshopper_defconfig" schon vor dem 
ersten Build mit "menuconfig" auf Kernel Version 2.6.27 umgestellt. (
B) Oder es fehlen einfach die Pull-Up's an den SD-Karten Pins. Da du 
dort nichts angeschlossen hast, solltest du die Unterstützung dafür in 
deinem Kernel doch besser deaktivieren.

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A) habe ich genauso gemacht
B) ich habe bisher nur den nackten grasshopper. Werde mal die SD-Karten 
Untertützung deaktivieren. Was mich allerdings wundert: Den 'alten' 
Kernel habe ich auch mit SD-Karten-Unterstützng getestet...

Hast Du wirklich keinen weiteren Patch verwendet?

Autor: Werner B. (werner-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Den 'alten' Kernel habe ich auch mit SD-Karten-Unterstützng getestet...

Mit 'CONFIG_MMC_BLOCK=y' oder 'CONFIG_MMC_BLOCK=*'?

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Werner,

CONFIG_MMC_BLOCK=y bei beiden Varianten (wie von Dir vorgeschlagen)

Autor: sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin gerade übersetzten der Version 2.2.1 und habe den oben genannten 
Patch verwendet. Nach längerer Zeit kommt dieser dann zur Anwendung, 
meldet jedoch einen Fehler:

buildroot-avr32-v2.2.1.tar.bz2
buildroot-v2.2.1-grasshopper-v0.0.3.tar.gz

Applying u-boot-1.3.4-grasshopper.1.patch using plaintext:
patching file board/atmel/grasshopper/config.mk
patching file board/atmel/grasshopper/grasshopper.c
patching file board/atmel/grasshopper/Makefile
patching file board/atmel/grasshopper/u-boot.lds
patching file include/configs/grasshopper.h
patching file Makefile
Hunk #1 FAILED at 2914.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
Patch failed!  Please fix u-boot-1.3.4-grasshopper.1.patch!

Hier noch die Makefile.rej:

***************
*** 2914,2919 ****
  atstk1006_config  :  unconfig
    @$(MKCONFIG) $(@:_config=) avr32 at32ap atstk1000 atmel at32ap700x

  favr-32-ezkit_config  :  unconfig
    @$(MKCONFIG) $(@:_config=) avr32 at32ap favr-32-ezkit earthlcd 
at32ap700x

--- 2914,2922 ----
  atstk1006_config  :  unconfig
    @$(MKCONFIG) $(@:_config=) avr32 at32ap atstk1000 atmel at32ap700x

+ grasshopper_config  :  unconfig
+   @$(MKCONFIG) $(@:_config=) avr32 at32ap grasshopper atmel at32ap700x
+
  favr-32-ezkit_config  :  unconfig
    @$(MKCONFIG) $(@:_config=) avr32 at32ap favr-32-ezkit earthlcd 
at32ap700x

Kann mir jemand bei dem Problem weiterhelfen?


Danke,
sebastian

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sebastian,

ist schon seltsam...

Es sollte eine Datei Makefile.orig (oder so ähnlich) erstellt worden 
sein. Auch hilfreich ist die Datei '.applied_patches_list' Kannst Du die 
mal als Anhang posten?

Wird in Deinem Buildroot versucht, U-Boot Version 1.3.4 zu erstellen?

P.S. Liege in den letzten Zügen beim Patch für buildroot 2.3.0-rc1. Bin 
ja mal gespannt...

Autor: sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir kamen die Fehlermeldungen auch sehr komisch vor. Daraufhin habe ich 
nochmals neu entpackt und make über Nacht laufen lassen. Heute morgen 
war der build dann vollständing.

Ich vermute das beim Entpacken etwas schief gegangen ist. Modifiziert 
habe ich keine der Dateien.

Bis dann,
Sebastian

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probleme, die sich von selbst lösen sind mir immer die liebsten :-)

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle,

Ich habe mich an einem Patch für buildroot 2.3.0 versucht, nur leider 
scheitere ich an der verzwickten Ordnerstruktur. Ich habs geschafft 
defconfig usw anzulegen und auch herausgefunden wie ich den Kernel 
soweit anpasse -> Andreas' Datein nach 
project_build_avr32/..-./linux-xx/arch/board/grasshopperxxx/ und 
Makefiles angepasst. Ich glaub das habe ich noch alles "richtig" 
gemacht. Aber wie erstelle ich jetzt den Patch um ihn als kernel-patch 
im target/device.../kernel-patch unterzubringen?

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

zu Deiner Mail:

Bitte poste in Zukunft die Anfragen ins Forum, weil

1. es sicherlich eine Menge Leute gibt, die von der Sache deutlich mehr 
verstehen als ich (hatte im August meinen ersten Linux-Kontakt)
2. Diejenigen, die das gleiche Problem haben, auch davon profitieren
3. ich zu meiner Schande gestehen muss, dass ich z.Zt häufiger in den 
Foren nach sehe, als meine Mails zu lesen (bitte kein Kommentar).

Ich vermute, Du hast die Kernelkonfiguration mit dem Namen 
grasshopper_devel_config nicht in der Patch Datei für den Kernel (bei 
V2.2.1 war das linux-2.6.27.grasshopper.1.patch) eingetragen. Dann weiß 
buildroot nicht, wie es den Kernel konfigurieren soll und motzt. Das 
ganze passiert bei UBoot, weil der zuerst kompiliert wird (wie gesagt 
alles Vermutung).

Zu Deiner jetzigen Anfrage: Ich habe den Eindruck, wir machen beide das 
gleiche, weil ich für 2.3.0 zwei defconfigs vorgesehen habe:
1. So wie bisher
2. mit LCD/keyboard/PWM/mplayer/samba

Das dumme ist nur, dass die zweite konfiguration noch komische Dinge 
macht (kompilieren ist OK aber der Hüpfer 'humpelt' anstatt zu hüpfen)

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael

ich hatte Deine letzte Frage nicht wirklich beantwortet:
1. Schau Dir den Inhalt von target/device/Atmel/grasshopper/*.patch  mit 
einem Texteditor an
2. man diff
3. Wenn ich eine neue Datei in einen vorhandenen Patch einfügen will, 
gebe ich folgendes an: diff -rupN /dev/null NeueDatei > aaa. Den Inhalt 
der Datei kopiere ich dann mit überarbeitetem Header in den vorhandenen 
Patch (wenn jemand weiß, wie das einfacher geht bitte melden)

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,

das mit dem PN und Forum ist immer so ein zweischneidiges Schwert. 
Gerade wenn es so eine "spezielle" Frage ist finde ich ist eine PM 
angebrachter.

Ja wir machen wahrscheinlich das selbe :) Habe im freaks-Forum schon 
gesehn das du dran bist. Trotzdem wollte ich es "einmal" für mich 
durchmachen um es dann für weitere Projekt bereits zu können.
Eventuell wäre es von Vorteil, wenn das Wiki dahingehend versucht wird 
so zu erweitern um alle nötigen Schritte nachvollziehen zu können.
Die "defvonfig" usw anzulegen ist ja relativ straight forward. Aber 
sobalds am Kernel frickeln geht wirds ungut. Woher hast du deine Infos 
genommen?.

Gerade das mit dem Patch verstehe ich ned, so wie ich den Patch lese 
veränderst du das atngw100 Verzeichnis. Kann das sein?

Danke schonmal für die Antwort mit dem Patch, soweit ich das verstehe 
kann man das mit quilt "relativ" einfach lösen.

Gruß
Michael

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

also:
Die einzigen Änderungen am Kernel finden sich am Ende des Patches: In 
KConfig (für kernel menuconfig: die Doku zu menuconfig findet sich in 
buildroot-avr32-v2.3.0-rc1/project_build_avr32/grasshopper/linux-2.6.27. 
6/Documentation)  und Makefile (damit der Compiler die board abhängigen 
Dateien auch kompiliert - eine einführende Doku findet sich in 
SelfLinux) wird der grasshopper in buildroot eingeklinkt.
Alle anderen Dateien werden unterhalb des Verzeichnisses 
project_build_avr32 erzeugt. Eine Datei, die erzeugt wird erkennt man 
daran, dass im Datenbereich nur '+' Einträge zu finden sind ('-' heißt 
entfernen / ohne Vorzeichen findet eine Stelle in einer Datei).
Lass Dich nicht durch die NGW Verweise verwirren: Du könntest da 
beliebige Verzeichnisse eintragen. Diese Information sagt nur, wie der 
Patch (ursprunglich) erstellt worden ist.
Und damit kommen wir auch gleich dazu, woher ich meine Info habe: Den 
wesentlichen Teil des Patches hat werner (siehe weiter oben) erstellt. 
Frag den mal :-)
Ach - bevor ich's vergesse: Rudimentär beschreibt 'AVR32005 AVR32 AP7 
How to add a custom board to Buildroot' wie wo was einzutragen ist.

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle,

So bin gerade nochmal dazugekommen mir das mit dem Patch erstellen 
anzusehen.
jetzt hab ich es begriffen glaub ich :)
Mir hat http://www.linuxchix.org/content/courses/kernel_ha... 
sehr gut auf die Sprünge geholfen. Jetzt kann ich mich an den schweren 
Part machen, das wirkliche anpassen der Kernel Datein.
Vielen Dank nochmal Andreas.

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir funktioniert buildroot 2.2.1 zusammen mit dem Patch 0.0.3 nicht.

Nach einer Weile wird libglib entpackt, das kompilieren schlägt fehl. 
Und das, obwohl libglib eindeutig nicht benötigt wird und auch nicht 
angewählt ist unter "select packages for the target".

Fehlermeldung:

echo "#ifndef __G_MARSHAL_H__" > xgen-gmh \
  && echo "#define __G_MARSHAL_H__" >> xgen-gmh \
  && /usr/bin/glib-genmarshal --nostdinc --prefix=g_cclosure_marshal 
./gmarshal.list --header >> xgen-gmh \
  && echo "#endif /* _G_MARSHAL_H_ */" >> xgen-gmh \
  && (cmp -s xgen-gmh gmarshal.h 2>/dev/null || cp xgen-gmh gmarshal.h) 
\
  && rm -f xgen-gmh xgen-gmh~ \
  && echo timestamp > stamp-gmarshal.h
/bin/bash: line 2: /usr/bin/glib-genmarshal: No such file or directory

Autor: Andreas Müller (schnitzeltony)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles nur Vermutung :-)
Buildroot erstellt zunächst die Umgebung, um cross-compilieren zu 
können. Es wird mindestens ein gcc (und vieles mehr) erzeugt. Dazu ist 
allerdings eine gcc mit allerlei Tools auf deinen Entwicklungsrechner 
notwendig.
Ich vermute Buildroot braucht glib auf deinem Entwicklungssystem (es 
wird ja auch '/usr/bin/glib-genmarshal: No such file or directory' 
angemeckert).
Befrag mal Deinen Paketmanager...

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit apt-get install libglib2.0-dev geht's erstmal weiter, mal sehen, wie 
weit...

Das Insekt kann einen wirklich in Atem halten.

Demnächst geht's bei mir mit dem ABDAC weiter, da hört man ja auch schon 
von einigen Problemen mit einem aktuellen Kernel.

Autor: Michael B. (bubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
Auszug aus ner Mail aus Liste:

>PPS! Users of AC97 and ABDAC must stay at Buildroot for AVR32 v2.2.1
>since this release does not support these sound devices with the new
>kernel 2.6.27.6.atmel.1. We have changed to the real deal DMA
>framework, and still have some work to do with the sound drivers.
>Hopefully I will have something ready early next year. The good side
>is that the sound drivers will be ready for submission into upstream
>Linux.

Wenn du bei 2.2.1 bleibst und nicht auf den neuen Kernel updatest 
solltest du keine Probleme bekommen

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.