Forum: Mikrocontroller und Digitale Elektronik U-Boot erkennt DDR3-RAM nicht korrekt


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Habe hier ein eigenes Board mit einer Allwinner A13 CPU.
Habe für dieses Board nun ein u-boot compiliert und aufgespielt.
Ebenso habe ich den test auch mit einem u-boot bzw. Image von armbian 
durchgeführt.

Auf dem Board befindet sich ein 128Mx16 Memory.

Leider zeigt u-boot beim Starten folgendes an:
U-Boot SPL 2020.RC
DRAM: 0 MiB
### ERROR ### Please RESET the board ###

Nun kommt natürlich ein HW-Fehler sehr wahrscheinlich in Frage. Dazu 
hätte ich ein paar Fragen an die Experten unter euch.

1) Ich habe die Datenbits untereinander getauscht.
Was heist dies?: D0 = D0 | D1-D7 untereinander vertauscht
D8 = D8 | D9-D15 untereinander vertauscht.

Dies sollte m.M.n kein Problem darstellen. An anderere Stelle habe ich 
gelesen, dass das LSB teilweise zur Kalibration herangezogen wird. Daher 
D= = D0 und D8=D8.

2) Wie versucht u-boot die Speichergrösse zu bestimmen? Ich sehe an der 
diff. ClockLeitung zum DDR3 nach dem Start von u-boot keine Aktivität 
ausser dem wechsel von low (vermutlich unkonfigutiert) zu high. Dieser 
Pegel bleibt dann auch bestehen. Es findet kein Tatken o.Ä. statt. Ist 
dies plausibel?

- Die Beschaltung habe ich mehrfach geprüft. Sollte korrekt sein.
- Habe bereits viele BGA-96 aufgelötet. Bisher immer erfolgreich. Habe 
den Chip auch bereits zweimal gewechselt. Dabei immer das selbe 
Ergebnis. Daher denke ich mal nicht an einen Lötstellenfehler bzw. 
Kurzschluss.

Bin über Vorschläge dankbar.

Grüsse
Krähe

von Μαtthias W. (matthias) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi

Also meinen U-Booten geb ich die Speichergröße immer per

#define PHYS_SDRAM_SIZE      SZ_256M

mit. Automatisch kann das U-Boot meines Wissens nur wenn Speichermodule 
samt SPD-EEPROM verwendet werden.

Matthias

von habeichvergessen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
https://linux-sunxi.org/Mainline_U-Boot

Am Ende der Seite gibt es Hinweise zur SDRAM-Konfiguration in u-boot.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Antworten.

Μαtthias W. schrieb:
> Hi
>
> Also meinen U-Booten geb ich die Speichergröße immer per
>
> #define PHYS_SDRAM_SIZE      SZ_256M

Sehr interessant.
Das könnte sehr gut die Quelle des Übels sein.
Werde ich heute testen.

habeichvergessen schrieb:
> https://linux-sunxi.org/Mainline_U-Boot
>
> Am Ende der Seite gibt es Hinweise zur SDRAM-Konfiguration in u-boot.

Vielen Dank. Hab ich bereits gesehen. Mein U-Boot ist entsprechend 
deisem hier:
+S:CONFIG_DRAM_CLK=360
+S:CONFIG_DRAM_ZQ=123
+S:CONFIG_DRAM_EMR1=4
+S:CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y

Konfiguriert.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Μαtthias W. schrieb:
> Also meinen U-Booten geb ich die Speichergröße immer per
>
> #define PHYS_SDRAM_SIZE      SZ_256M

Du scheinst ein i.MX board zu verwenden, richtig?

Denn nach dem durchsuchen des u-boot git repos scheint dieses Define 
hauptsächlich in Zusammenhang mit i.MX Prozessoren verwendung zu 
finden...

Für Allwinner scheint es keine solche Einstellung zu geben... Bzw. 
verwendet z.B. Olimex keine solche Definition bei deren Allwinner 
Boards.

von Μαtthias W. (matthias) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Μαtthias W. schrieb:
>> Also meinen U-Booten geb ich die Speichergröße immer per
>>
>> #define PHYS_SDRAM_SIZE      SZ_256M
>
> Du scheinst ein i.MX board zu verwenden, richtig?
>
> Denn nach dem durchsuchen des u-boot git repos scheint dieses Define
> hauptsächlich in Zusammenhang mit i.MX Prozessoren verwendung zu
> finden...
>
> Für Allwinner scheint es keine solche Einstellung zu geben... Bzw.
> verwendet z.B. Olimex keine solche Definition bei deren Allwinner
> Boards.

Ja, ist ein iMX. War aber früher™ auch bei anderen ARM Systemen so. Bin 
aber ehrlich gesagt nicht auf dem Stand von 2016 vor der Verwendung von 
device tree und kconfig im U-Boot.

Matthias

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für deine Antwort.

Es scheint wirklich unauffindbar, wie in U-Boot die Speichergrösse 
angegeben wird.

Hier eine Beispielkonfiguration für ein Olimex A13 Board:

https://github.com/linux-sunxi/u-boot-sunxi/blob/0189be69ff8986f234c4183d241ff0fface50bd0/configs/A13-OLinuXinoM_defconfig

Da sieht man beispielsweise nichts vom RAM ausser:
CONFIG_DRAM_CLK=408
CONFIG_DRAM_EMR1=0
CONFIG_NR_DRAM_BANKS=1

Auch unter board/olimex/ lässt sich nichts zu einem Allwinner finden, 
wohl aber etwas für ein i.MX Board.

https://github.com/linux-sunxi/u-boot-sunxi/tree/d2faf46f3e5a7b42c69c226f5f5b54c6a5fea60d/board/olimex

Für das i.MX Board wurde die bereits erwähne Konfiguration vorgenommen:

https://github.com/linux-sunxi/u-boot-sunxi/blob/0b80e1c63d5ff9585c79afff1092cf761cea46cc/include/configs/mx23_olinuxino.h

Doch für das A13 Board findet sich nichts.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, dass u-boot das memory im Device-Tree erwartet?
 12         memory {

13                 linux,usable-memory = <0x80000000 0x1ff00000>,

14                                 <0xa0000000 0x1ff00000>;

15         };

Wobei mir dies unwahrscheinlich erscheint, da u-boot nichts mitteilt, 
dasss es bereits den fdt geladen hätte...

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Koennt' es sein, dass bei den Allwinners noch vor dem eigentlichen uboot 
ein SPL vorgeschaltet wird, der so Zeugs, wie SDRAM-Controller init 
macht?
<hibbelhibbel>Ach was freu' ich mich schon auf den naechsten 
Ramschkarton vom Pollin mit dem A20 Board drinnen</hibbelhibbel>

Gruss
WK

von Holger K. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Koennt' es sein, dass bei den Allwinners noch vor dem eigentlichen uboot
> ein SPL vorgeschaltet wird, der so Zeugs, wie SDRAM-Controller init
> macht?

Nun, u-boot wird tatsächlich mit einem SPL erzeugt. Daher würd ich mal 
sagen, ja.

Aber die frage ist, wo definiert ich nun die Memorygrösse?
Im SPL ja vemutlich. Aber bisher hab ich keinerlei Boardspezifische 
Files in den u-boot Sourcen ausfindig machen können.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Ich pushe mal den Thread :)

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
So ich bin etwas weiter gekommen.

In der Datei: board/sunxi/board.c

Gibt es folgenden code auf Zeile 669
  printf("DRAM:");
  gd->ram_size = sunxi_dram_init();
  printf(" %d MiB\n", (int)(gd->ram_size >> 20));
  if (!gd->ram_size)
    hang();

Dieser ist das Quell des Übels...
Die Funktion sunxi_dram_init sieht so aus:

[dram_sun5i_auto.c]
unsigned long sunxi_dram_init(void)
{
  return dramc_init(&dram_para);
}

Dann die dramc_init
[dram_sun4i.c:692]
unsigned long dramc_init(struct dram_para *para)
{
  unsigned long dram_size, actual_density;

  /* If the dram configuration is not provided, use a default */
  if (!para)
    return 0;

  /* if everything is known, then autodetection is not necessary */
  if (para->io_width && para->bus_width && para->density)
    return dramc_init_helper(para);

  /* try to autodetect the DRAM bus width and density */
  para->io_width  = 16;
  para->bus_width = 32;
#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN5I)
  /* only A0-A14 address lines on A10/A13, limiting max density to 4096 */
  para->density = 4096;
#else
  /* all A0-A15 address lines on A20, which allow density 8192 */
  para->density = 8192;
#endif

  dram_size = dramc_init_helper(para);
  if (!dram_size) {
    /* if 32-bit bus width failed, try 16-bit bus width instead */
    para->bus_width = 16;
    dram_size = dramc_init_helper(para);
    if (!dram_size) {
      /* if 16-bit bus width also failed, then bail out */
      return dram_size;
    }
  }

  /* check if we need to adjust the density */
  actual_density = (dram_size >> 17) * para->io_width / para->bus_width;

  if (actual_density != para->density) {
    /* update the density and re-initialize DRAM again */
    para->density = actual_density;
    dram_size = dramc_init_helper(para);
  }

  return dram_size;
}

Und schlussendlich noch die wichtige dramc_init_helper funktion

[dram_sun4i.c:561]
static unsigned long dramc_init_helper(struct dram_para *para)
{
  struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
  u32 reg_val;
  u32 density;
  int ret_val;

  /*
   * only single rank DDR3 is supported by this code even though the
   * hardware can theoretically support DDR2 and up to two ranks
   */
  if (para->type != DRAM_MEMORY_TYPE_DDR3 || para->rank_num != 1)
    return 0;

  /* setup DRAM relative clock */
  mctl_setup_dram_clock(para->clock, para->mbus_clock);

  /* Disable any pad power save control */
  mctl_disable_power_save();

  mctl_set_drive();

  /* dram clock off */
  dramc_clock_output_en(0);

#ifdef CONFIG_MACH_SUN4I
  /* select dram controller 1 */
  writel(DRAM_CSEL_MAGIC, &dram->csel);
#endif

  mctl_itm_disable();
  mctl_enable_dll0(para->tpr3);

  /* configure external DRAM */
  reg_val = DRAM_DCR_TYPE_DDR3;
  reg_val |= DRAM_DCR_IO_WIDTH(para->io_width >> 3);

  if (para->density == 256)
    density = DRAM_DCR_CHIP_DENSITY_256M;
  else if (para->density == 512)
    density = DRAM_DCR_CHIP_DENSITY_512M;
  else if (para->density == 1024)
    density = DRAM_DCR_CHIP_DENSITY_1024M;
  else if (para->density == 2048)
    density = DRAM_DCR_CHIP_DENSITY_2048M;
  else if (para->density == 4096)
    density = DRAM_DCR_CHIP_DENSITY_4096M;
  else if (para->density == 8192)
    density = DRAM_DCR_CHIP_DENSITY_8192M;
  else
    density = DRAM_DCR_CHIP_DENSITY_256M;

  reg_val |= DRAM_DCR_CHIP_DENSITY(density);
  reg_val |= DRAM_DCR_BUS_WIDTH((para->bus_width >> 3) - 1);
  reg_val |= DRAM_DCR_RANK_SEL(para->rank_num - 1);
  reg_val |= DRAM_DCR_CMD_RANK_ALL;
  reg_val |= DRAM_DCR_MODE(DRAM_DCR_MODE_INTERLEAVE);
  writel(reg_val, &dram->dcr);

  dramc_clock_output_en(1);

  mctl_set_impedance(para->zq, para->odt_en);

  mctl_set_cke_delay();

  mctl_ddr3_reset();

  udelay(1);

  await_bits_clear(&dram->ccr, DRAM_CCR_INIT);

  mctl_enable_dllx(para->tpr3);

  /* set refresh period */
  dramc_set_autorefresh_cycle(para->clock, density);

  /* set timing parameters */
  writel(para->tpr0, &dram->tpr0);
  writel(para->tpr1, &dram->tpr1);
  writel(para->tpr2, &dram->tpr2);

  reg_val = DRAM_MR_BURST_LENGTH(0x0);
#if (defined(CONFIG_MACH_SUN5I) || defined(CONFIG_MACH_SUN7I))
  reg_val |= DRAM_MR_POWER_DOWN;
#endif
  reg_val |= DRAM_MR_CAS_LAT(para->cas - 4);
  reg_val |= DRAM_MR_WRITE_RECOVERY(ddr3_write_recovery(para->clock));
  writel(reg_val, &dram->mr);

  writel(para->emr1, &dram->emr);
  writel(para->emr2, &dram->emr2);
  writel(para->emr3, &dram->emr3);

  /* disable drift compensation and set passive DQS window mode */
  clrsetbits_le32(&dram->ccr, DRAM_CCR_DQS_DRIFT_COMP, DRAM_CCR_DQS_GATE);

#ifdef CONFIG_MACH_SUN7I
  /* Command rate timing mode 2T & 1T */
  if (para->tpr4 & 0x1)
    setbits_le32(&dram->ccr, DRAM_CCR_COMMAND_RATE_1T);
#endif
  /* initialize external DRAM */
  mctl_ddr3_initialize();

  /* scan read pipe value */
  mctl_itm_enable();

  /* Hardware DQS gate training */
  ret_val = dramc_scan_readpipe();

  if (ret_val < 0)
    return 0;

  /* allow to override the DQS training results with a custom delay */
  if (para->dqs_gating_delay)
    mctl_set_dqs_gating_delay(0, para->dqs_gating_delay);

  /* set the DQS gating window type */
  if (para->active_windowing)
    clrbits_le32(&dram->ccr, DRAM_CCR_DQS_GATE);
  else
    setbits_le32(&dram->ccr, DRAM_CCR_DQS_GATE);

  mctl_itm_reset();

  /* configure all host port */
  mctl_configure_hostport();

  return get_ram_size((long *)PHYS_SDRAM_0, PHYS_SDRAM_0_SIZE);
}

get_ram_size ist übrigens in common/memsize.c:26 definiert


Offenbar wird hier sehrwohl der DDR-Clock aktiviert:
  /* setup DRAM relative clock */
  mctl_setup_dram_clock(para->clock, para->mbus_clock);

Das ich diesen nicht messen kann, irritiert mich ein wenig.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Das ich diesen nicht messen kann, irritiert mich ein wenig.

Mit was misst du denn "den"? So ein paar 100MHz bei ein paar zig 
Millivolt - das wird ja mit'm Phasenpruefer, Duspol oder der Zunge etwas 
schwierig ;-)

Gruss
WK

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:
> Holger K. schrieb:
>> Das ich diesen nicht messen kann, irritiert mich ein wenig.
>
> Mit was misst du denn "den"? So ein paar 100MHz bei ein paar zig
> Millivolt - das wird ja mit'm Phasenpruefer, Duspol oder der Zunge etwas
> schwierig ;-)
>
> Gruss
> WK

Danke für deine Antwort.

Aktuell messe ich dies mit einem Oszilloskop mit 200MHz Analogbandbreite 
sowie einem kapazitätsarmen Tastkopf.

von oszi40 (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Holger K. schrieb:
> Aktuell messe ich

Aktuell messe ich gar nicht und sehe was der SPD liefert. Das könnte man 
aber abschalten oder manipulieren. Manchmal lügt er auch. 
https://de.wikibooks.org/wiki/Computerhardware:_RAM:_Details:_SPD-ROM

von X2 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> Aktuell messe ich gar nicht und sehe was der SPD liefert. Das könnte man
> aber abschalten oder manipulieren. Manchmal lügt er auch.
> https://de.wikibooks.org/wiki/Computerhardware:_RAM:_Details:_SPD-ROM

Schonmal was von Memory Down gehört? Da gibt es normalerweise kein 
SPD-EEPROM, da es keinen Sinn macht...

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Tatsächlich habe ich bei meinem Embedded-Board kein SPD-EEPROM.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Hm, tja. Dann bin ich mit meinem Latein erstmal am Ende und beneide dich 
nicht um die Fehlersuche.

Gruss
Wolfram

von Holger K. (holgerkraehe)


Bewertung
2 lesenswert
nicht lesenswert
Soo, habe mir heute mal wieder Zeit genommen, mich diesem Thema zu 
widmen.

Ich habe nun herausgefunden, dass das DQS-Training fehlschlägt.
static int dramc_scan_readpipe(void)
{
  struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
  u32 reg_val;

  /* data training trigger */
  clrbits_le32(&dram->csr, DRAM_CSR_FAILED);
  setbits_le32(&dram->ccr, DRAM_CCR_DATA_TRAINING);

  /* check whether data training process has completed */
  await_bits_clear(&dram->ccr, DRAM_CCR_DATA_TRAINING);

  /* check data training result */
  reg_val = readl(&dram->csr);
  if (reg_val & DRAM_CSR_FAILED)
    return -1;

  return 0;
}
/* Hardware DQS gate training */
  ret_val = dramc_scan_readpipe();
//if (ret_val < 0)
  //  return 0;

Hier wird mir -1 geliefert.

Vielleicht hat ja jemand eine Idee, was man hier anpassen könnte?

: Bearbeitet durch User
von No Y. (noy)


Bewertung
0 lesenswert
nicht lesenswert
Mal Schaltplan und Layout posten...

von Holger K. (holgerkraehe)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Gute Idee!

von TR.OLL (Gast)


Bewertung
0 lesenswert
nicht lesenswert
U-Boote gehen auch ohne Arbeitsspeicher.

SCNR

von No Y. (noy)


Bewertung
0 lesenswert
nicht lesenswert
M8 und H1??

VREF alle auf GND?

Da sollte eigentlich ein Spannungsteiler hin der nciht überall auf GND 
gezogen ist...


Und ncoh einige andere Pins die irgendwie alle auf GND sind??

IC301A SVREF, IC300B VDD / VDDQ  alle GND?

C210 / C211


Wenn das kein Darstellungsfehler ist... Ich dachte du kannst sowas? 
Hattest du doch mal irgendwo geschrieben...

: Bearbeitet durch User
von Holger K. (holgerkraehe)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
sorry, da ging was schief mit dem PDF.
Hier bilder mit mehr informationen.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Ja, das Board ist Schaltungstechnisch fast 1:1 identisch mit dem Olimex 
A13 SOM. Mit der Ausnhamne, dass ich die Datenleitungen des RAMs nicht 
1:1 verbunden habe sondern innerhalb einer Lane D0..D7, D8..D15 geswapt 
habe...
Wobei ich hier jeweils das LSB (D0, D8) belassen habe, da dies scheinbar 
laut JEDEC für das Leveling verwendet wird.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
No Y. schrieb:
> Wenn das kein Darstellungsfehler ist... Ich dachte du kannst sowas?
> Hattest du doch mal irgendwo geschrieben...

Nun ja, ich dachte auch, dass ich sowas kann. Zumindest habe ich bereits 
einige vergleichbare Boards entworfen und zum funktionieren bekommen.

Schlussendlich kann man jedoch immer über Probleme stolppern...

von No Y. (noy)


Bewertung
0 lesenswert
nicht lesenswert
Ist Altium oder?
Wir nutzen Mentor daher bin ich mir da jetzt nciht ganz sicher.

Ist es bei Altium egal welches Symbol das Netz hat? Ich meine du hast am 
1.5v Schaltregler den Pfeil und überall woanders das "GND" Symbol. Ist 
also korrekt so? Nicht das es da Labelfehler oder so gab.

Ansonsten was mir auffällt ich finde deine Abblockkondensatoren Menge 
sehr grenzwertig für den RAM.

Wir packen da deutlich mehr dran...  Schau lieber nochmal ins Datenblatt 
deines RAM...

Wir haben auch eine Terminierung am ende der DRAM CLK...

Das tauschen der DQ Leitungen ist im prinzip ok.


Du solltest trotzdem mal DEINEN Schaltplan posten nciht den OLIMEX..
In der Schaltung da oben ist nämlich nichts geswapt wie du schreibst...


Besser wäre einen Spannungsteiler für RAM + CPU für die Ref Spannung zu 
haben...
So hast du mehrere und bist nciht sicher ob die alle die gleiche REF 
sehen..

: Bearbeitet durch User
von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
No Y. schrieb:
> Ist Altium oder?
> Wir nutzen Mentor daher bin ich mir da jetzt nciht ganz sicher.
>
> Ist es bei Altium egal welches Symbol das Netz hat? Ich meine du hast am
> 1.5v Schaltregler den Pfeil und überall woanders das "GND" Symbol. Ist
> also korrekt so? Nicht das es da Labelfehler oder so gab.

Danke für deine Antwort.

Ja, das ist irrelevant, welches Symbol da ist. Für Altium ist das nur ne 
Grafik. Der Name darüber ist der Netzname. Das stimm auf jeden Fall zu 
100%. Das hätte ich sonst beim Layouten bemerkt.

No Y. schrieb:
> Ansonsten was mir auffällt ich finde deine Abblockkondensatoren Menge
> sehr grenzwertig für den RAM.
>
> Wir packen da deutlich mehr dran...  Schau lieber nochmal ins Datenblatt
> deines RAM...

Das stimmt, die ist relativ niedrig. Habe auch mal versuchsweise mehr 
angehängt auf dem Board und zugleich auch noch die Spannungsstabilität 
mit dem Oszi geprüft. War soweit immer in Ordnung. geringe Einbrüche im 
Bereich von 5-10mV waren evtl. zu sehen. Wobei dies eher Rauschen war.

No Y. schrieb:
> Wir haben auch eine Terminierung am ende der DRAM CLK...
>
> Das tauschen der DQ Leitungen ist im prinzip ok.

Das mit der Terminierung könnte durchaus noch ein Punkt sein...
Habt ihr nur den CLK terminiert?

No Y. schrieb:
> Du solltest trotzdem mal DEINEN Schaltplan posten nciht den OLIMEX..
> In der Schaltung da oben ist nämlich nichts geswapt wie du schreibst...

Das ist mein Schaltplan, so wie das Board von mir umgesetzt wurde.
Doch doch, da ist schon geswapt. Die Netznamen sind der Reihe nach, die 
DRAM-Pins jedoch nicht...

No Y. schrieb:
> Besser wäre einen Spannungsteiler für RAM + CPU für die Ref Spannung zu
> haben...
> So hast du mehrere und bist nciht sicher ob die alle die gleiche REF
> sehen..

Ok ich sehe was du meinst. Das liesse sich ja durch ein 
Litzchen/Drähtchen schnell ändern...

von No Y. (noy)


Bewertung
0 lesenswert
nicht lesenswert
Sorry hab es jetzt gesehen, das die Nummerierung im "Symbol" geändert 
wurde..

Ja nur die CLK Terminiert. Mit jeweils 49.9 Ohm und 100nF gegen DDR 1.5V
Quasi T geschaltet...

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
No Y. schrieb:
> Ja nur die CLK Terminiert. Mit jeweils 49.9 Ohm und 100nF gegen DDR 1.5V
> Quasi T geschaltet...

macht ihr dann auch allwinner boards oder i.mx6?

von No Y. (noy)


Bewertung
0 lesenswert
nicht lesenswert
😁 hab in den Schaltplan vom i.MX6 geschaut.
Allwinner haben wir nicht.

Kann noch Rockchip und TI Sitara anbieten nachzuschauen.
Sowie andere i.MXer.




Hab mir auch nicht das Datenblatt deiner CPU angeschaut.




Und wenn Allwinner da nichts speziell gegen hat ist die Drehung der DQ 
definitiv i.o. im i.MX6 haben wir es ebenfalls gemacht.

: Bearbeitet durch User
von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für deine Unterstützung.

Das Datenblatt des A13 ist leider sehr dürftig.
Ich habe wirklich gehofft, dass ich das Teil so ans laufen kriege...

Ich werde nun also noch versuchen die Leitungen zu terminieren und die 
VREFs zu verbinden.

Sehr viel mehr fällt mir dann nicht mehr ein.

Am Ende werdens wohl die vertauschten Datenleitungen sein... Ich sehr 
bereits kommen...

von No Y. (noy)


Bewertung
0 lesenswert
nicht lesenswert
Nein DQ vertauschen ist ok. Haben wir beim i.MX6 auch gemacht. D0 und D8 
aber 1:1. Wenn die Chinesen daher bei Allwinner nicht das explizit 
ausgeschlossen haben sollte es gehen. Dann ist es ggf. doch UBoot 
Konfiguration. Aber da endet es bei mir. Hasse UBoot und wir verwenden 
fast überall Barebox.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
No Y. schrieb:
> Nein DQ vertauschen ist ok. Haben wir beim i.MX6 auch gemacht. D0
> und D8
> aber 1:1. Wenn die Chinesen daher bei Allwinner nicht das explizit
> ausgeschlossen haben sollte es gehen. Dann ist es ggf. doch UBoot
> Konfiguration. Aber da endet es bei mir. Hasse UBoot und wir verwenden
> fast überall Barebox.

Nun D0 und D8 hab ich ja auch 1:1. Leider ist die Doku derart dürftig, 
dass ich keinerlei Informationen diesbezüglich gefunden habe. Ich habe 
bei meinen Recherchen jedoch kein einizges Schema gefunden, bei welchem 
die Datenleitungen vertauscht wurden (Beim A13). Ich dachte mir, komm, 
einfach mal testen ^^...

Barebox kenn ich (noch) nicht. Den U-Boot Code habe ich inzwischen 
soweit mit printf's ausgestattet, dass ich exakt weiss, wo es hackt..

Nämlich genau hier:
  reg_val = readl(&dram->csr);
  if (reg_val & DRAM_CSR_FAILED)
    return -1;

  return 0;
Hier bekomme ich eine -1 retour, bzw. das DQS training ist 
fehlgeschlagen. Da kann U-Boot selbst nicht mehr viel dafür...

Ich gehe stark davon aus, dass es ein HW-Problem ist.

von guest (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Keine Ahnung ob man das beim Allwinner einstellen kann. Wir hatten bei 
unser eigenen HW mit i.MX mal ehebliche Probleme mit dem RAM bei zu 
hoher 'drive strength'.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Ja, soweit ich weiss, kennt der Allwiner eine solche Einstellung.
Vielleicht hilft es ja etwas.

von No Y. (noy)


Bewertung
0 lesenswert
nicht lesenswert
Hab mal bei unserem Chinesen (Rockchip) geschaut...

Auch hier CLK terminiert. Aber DQ getauscht. Sogar so das D8 auf D0 und 
D0 auf D8 rest ist durcheinander... Also aber nur durcheinander 
innerhalb DQ1-DQ7 sowie Gegenstück. Aber hast du ja auch entsprechend 
gemacht.

Aber auch hier die REF geht an RAM + Prozessor also selber 
Spannungsteiler..


Beim TI AM335 auch gedreht , selber spannungsteiler aber keine CLK 
Terminierung..

TI OMAP auch gedreht , selber refspannung, terminierung an clk + A pins.

I.MX7 Terminierung, gedreht, selber spannungsteiler...

Denke bei den ganzen anderen ist es auch so..

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
vielen Dank fürs nachschauen.

Somit sollte ich es mal mit CLK terminierung und mit gleichem 
spannungsteiler versuchen.

Wenns dann immer noch nicht geht, müssen es fast die Datenleitungen 
sein.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
Wenn es die CLK-Terminierung sein sollte, müsstest Du doch mit dem Oszi 
sehen, dass der da einen Takt ausgibt und dann Daten zurückkommen die 
nicht passen. Ohne Takt wird der Prozessor es schwer haben 
festzustellen, dass mit der Terminierung etwas nicht stimmt.

Auch wenn es die Vrefs sind, müssten erst mal etwas Daten fließen und 
die dann durch die Vrefs falsch interpretiert werden.

Bist Du Dir sicher daß es nicht stattdessen irgendeine Lötzinnbrücke 
unter dem IC oder ein ähnlicher Lötfehler auf Deinem Board ist? Ich 
hatte gestern erst wieder einen Widerstand, der trotz von oben ok 
aussehender Lötstelle keinen Kontakt zum Pad hatte...

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Wenn es die CLK-Terminierung sein sollte, müsstest Du doch mit dem Oszi
> sehen, dass der da einen Takt ausgibt und dann Daten zurückkommen die
> nicht passen.

Das hab ich mir eben auch gedacht.
Aber aus irgendeinem Grund, kommt da gar kein Takt.

Gerd E. schrieb:
> Bist Du Dir sicher daß es nicht stattdessen irgendeine Lötzinnbrücke
> unter dem IC oder ein ähnlicher Lötfehler auf Deinem Board ist? Ich
> hatte gestern erst wieder einen Widerstand, der trotz von oben ok
> aussehender Lötstelle keinen Kontakt zum Pad hatte...

Eigentlich ja. Hab das IC auch bereits einmal erneut aufgelötet und alle 
Pins gefühlte 100 mal überprüft und nochmals nachgelötet...

Daher würde ich mal sagen, dass es da zu 99% keinen Fehler hat.
Ich habe inzwischen neue Chips bestellt und versuche es vielleicht mit 
einem zweiten board.
Gleichzeitig habe ich nun endlich mal einen verheissungsvollen Kontakt 
zu allwinner erhalten in der Hoffnung, mehr Informationen zum DDR3 
Interface zu erhalten.

von msp430 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was war jetzt das Problem?

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
msp430 schrieb:
> Was war jetzt das Problem?

Leider hab ich das Problem bis heute nicht herausgefunden.
Ich kann es mir nicht erklären. Hab auch das Schema an Allwinenr zu 
prüfung gesendet. Diese meinten auch, dass die Verdrahtung so ok ist.

Neue Chips aus China zu erhalten dauert immer ne ganze Weile.

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.

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