U-Boot erkennt DDR3-RAM nicht korrekt

[Holger K. (holgerkraehe)]

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

[Μαtthias W. (matthias)]

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

[habeichvergessen (Gast)]

https://linux-sunxi.org/Mainline_U-Boot

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

[Holger K. (holgerkraehe)]

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.

[Holger K. (holgerkraehe)]

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

[Μαtthias W. (matthias)]

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

[Holger K. (holgerkraehe)]

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.

[Holger K. (holgerkraehe)]

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

[Dergute W. (derguteweka)]

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

[Holger K. (Gast)]

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.

[Holger K. (holgerkraehe)]

Ich pushe mal den Thread :)

[Holger K. (holgerkraehe)]

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.

[Dergute W. (derguteweka)]

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

[Holger K. (holgerkraehe)]

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.

[oszi40 (Gast)]

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

[X2 (Gast)]

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

[Holger K. (holgerkraehe)]

Tatsächlich habe ich bei meinem Embedded-Board kein SPD-EEPROM.

[Dergute W. (derguteweka)]

Moin,

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

Gruss
Wolfram

[Holger K. (holgerkraehe)]

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?

[No Y. (noy)]

Mal Schaltplan und Layout posten...

[Holger K. (holgerkraehe)]

Gute Idee!

[TR.OLL (Gast)]

U-Boote gehen auch ohne Arbeitsspeicher.

SCNR

[No Y. (noy)]

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

[Holger K. (holgerkraehe)]

sorry, da ging was schief mit dem PDF.
Hier bilder mit mehr informationen.

[Holger K. (holgerkraehe)]

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.

[Holger K. (holgerkraehe)]

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

[No Y. (noy)]

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

[Holger K. (holgerkraehe)]

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

[No Y. (noy)]

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

[Holger K. (holgerkraehe)]

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?

[No Y. (noy)]

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

[Holger K. (holgerkraehe)]

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

[No Y. (noy)]

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.

[Holger K. (holgerkraehe)]

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.

[guest (Gast)]

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

[Holger K. (holgerkraehe)]

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

[No Y. (noy)]

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

[Holger K. (holgerkraehe)]

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.

[Gerd E. (robberknight)]

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

[Holger K. (holgerkraehe)]

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.

[msp430 (Gast)]

Was war jetzt das Problem?

[Holger K. (holgerkraehe)]

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.