U-Boot erkennt DDR3-RAM nicht korrekt

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

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:

1

+S:CONFIG_DRAM_CLK=360

2

+S:CONFIG_DRAM_ZQ=123

3

+S:CONFIG_DRAM_EMR1=4

4

+S:CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y

Konfiguriert.

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

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

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:

1

CONFIG_DRAM_CLK=408

2

CONFIG_DRAM_EMR1=0

3

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.

Kann es sein, dass u-boot das memory im Device-Tree erwartet?

1

 12         memory {

2

3

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

4

5

14                                 <0xa0000000 0x1ff00000>;

6

7

15         };

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

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

Ich pushe mal den Thread :)

So ich bin etwas weiter gekommen.

In der Datei: board/sunxi/board.c

Gibt es folgenden code auf Zeile 669

1

  printf("DRAM:");

2

  gd->ram_size = sunxi_dram_init();

3

  printf(" %d MiB\n", (int)(gd->ram_size >> 20));

4

  if (!gd->ram_size)

5

    hang();

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

[dram_sun5i_auto.c]

1

unsigned long sunxi_dram_init(void)

2

{

3

  return dramc_init(&dram_para);

4

}

Dann die dramc_init
[dram_sun4i.c:692]

1

unsigned long dramc_init(struct dram_para *para)

2

{

3

  unsigned long dram_size, actual_density;

4

5

  /* If the dram configuration is not provided, use a default */

6

  if (!para)

7

    return 0;

8

9

  /* if everything is known, then autodetection is not necessary */

10

  if (para->io_width && para->bus_width && para->density)

11

    return dramc_init_helper(para);

12

13

  /* try to autodetect the DRAM bus width and density */

14

  para->io_width  = 16;

15

  para->bus_width = 32;

16

#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN5I)

17

  /* only A0-A14 address lines on A10/A13, limiting max density to 4096 */

18

  para->density = 4096;

19

#else

20

  /* all A0-A15 address lines on A20, which allow density 8192 */

21

  para->density = 8192;

22

#endif

23

24

  dram_size = dramc_init_helper(para);

25

  if (!dram_size) {

26

    /* if 32-bit bus width failed, try 16-bit bus width instead */

27

    para->bus_width = 16;

28

    dram_size = dramc_init_helper(para);

29

    if (!dram_size) {

30

      /* if 16-bit bus width also failed, then bail out */

31

      return dram_size;

32

    }

33

  }

34

35

  /* check if we need to adjust the density */

36

  actual_density = (dram_size >> 17) * para->io_width / para->bus_width;

37

38

  if (actual_density != para->density) {

39

    /* update the density and re-initialize DRAM again */

40

    para->density = actual_density;

41

    dram_size = dramc_init_helper(para);

42

  }

43

44

  return dram_size;

45

}

Und schlussendlich noch die wichtige dramc_init_helper funktion

[dram_sun4i.c:561]

1

static unsigned long dramc_init_helper(struct dram_para *para)

2

{

3

  struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;

4

  u32 reg_val;

5

  u32 density;

6

  int ret_val;

7

8

  /*

9

   * only single rank DDR3 is supported by this code even though the

10

   * hardware can theoretically support DDR2 and up to two ranks

11

   */

12

  if (para->type != DRAM_MEMORY_TYPE_DDR3 || para->rank_num != 1)

13

    return 0;

14

15

  /* setup DRAM relative clock */

16

  mctl_setup_dram_clock(para->clock, para->mbus_clock);

17

18

  /* Disable any pad power save control */

19

  mctl_disable_power_save();

20

21

  mctl_set_drive();

22

23

  /* dram clock off */

24

  dramc_clock_output_en(0);

25

26

#ifdef CONFIG_MACH_SUN4I

27

  /* select dram controller 1 */

28

  writel(DRAM_CSEL_MAGIC, &dram->csel);

29

#endif

30

31

  mctl_itm_disable();

32

  mctl_enable_dll0(para->tpr3);

33

34

  /* configure external DRAM */

35

  reg_val = DRAM_DCR_TYPE_DDR3;

36

  reg_val |= DRAM_DCR_IO_WIDTH(para->io_width >> 3);

37

38

  if (para->density == 256)

39

    density = DRAM_DCR_CHIP_DENSITY_256M;

40

  else if (para->density == 512)

41

    density = DRAM_DCR_CHIP_DENSITY_512M;

42

  else if (para->density == 1024)

43

    density = DRAM_DCR_CHIP_DENSITY_1024M;

44

  else if (para->density == 2048)

45

    density = DRAM_DCR_CHIP_DENSITY_2048M;

46

  else if (para->density == 4096)

47

    density = DRAM_DCR_CHIP_DENSITY_4096M;

48

  else if (para->density == 8192)

49

    density = DRAM_DCR_CHIP_DENSITY_8192M;

50

  else

51

    density = DRAM_DCR_CHIP_DENSITY_256M;

52

53

  reg_val |= DRAM_DCR_CHIP_DENSITY(density);

54

  reg_val |= DRAM_DCR_BUS_WIDTH((para->bus_width >> 3) - 1);

55

  reg_val |= DRAM_DCR_RANK_SEL(para->rank_num - 1);

56

  reg_val |= DRAM_DCR_CMD_RANK_ALL;

57

  reg_val |= DRAM_DCR_MODE(DRAM_DCR_MODE_INTERLEAVE);

58

  writel(reg_val, &dram->dcr);

59

60

  dramc_clock_output_en(1);

61

62

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

63

64

  mctl_set_cke_delay();

65

66

  mctl_ddr3_reset();

67

68

  udelay(1);

69

70

  await_bits_clear(&dram->ccr, DRAM_CCR_INIT);

71

72

  mctl_enable_dllx(para->tpr3);

73

74

  /* set refresh period */

75

  dramc_set_autorefresh_cycle(para->clock, density);

76

77

  /* set timing parameters */

78

  writel(para->tpr0, &dram->tpr0);

79

  writel(para->tpr1, &dram->tpr1);

80

  writel(para->tpr2, &dram->tpr2);

81

82

  reg_val = DRAM_MR_BURST_LENGTH(0x0);

83

#if (defined(CONFIG_MACH_SUN5I) || defined(CONFIG_MACH_SUN7I))

84

  reg_val |= DRAM_MR_POWER_DOWN;

85

#endif

86

  reg_val |= DRAM_MR_CAS_LAT(para->cas - 4);

87

  reg_val |= DRAM_MR_WRITE_RECOVERY(ddr3_write_recovery(para->clock));

88

  writel(reg_val, &dram->mr);

89

90

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

91

  writel(para->emr2, &dram->emr2);

92

  writel(para->emr3, &dram->emr3);

93

94

  /* disable drift compensation and set passive DQS window mode */

95

  clrsetbits_le32(&dram->ccr, DRAM_CCR_DQS_DRIFT_COMP, DRAM_CCR_DQS_GATE);

96

97

#ifdef CONFIG_MACH_SUN7I

98

  /* Command rate timing mode 2T & 1T */

99

  if (para->tpr4 & 0x1)

100

    setbits_le32(&dram->ccr, DRAM_CCR_COMMAND_RATE_1T);

101

#endif

102

  /* initialize external DRAM */

103

  mctl_ddr3_initialize();

104

105

  /* scan read pipe value */

106

  mctl_itm_enable();

107

108

  /* Hardware DQS gate training */

109

  ret_val = dramc_scan_readpipe();

110

111

  if (ret_val < 0)

112

    return 0;

113

114

  /* allow to override the DQS training results with a custom delay */

115

  if (para->dqs_gating_delay)

116

    mctl_set_dqs_gating_delay(0, para->dqs_gating_delay);

117

118

  /* set the DQS gating window type */

119

  if (para->active_windowing)

120

    clrbits_le32(&dram->ccr, DRAM_CCR_DQS_GATE);

121

  else

122

    setbits_le32(&dram->ccr, DRAM_CCR_DQS_GATE);

123

124

  mctl_itm_reset();

125

126

  /* configure all host port */

127

  mctl_configure_hostport();

128

129

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

130

}

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


Offenbar wird hier sehrwohl der DDR-Clock aktiviert:

1

  /* setup DRAM relative clock */

2

  mctl_setup_dram_clock(para->clock, para->mbus_clock);

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

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

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.

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

Moin,

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

Gruss
Wolfram

Soo, habe mir heute mal wieder Zeit genommen, mich diesem Thema zu 
widmen.

Ich habe nun herausgefunden, dass das DQS-Training fehlschlägt.

1

static int dramc_scan_readpipe(void)

2

{

3

  struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;

4

  u32 reg_val;

5

6

  /* data training trigger */

7

  clrbits_le32(&dram->csr, DRAM_CSR_FAILED);

8

  setbits_le32(&dram->ccr, DRAM_CCR_DATA_TRAINING);

9

10

  /* check whether data training process has completed */

11

  await_bits_clear(&dram->ccr, DRAM_CCR_DATA_TRAINING);

12

13

  /* check data training result */

14

  reg_val = readl(&dram->csr);

15

  if (reg_val & DRAM_CSR_FAILED)

16

    return -1;

17

18

  return 0;

19

}

1

/* Hardware DQS gate training */

2

  ret_val = dramc_scan_readpipe();

3

//if (ret_val < 0)

4

  //  return 0;

Hier wird mir -1 geliefert.

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

Mal Schaltplan und Layout posten...

Gute Idee!

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

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

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.

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

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

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

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

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?

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

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

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.

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:

1

  reg_val = readl(&dram->csr);

2

  if (reg_val & DRAM_CSR_FAILED)

3

    return -1;

4

5

  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.

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

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

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.

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

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