NSLU2 - 'Experte'

Installing Memory

There are two ways to increase the RAM on your Slug. You can either double up with chips of the same organization or you can replace the chips on the board with higher capacity ones. I’m sure that the former method works but I don’t believe that the firmware configuration solution herein supports four-chip solutions.

The board comes with 2 128Mib chips. You’re looking for 256Mib or 512Mib chips. Some folks have been successful in harvesting SDRAM chips from DIMMs they’ve found. Good luck to you bargain hunters. I tired of the search and bought chips from Digikey. What you need are chips with the following characteristics.

• Synchronous DRAM, PC133 compliant (7.5ns), 3.3v
• 54 pin TSOP II packaging
• 256Mib (16Mx16) or 512Mib chips (32Mx16)

The manufacturer of the original memory, ISSI, does not have 512Mib chips for sale on DigiKey’s site. There are 256Mib chips. IMHO, if I’m going to go through the hassle of replacing the memory, I’m going to spend a little more to quadruple the RAM instead of doubling it.

I bought the 512Mib Micron memory: MT48LC32M16A2.

You’ll need rework equipment to remove the old memory and replace it with the new. I have access to a microscope and Metcal soldering station. We use ChipQuick and low-temperature solder to ease the old parts from boards. You’ll need to remove the battery holder from your Slug before working on the memory chips.

I found that Kingston sells a DIMM part [KVR133X64C3/128] with four 4Mx16×4 chips. These are the same organization as the chips that come on the slug.

Configuring the Slug for More RAM via APEX

Up to now, most folks have been either recompiling RedBoot or replacing RedBoot with APEX so that the larger memories are configured and detected. As of version 1.4.17, APEX has support for enabling larger memory on the SLUG without either of these tedious tasks.

Let me be clear that I haven’t verified that this will work for four-chip configurations. Because we’re running APEX as a second-stage loader from SDRAM, when we change the memory configuration register, there should be no way for APEX to set the mode register of the second bank of memory. APEX version 1.4.17 performs a cache lock-down while reinitializing SDRAM, so it may work.

What we have to do is simple. We need to update the SDRAM configuration register so that the SDRAM controller allows us to address the extra memory. RedBoot will already have configured the SDRAM mode registers. Schematically, it looks like this:

• RedBoot initializes the hardware.
• RedBoot loads APEX (as if it were the Linux kernel) and executes it.
• APEX updates the memory configuration register.
• APEX rescans memory.
• APEX boots the kernel with an accurate memory map.

In APEX 1.4.17, there is a special command, sdram-init, that re-configures the SDRAM configuration register and then searches for unique memory. There is another new command, memscan, that scans memory and constructs the memory map APEX uses to build the ATAG structure passed to the Linux kernel.

This means you need to update APEX in flash which can be tricky or use one of the Debian distributions that depends on APEX as a second stage loader.

Putting this together means you need to change the startup variable in APEX to include sdram-init and a memory scan. You can do this from the console by interrupting the boot process with a ^C while APEX copies the kernel and ramdisk from flash, or you can use the user-space program ##apex-env##. It is important to insert the new commands at the beginning of the command list and to maintain all of the other commands. Single quotes around the startup commands are important to prevent expansion of the APEX variable references.

# apex-env
...
startup *= copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C to cancel autoboot.; boot
# apex-env setenv startup 'sdram-init; memscan -u 0+256m; copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C to cancel autoboot.; boot'

Configuring the Slug for More RAM via arm-kernel-shim

For those who do not use APEX, but still want to use more memory, the arm-kernel-shim has support for reconfiguring the SDRAM controller and passing the correct memory size to the kernel. It isn’t as flexible as APEX in that it cannot detect memory. This support was added in version 1.4 of the shim.

Potential Future Work

Version 1.4.17 of APEX implements a cache lock-down in sdram-init in order that the SDRAM controlled may be taken off-line while SDRAM is reconfigured. I’m not sure that all of this should be OK since we’re supposed to disable the refresh counter while we bring-up SDRAM.

Moreover, I’ve been unable to verify that the cache lock-down is even necessary. When I disable that portion of the code, the SDRAM is still reinitialized. It is possible that the SDRAM controller refuses to go offline, or perhaps I’m not flushing the cache properly in my tests.

Copyright by http://wiki.buici.co … lug+Memory+Expansion
Kopiert von https://web.archive. … xpansion#Attachments, da sonst nicht weiter verohanden. Ich suche noch Bilder.

Es gibt kein Webinterface, so lange ihr nicht z B. LUA, Samba oder ähnliches installiert habt.

Ganz klar, nach der ersten Installation läuft ein sshd in den ihr euch einloggen könnt, dazu nehmt ihr z. B. puTTy. Dort gebt ihr die IP eurer NSLU2 ein oder, wenn ihr der NSLU2 eine feste IP im Router (fritz.box!) zugewiesen habt, den entsprechenden Hostnamen der NSLU2.

telnet für den Zugriff auf RedBoot (zum flashen):
Diese Methode setzt ein laufendes *NIX System wie z. B. UBUNTU vorraus.

sudo arping -f 192.168.0.1; telnet 192.168.0.1 9000

dann 2x CTRL+C drücken

Schnittstelle: comX
Speed (baud): 115200
Data Bits: 8
Stop Bits: 1
Parity: none/keine
Flow control: XON/XOFF

Ein weiteres Startproblem taucht auch immer wieder auf, zumeist heißte es “…seit ich meine/n neue/n Festplatte/n oder USB-Memory-Stick…”. Dieses Problem zu ergründen würde warhscheinlich die Entwicklungskosten der Slug übersteigen, jedoch gibt es eine Art “Workaround” für diesen Fall. Jede Festplatte hat einen Namen im Ordner /dev zB sda*, diese sog. Devices werden auch in der fstab zum mounten der Speichermedien benutzt. Hat man zB sein Hauptverzeichnis / auf der ersten Partition der ersten Festplatte (/dev/sda1) steht dann in der fstab:

/dev/sda1   /   ext3   noatime,errors=remount-ro 0   1

Schließt man nun eine weitere Festplatte VOR dem Einschalten der Slug an, so kann die neue Festplatte den Platz der ersten Festplatte in /dev einnehmen. Debian sucht nun auf der neuen Festplatte das System…vergebens, um dies zu umgehen werden eindeutige Namen für jede Partition verlangt. Diese sog. Labels erstellt man ganz einfach:

tune2fs -L Partitionsname /dev/sda*

Hat man nun jeder Partition einen Namen gegeben, muß nur noch die fstab angepasst werden:

LABEL=Partitionsname   /   ext3  noatime,errors=remount-ro 0   1

Die einzige Ausnahme ist die SWAP-Partition, ihr kann man per

mkswap -L SwapPartitionsname /dev/sda*

einen Namen geben. Zuvor muß die SWAP-Partition deaktiviert (swapoff /dev/sda*), danach wieder aktiviert (swapon Label=SwapPartitionsname) werden.

(* entspricht jeweils einer Nummer der jeweiligen Partition)

Tja…es fängt ganz gut an, die LEDs leuchten und blinken nach dem Einschalten, die LED an Festplatte oder USB-Memory-Stick blinkt und hört nach wenigen Sekunden einfach nicht auf, die Slug ist jedoch nicht per Telnet oder SSH erreichbar. Dieses Problem gibt es meistens nach der ersten Installation, bei der YBIND und ähnliche Daemons installiert und gestartet wurden. YBIND ist ein Service der DHCP/DNS Dienste zur Verfügung stellt und beim starten das Netzwerk intensiv durchsucht und mit seinen Regeln vergleicht.

Eine weitere Möglichkeit ist die Festplattendiagnose nach x-Startvorgängen oder bei Fehlern im Dateisystem. Eine Festplattendiagnose (fsck; in DOS/Windows auch scandisk) dauert je nach Kapazität und Speichermedium. Wenn dabei Fehler gefunden werden und nicht korrigiert automatisch werden (können) lässt die Aktivität der LED des Sepichermediums nach, Telnet und SSH sind nicht verfügbar. Ein Eingriff per serieller Schnittstelle ist unumgänglich.

Immer wieder kommt es vor, dass die Slug entweder ewig braucht um zu starten oder schwer bis gar nicht reagiert nach dem Einschalten. Dieses Problem ist zumeist auf zwei Fehlerquellen zurückzuführen, zum einen die interne Batterie und zum anderen das Netzteil.

Ist die Batterie (fast) leer, so merkt sich die Slug nicht mehr die aktuelle Uhrzeit und fordert zum manuellen Eingreifen auf.
Ist das Netzteil defekt, startet die Slug zumeist gar nicht mehr, solange ein USB-Memory-Stick oder eine Festplatte angeschlossen ist. Steckt man alle USB-Geräte ab startet die Slug.

Welches der beiden Probleme bei Dir aufgetreten ist, kann man entweder ausprobieren ODER über die serielle Schnittstelle rausfinden.

…auf DER mini-tutorial Seite zu NSLU2 (Slug)

Viele Probleme treten immer wieder mit der kleinen Slug auf, und immer wieder werden die selben Fragen in Foren gestellt; doch niemand sucht wirklich vorher nach einer Lösung.

Hier sollen nun kurz und bündig alle gefundenen Lösungen zu finden sein. Aber nicht nur Lösungen sind hier zu finden, sondern auch einfache Konfigurationsdateien (zB. für ntp-server oder Samba) und kurze Tutorials.