System-Speicher erweitern durch DDR-SDRAM Chip parallel auflöten (ein Adresspin unterschiedlich)?

[Sven L. (svenni77)]

Hallo DDR-SDRAM Spezialisten!

Vielleicht könnt Ihr mich gleich davon abhalten Zeit zu verschwenden, 
weil Ihr etwas Ähnliches schon mal versucht habt:

Ich habe einen Satelliten-Receiver (QBoxHD von Duolabs - CPU: STi7101) 
mit 128MB (System-)RAM. Nach dem Starten der Anwendungen sind noch ca. 
20MB frei. Das ist relativ knapp bemessen und ich hab mir irgendwann mal 
den Floh ins Ohr gesetzt, den Speicher zu erweitern (also Herunterlöten 
der alten Chips und Ersetzen durch größere). Größere DDR-SDRAM-Chips mit 
1Gb (statt 512Mb) gibt es zwar im gleichen Package (TSOP-II) von Micron 
(MT46V64M16-5B), allerdings sind die mit der benötigten Frequenz 
(200MHz, dafür steht der Suffix -5B) nur sehr schwierig (z.B. bei 
aliexpress) zu bekommen.

Jetzt fiel mir eben die Möglichkeit ein, dass man die gleichen Chips ja 
einfach Huckepack parallel obendrauf anlöten könnte. Dabei natürlich 
z.B. A12 auslassen und per Kupferlackdraht auf A13 mappen. Könnte das 
funktionieren oder gibt es bei der Initialisierung oder durch 
Temperatur/Reflexionen irgendwelche Probleme?

Die RAM-Chips auf dem Board sind die HY5DU121622DTP von Hynix. Falls Ihr 
Datenblätter nicht raussuchen wollt, ich kann sie noch hinzufügen, weiß 
allerdings gerade nicht, ob das rechtlich hier erlaubt ist.

Das basiert natürlich alles auf der Annahme, dass das höchste Adressbit 
auf dem Mainboard auch wirklich zur CPU geroutet wurde. Die CPU 
unterstützt laut Datenblatt mindestens 176MB, im 32-Bit Mode auch 512MB.

Danke Euch für die Info!

[Rufus Τ. F. (rufus)]

Hast Du schon mal darüber nachgedacht, daß auch die Software Deines 
Receivers wissen muss, daß es nach dem Umbau mehr RAM gibt?

[Sven L. (svenni77)]

Mann-o-mann, das ging schnell!

Sorry, ich habe vergessen zu erwähnen, dass ich sämtliche Sourcen 
besitze und bereits den Linux-Kernel auf eine neuere Version portiert 
habe. Im Kernel wird während der Initialisierungsphase der verfügbare 
Speicher ermittelt.

[Stefan F. (Gast)]

A12 auslassen und mit A13 verbinden ist aber nicht sinnvoll.

Wenn A13 zwischen den beiden Speichern unterscheiden soll, musst du eine 
Logikschaltung vor die Chip-Select Leitungen beider IC's bauen, die das 
CS Signal der Platine mit A13 kombiniert.

CS=Low und A13=Low -> Selektiert den ersten Chip
CS=Low und A13=High -> Selektiert den zweiten Chip
CS=High und A13=egal -> Selektiert keinen Chip.

[Achim S. (Gast)]

Sven L. schrieb:
> Dabei natürlich
> z.B. A12 auslassen und per Kupferlackdraht auf A13 mappen.

das nützt dir nichts: du müsstest aus den höherwertigen Adressen 
ausdekodieren, welches DRAM gerade gemeint ist. Die CS-Pins deiner DRAMs 
müssen unterschiedlich angesteuert werden, nicht die Adressen.

Ein Beispiel, was bei deinem Aufbau nicht klappen wird:
Du möchtest vom "oberen DRAM" lesen und setzt A13 auf eins. Trotzdem 
bekommen jetzt beide DRAMs das Lesekommando und beide treiben Ihre (im 
allgemeinen Fall unterschiedlichen) Daten, so dass auf dem Datenbus nur 
Unsinn rauskommt.

Der richtige Ansatz wäre: wenn A13 auf 0 ist, dann erhält nur der untere 
Chip (über CS) das Lesekommando. Ist A13 auf 1, dann wird nur auf dem 
oberen Chip gelesen. Wenn dein Controller nicht von Haus zwei DRAM-Ränge 
unterstützt, dann müsstest du dir (theoretisch) du dir die beiden 
Varianten des CS (CS0 und CS1) aus dem CS des Controllers und aus A13 
dekodieren. Praktisch wird es sehr viel einfacher sein, den kleinen DRAM 
durch einen größeren Chip zu ersetzen.

[Sven L. (svenni77)]

Stefan U. schrieb:
> A12 auslassen und mit A13 verbinden ist aber nicht sinnvoll.
>
> Wenn A13 zwischen den beiden Speichern unterscheiden soll, musst du eine
> Logikschaltung vor die Chip-Select Leitungen beider IC's bauen, die das
> CS Signal der Platine mit A13 kombiniert.
>
> CS=Low und A13=Low -> Selektiert den ersten Chip
> CS=Low und A13=High -> Selektiert den zweiten Chip
> CS=High und A13=egal -> Selektiert keinen Chip.

Mist, das ist mein Denkfehler! Ich bin bisher davon ausgegangen, dass 
A13 ja einfach den Chip (de-)selektiert, aber das ist ja gar nicht der 
Fall. Damit würde der Inhalt unterhalb des A12-Bereiches gespiegelt 
werden...eventuelle Signalkollision inklusive...

Es geht nur mit so einer Schaltung, Du hast Recht!

[Sven L. (svenni77)]

Ja, Ihr habt Recht! Ich merke gerade, dass ich schon lange keine 
Hardware mehr entworfen habe :-(.

Um das doch noch weiter zu treiben...weil mich der Aufbau dieser Logik 
nicht davon abhalten würde...könnte es dann funktionieren?

Am liebsten würde ich ja gleich den großen 1MBit Chip verbauen, aber 
woher nehmen, wenn nicht stehlen?!

[Christian R. (supachris)]

Komplett tauschen ist sinnvoller. Ali liefert doch fast immer 
ordentlich.
Mit Glück sind die Leitungen zur CPU geroutet.

[Sven L. (svenni77)]

Ja, das wäre auch mein Favorit, aber die Verkäufer äußerten sich bisher 
nie vernünftig, ob sie denn die 5B-Variante verkaufen oder eine andere. 
Ich hatte bisher aber auch nie Probleme mit Ali!

Laut STi7101 Datenblatt muss es übrigens unbedingt die 200MHz-Variante 
(DDR400) sein!

Ich werde mal schauen, ob ich die Version noch irgendwo auftreiben 
kann...an TSSOP "so viel" Lackdraht anlöten gefällt mir nicht. Schade!

Danke an Euch alle!

[Sven L. (svenni77)]

Ich habe eben noch einen weiteren - hoffentlich kompatiblen - Chip 
gefunden:

IM1G16D1CCT

Firma: Intelligent memory

Noch nie gehört! Selbst bei Ali findet man keinen einzigen Eintrag, 
obwohl auf der Seite http://www.intelligentmemory.com/dram/ddr1-sdram/ 
"in Production" steht.

[Joachim B. (jar)]

Sven L. schrieb:
> Ich werde mal schauen, ob ich die Version noch irgendwo auftreiben
> kann...an TSSOP "so viel" Lackdraht anlöten gefällt mir nicht. Schade!

???

du kannst doch alle Beine nach unten knicken und den Baugleichen Chip 
auflöten, nur die beiden CS Pins, vom unteren und oberen müssten mit 
Fädeldraht also 2 pro IC-Gruppe ausdekodieren, hatte ich schon beim 
guten alten PC1500 gemacht, also viele Fädel/Lack-drähte sind das doch 
nicht.

[Rufus Τ. F. (rufus)]

CS-Pins will man bei SDRAM ziemlich sicher nicht selbst über 
Adressleitungen ausdecodieren. Die Dinger arbeiten mit gemultiplexten 
Adressen, da ist so eine einfache aus SRAM-Zeiten stammende Logik wie 
die von Stefan weiter oben erwähnte kaum umsetzbar. Dazu kommt, daß so 
ein DDR-SDRAM ein "bisschen" flotter ist in seinem Timing ...

[Joachim B. (jar)]

Rufus Τ. F. schrieb:
> CS-Pins will man bei SDRAM ziemlich sicher nicht selbst über
> Adressleitungen ausdecodieren

upps, habe das D bei SRAM übersehen, sorry!

[Sven L. (svenni77)]

OK, das funktioniert also alles so gar nicht?! Mist! Das sieht in den 
Datasheets gar nicht so kompliziert aus. Wenn low, dann aktiviert 
ansonsten deselektiert:

CS#   Input
Chip select: CS# enables (registered LOW) and disables (registered HIGH)
the command decoder. All commands are masked when CS# is registered
HIGH. CS# provides for external bank selection on systems with multiple
banks. CS# is considered part of the command code.

Hier der Link zum Datenblatt: 
https://www.micron.com/~/media/documents/products/data-sheet/dram/ddr1/1gb_ddr.pdf

Was gibt es da zu beachten und was habe ich übersehen? Es könnte auf 
jeden Fall passieren, dass das Adresssignal A13 zeitlich gesehen erst 
nach dem CS#-Signal gesetzt wird. Dadurch wird "mein neues" CS-Signal 
natürlich auch verzögert, was so eigentlich nicht vorgesehen ist.


Ich habe bis eben nochmal nach Alternativen für den Chip gesucht (auch 
bei kompletten SO-DIMMs, aber die verwenden scheinbar alle 64M8, also 
8-Bit Datenbus). Insgesamt habe ich drei Hersteller gefunden, die 1Gb 
Chips im TSOP-II Package anbieten:
1. Alliance memory: In den Datenblättern von Alliance memory wurden die 
200MHz durch 166MHz ersetzt, fällt also raus.
2. Die Firma Intelligent memory könnte ich noch anschreiben. Vielleicht 
schicken sie mir ein paar Samples.
3. Micron: Auch hier wurde aus irgendwelchen Gründen die Unterstützung 
von 200MHz gestrichen. Im Datenblatt wird sie noch erwähnt, allerdings 
schon mit der Fußnote: "1. Not recommended for new designs.".

Wenn es keine Bastellösung gibt, sieht es so aus, als würde ich ein 
totes Pferd reiten. Grrr!

[Rufus Τ. F. (rufus)]

Sven L. schrieb:
> CS#   Input

/CS selbst ist nicht das Problem, sondern das, was während des 
Speicherzugriffs auf den Adressleitungen los ist.

Deine DDR-SDRAMs kannst Du vermutlich am einfachsten durch Recycling 
gewinnen, die Chance, so etwas auf alten Speicherriegeln von PCs zu 
finden, schätze ich gar nicht mal so schlecht ein.


Erfolg!