Posted on Leave a comment

Remote debugging over SSH (Windows)

Remote debugging is a feature of the ICEbearPlus extended debugging toolchain. It enables you to grant access to a locally running debug agent by using SSH tunneling feature of the third party application Putty. For example, if your hardware shows a problem in the field or development of a new flash driver is required, debugging service can be provided by us without the requirement to send hardware.  So the steps for a service technician are:

  • (Inform sysadmin about the action to avoid paranoia)
  • Obtain Putty.exe from putty.org
  • Run it
  • Configure the tunnel
  • Start the debug agent

Configuring the tunnel session

Add the host name and port as shown below. You may want to get back to this menu later and Save this session for later use.

When you make a connection, a black terminal window pops up and will ask you for login data (sent to you separately).

Configure the tunnel

To grant access to a local port of your computer, the tunnel needs to be configured as ‘Remote’, i.e. the ‘Source port’ of the remote host is forwarded to the local port. Means, an authorized person logged in on the remote server can connect to your local port as long as Putty is active.

To open a remote port forward, add ‘Source port’ and ‘Destination’ as shown below and click ‘Add’. Do the same for both ports 2000 and 4000 for the local gdbproxy server, such that the settings are displayed in the image on the bottom.

Then you can connect using ‘Open’.

gdbproxy debugging

Start the gdbproxy server via the Start menu through the ICEbear->Start gdbproxy entry.

Then the gdbserver should fire up as shown below.

Once a connection is made, you can see this on the console. Also, the status during debugging is displayed. If the connection through the tunnel is effective (i.e. Putty tunnel session active) a connection can be made.

A safety notice: No other person aware of this information can connect to your target. Only authorized persons with a login can access your local ports during an active session. Once you terminate the Putty session by closing the window, all connections are terminated and no more access from outside is possible.

Service package

Available remote debugging services:

  • Analog Devices Blackfin targets (ICEbearPlus and service contract required)
  • netpp node or dombert IP camera hardware (ZPUng)
  • ARM based systems supported by OpenOCD

Übersicht

MaSoCist – ein linux-ähnliches Build-System für eigene CPU-Designs als OpenSource

FPGAs erlauben ein weitgehend nur durch die vorgegebenen Chip-Resourcen eingeschränktes eigenes Prozessordesign mit Peripherie.
Da auf FPGAs oft für den Anwendungszweck spezialisierte Hardware zum Einsatz kommt, kann ein software-implementierter on-chip CPU-Kern meist einfache Konfigurationsarbeiten oder die Schnittstelle zum Nutzer — die Peripherie — abdecken. Typischerweise wird dies als ‘SoC’ — System on Chip — bezeichnet.

Die MaSoCist-Umgebung (Abkürzung für Martins System on Chip Instancing/Simulation tool
erlaubt, die CPU wie auch die benötigte Peripherie weitgehend analog zum Linux Kernel zu konfigurieren und die Software wie auch die Hardware über Gerätebeschreibungen zu definieren. Damit kann u.a. die Firmware/Software, die grundsätzlich per GNU-Toolchain gebaut wird, für viele verschiedene FPGA-Plattformen verwaltet werden.

Details

In der Nische der FPGA SoCs haben sich resourcensparende Stack-Maschinen trotz Geschwindigkeitseinbussen gegenüber komplexeren Architekturen gut etabliert, unter anderem die von Øyvind Harboe konzipierte ZPU-Architektur, die mit einem vollständigen GNU-Werkzeugkasten (gcc, gdb) daherkommt.
Sie gilt als die kompakteste 32-Bit-Architektur mit gcc-Support, da sie im Vergleich zu den proprietären Herstellerlösungen wenig Logikelemente benötigt und eine der besten Code-Dichten aufweist.

Das System ist dabei aufgebaut wie ein Linux-Kernel, nur für Hardware:
Optionen können entsprechend der Zielanwendung konfiguriert werden, werden z.B. vier UARTs benötigt, wird die zugehörige Variable CONFIG_NUM_UART angepasst.
Dabei wird automatisch alles Nötige für den Anwender erzeugt:

  • Hardware-Definition in HDL (VHDL) für die Synthese oder Simulation
  • Header mit Register-Definitionen für den C-Programmierer
  • Register-Referenzdokumentation (Register-Bits, usw.)

Im Rahmen einer Machbarkeitsstudie wurde eine gegenüber der originalen ZPU-Architektur verbesserte schnellere Variante ZPUng mit dreistufiger Pipeline entwickelt, die unwesentlich mehr Logik benötigt und dank einem passenden Befehlsinterpreter vollständig Opcode-kompatibel zum Original ist.

Highlights

Referenzanwendungen

Alle Anwendungen benötigen weniger als 32kB on-Chip SRAM und normalerweise kein externes Memory.

Ein weiteres Feature ist die Fähigkeit der kompletten Simulation des Programmcode. Werden z.B. Variablen oder Register nicht korrekt initialisiert, tritt dies sofort in der Simulation zutage. Somit lassen sich komplette Programme, sofern sie deterministisch ablaufen, zusammen mit der Hardware und entsprechend virtuellen Stimulationen durchsimulieren und regress-testen.
So sind auch sicherheitsrelevante Funktionen wie hardwaremässige Not-Abschaltung bei fehlerhaftem Verhalten gut verifizierbar.

Für die Simulation wird ‘ghdl’ verwendet, welches quelloffen ist und eine hohe Robustheit aufweist. Insofern ist die vorgestellte Lösung komplett herstellerunabhängig und läuft je nach Konfiguration auf
Plattformen unterschiedlicher FPGA-Hersteller.
Das ‘MaSoCist’-Build-System ist unter einer OpenSource-Lizenz und als Docker container (keine Installation von weiteren Paketen nötig) verfügbar. Gleichzeitig werden Entwickler bei Neuentwicklung ihrer
Komponenten nicht zur Offenlegung ihrer Designs gezwungen.

Weitergehende Informationen (englisch):

https://section5.ch/index.php/documentation/masocist-soc/

Die Links zu Git-Repositories werden hier in Kürze veröffentlicht. Bitte um etwas Geduld.

Services

We are experts in the following fields:

  • Machine vision algorithms
  • Web Technologies
  • IP cores and DSP-Architectures

Our services:

How we work:

  • Testing while developing: automated continuous integration
  • Early prototyping – show customers what they get
  • Agile but sustainable development, heavily dependent on Docker technologies