Eine Datenbank kompatibler Display-Panele

Display-Panele, wie sie in Flachbildschirmen, TVs, Tablets und Notebooks zum Einsatz kommen, gibt es in vielen verschiedenen Kombinationen von Abmessung und Auflösung. Während diese Parameter trotz ihrer Vielfalt noch einigermaßen normiert sind, verwendet für die Anschlüsse auf der Display-Rückseite, über die das Panel intern mit dem Grafikausgang der jeweiligen Hauptplatine verbunden wird, jeder Hersteller eigene Buchsen, die unterschiedliche Pin-Anzahl und -Belegung aufweisen. Die Art der Bildübertragung ist dabei stets über unterschiedlich viele LVDS-Kanäle. Zu den LVDS-Leitungen kommen noch weitere für den Zugriff auf den Parameter-Speicher im Display (EDID).

Üblicherweise kommt der Endnutzer erst mit der LVDS-Schnittstelle in Berührung, wenn das Display beschädigt wird und ersetzt werden muss. Dabei passiert es mir nicht selten, dass ich eigentlich noch Displays aus anderen Geräten zur Verfügung hätte, insbesondere aus alten Notebooks. Aus der oben genannten Problematik, kann man aber nicht einfach defektes und funktionierendes Display gegeneinander austauschen, denn obwohl stets Flachbandkabel zum Einsatz kommen, selbst dann, wenn der Display-Stecker in die Display-Buchse passt, nicht notwendigerweise die gleiche Pinbelegung vorliegt.

Da wäre es hilfreich, die Display-Schnittstelle wäre einer Normierung unterworfen, sodass Displays unterschiedlicher Hersteller miteinander vertauschbar wären.

Primäres Ziel bei dieser Überlegung ist, den Endnutzer in die Lage zu versetzen, sein Endgerät selbst reparieren zu können. Eine Möglichkeit, dem Nutzer dabei zu helfen, könnte eine Datenbank sein, welche eine Korrelation zwischen einerseits Endgeräten, z.B. Notebooks, und andererseits Display-Panel-Modellen aufstellt, zusammen mit Informationen zu Abmessung und Auflösung des Displays, sodass man beispielsweise beim Defekt seines Thinkpad T42p Displays unmittelbar abrufen könnte, dass die Notebooks Dell Latitude C600 und Dell Inspiron 4000 kompatible Displays enthalten, es sich also lohnt, die Letzteren entsprechend auszuschlachten.

Außer für Thinpads gibt es eine solche Datenbank bisher leider scheinbar nicht.

Wünschenswert wäre natürlich auch, die Panel-Hersteller würden zu ihren Display-Daten stets auch Pin-Belegung und Bildübertragungs-Protokoll veröffentlichen. Leider ist das nicht die gängige Praxis.

Veröffentlicht unter Technik | Hinterlasse einen Kommentar

TI’s XDS100 v2 JTAG adapter

Texas Instruments offers a special JTAG adapter for programming some of their digital signal processors (DSPs). The adapter with the model number XDS100v2 from Spectrum Digital is sold as TMDSEMU100V2U-14T. The board is equiped with an FTDI FT2232H USB-serial converter, which connects to a Xilinx XC2C32A-VQG44 programmable logic IC (CPLD).

The adapter is supported by OpenOCD using interface configuration interface/ftdi/xds100v2.cfg.

Veröffentlicht unter JTAG | Verschlagwortet mit , , | Hinterlasse einen Kommentar

FT2232D-based JTAG adapter interfaces with STM32F3 Discovery board

With the help of Paul Fertser from IRC channel #OpenOCD on oftc.net and the interface config file he kindly created for my JTAG adapter:

#
# www.100ask.org OpenJTAG
#
# http://www.100ask.net/OpenJTAG.html
#

interface ftdi
ftdi_device_desc "USB<=>JTAG&RS232"
ftdi_vid_pid 0x1457 0x5118

ftdi_layout_init 0x0f08 0x0f1b
ftdi_layout_signal nSRST -data 0x0200 -noe 0x0800
ftdi_layout_signal nTRST -data 0x0100 -noe 0x0400

… I was able to interface with a STM32F3 Discovery Board.

Foto…

More specifically, I interfaced with the STM32F303, the main microcontroller on the board. In order to do that, I I mapped the JTAG pins, referenced in the chip’s datasheet, to header pins available on the board:

  • TMS = PA13
  • TCLK = PA14
  • TDI = PA15
  • TDO = PB3
  • nTRST = PB4
  • 3.3V
  • GND

After connecting the corresponding adapter pins, I could verify the connection by successfully executing some OpenOCD demo commands:

$ openocd -f interface/ftdi/100ask-openjtag.cfg -f target/stm32f3x.cfg -c "reset_config none; init; reset halt; reset; reset halt; shutdown"
Open On-Chip Debugger 0.8.0 (2014-10-20-22:02)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m reset_config sysresetreq
none separate
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f3x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f3x.bs tap/device found: 0x06422041 (mfg: 0x020, part: 0x6422, ver: 0x0)
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32f3x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f3x.bs tap/device found: 0x06422041 (mfg: 0x020, part: 0x6422, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000704 msp: 0x2000a000
Info : JTAG tap: stm32f3x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f3x.bs tap/device found: 0x06422041 (mfg: 0x020, part: 0x6422, ver: 0x0)
Info : JTAG tap: stm32f3x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f3x.bs tap/device found: 0x06422041 (mfg: 0x020, part: 0x6422, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08000704 msp: 0x2000a000
shutdown command invoked
Veröffentlicht unter JTAG | Verschlagwortet mit , , , , | Hinterlasse einen Kommentar

100ask’s JTAG adapter

The JTAG adapter from 100ask.org is a USB-JTAG adapter, available e.g. on eBay. Although on the website the adapter is called „OpenJTAG“, I will only refer to it as 100ask-JTAG adapter, because it is not open hardware and especially not to be confused with the official adapter from the OpenJTAG project. OpenJTAG.org’s adapter is more sophisticated and upgradeable, as it is based on a Lattice MachXO2 FPGA, while 100ask’s only uses an FTDI FT2232D USB-serial converter to emulate JTAG, similar to Esden’s FLOSS-JTAG (and apparently many other JTAG adapters). According to the datasheet, the FT2232D has a maximum bitrate of 3Mbps.

The appropriate OpenOCD interface driver is ftdi (ft2232 is deprecated). However, in which pin configuration, has yet to be determined.

Thankfully, upon request, I got the adapter’s schematics alongside permission to publish them to the public domain. With them I should quickly be able to present a working configuration.

Follow up: FT2232D-based JTAG adapter interfaces with STM32F3 Discovery board

Veröffentlicht unter JTAG | Verschlagwortet mit , , , | Hinterlasse einen Kommentar

Browser acceleration ideas

With increasing internet bandwidths and PC performance, websites are getting more and more complex, in a way that older computer can get very challenged rendering them. One way to address this problem is to assign browsing-related tasks from the CPU to the GPU or other acceleration hardware like FPGA boards or ASICs.

One could imagine a (mini)PCI based FPGA board taking over the JPEG decoding or HTML parsing.

In open source browsers, like Chromium, such tasks are outsourced to libraries anyways. I imagine, it would be comparably simple to replace a software-based e.g. JPEG decoding library like libjpeg-turbo by one that transparently switches to hardware accelerated decoding if available.

There are several projects out there using PCI-based FPGAs for prototyping, e.g.

Are mobile browsers making use of hardware acceleratable features in their respective phone’s SoC and if yes, how?

Read more on the Wiki page…

Veröffentlicht unter Bug reports & Feature requests, FPGA | Verschlagwortet mit , , , , | Hinterlasse einen Kommentar

Upon errors Chrome should pause downloads instead of canceling them

In Chromium 37.0.2062.120 ongoing downloads are canceled when errors occur, e.g. when you stumble over your network cable, unplug it from the PC and Wicd subsequently tries to establish a wireless connection. In such cases Chromium displays an „Unknown network error.“ message in the Downloads manager.

This shouldn’t happen as by canceling the download the data downloaded so far is being deleted.

Instead, Chromium should only pause the download upon error and wait for user interaction to cancel or resume it.

Veröffentlicht unter Bug reports & Feature requests | Verschlagwortet mit , , | Hinterlasse einen Kommentar

Bastler-Problem: EDID checksum invalid

Die LCD-Panele in Flachbildschirmen sind nicht sonderlich kratzfest und können z.B. bei Sturz zerbrechen. Wer dann das defekte LCD-Panel durch ein nicht mit dem Original identischen, aber pin-gleichen und funktionskompatiblen LCD ersetzt, wird feststellen, dass der Bildschirm zwar ordnungsgemäß funktioniert, aber der Linux-Kernel beim Booten einen Prüfsummenfehler meldet:

EDID checksum invalid, remainder is ...

Das hängt vermutlich damit zusammen, dass Bildschirme am DB15-Port über eine Datenleitung mit dem PC kommunizieren, worüber der Bildschirm beispielsweise Display-Daten bekanntgeben kann, die dann nicht mit der Firmware im Bildschirm übereinstimmen.

Ist der Bildschirm mit dem ersetzten LCD funktionstüchtig, kann man sich der obigen Fehlermeldung entledigen, indem man den Linux-Kernel folgendermaßen patcht:

In der Datei /drivers/gpu/drm/drm_edid.c gibt es die Zeile:

DRM_ERROR("EDID checksum is invalid, remainder is %d\n", csum);

Diese und die darauffolgenden Zeilen

if... goto bad;

kommentiert man aus und ersetzt den DRM_ERROR durch:

printk(KERN_ERR "EDID checksum is invalid");
Veröffentlicht unter Fixes | Verschlagwortet mit , , , , , , | Hinterlasse einen Kommentar

Debian über Peer-to-Peer installieren

Eine Debian-Installation besteht aus einer aufeinander abgestimmten Liste von installierten Paketen, die über einen Paket-Manager verwaltet wird. Die Installation von Software geschieht üblicherweise durch Installation des entsprechenden Pakets und ggf. dessen Abhängigkeiten (abhängige Pakete). Diese Pakete werden von einem Mirror des Debian-Projekts über HTTP oder FTP heruntergeladen.

Nicht selten haben heutzutage private Haushalte breitbandige Internetanschlüsse, die Download mit einer wesentlich höheren Rate erlauben, als Mirror es üblicherweise im Upload bereitstellen können. Bei der Frage nach einer Erhöhung des Durchsatzes kommen Peer-to-Peer-Netzwerke in den Sinn. Sie basieren auf dem Prinzip, dass beliebige Hosts, welche über eine Resource, z.B. ein Debian-Paket verfügen, dieses mit gewisser Geschwindigkeit zu einem danach fragenden Host hochladen. Durch die Vielzahl der Hochladenden steigt beim Nachfragenden die Download-Geschwindigkeit.

Das Peer-to-Peer-Prinzip eignet sich auf den ersten Blick sehr gut für das Teilen von Debian-Paketen, da Pakete üblichweise nach der Installation nicht gleich wieder gelöscht, sondern in einem Cache-Verzeichnis vorgehalten werden (/var/cache/apt/archives/), ein Verzeichnis das keine Nutzer-Daten enthält und daher grundsätzlich ohne größere Bedenken öffentlich weitergeteilt werden könnte.

In der Tat gibt es bereits einen Ansatz hinsichtlich der Verwendung von Torrent: DebTorrent. Allerdings hat das Torrent-System hier einige Nachteile, z.B. wegen der vielen vergleichsweise kleinen Pakete (vgl. vorheriger Link).

Mit apt-p2p ist es anscheinend auch möglich, Debian-Pakete dezentral organisiert von anderen Debian-Nutzern zu laden, die an einem System verteilter Hash-Tabellen teilnehmen (DHT).

Ein anderer Ansatz für das Peer-to-Peer-Laden von Debian-Paketen bietet das Metalink-Protokoll. Dabei kann eine ursprüngliche, angefragte Quelle mit einer Liste von alternativen Bezugsquellen für dieselbe Resource antworten. Das Debian-Repository scheint Metalink zu unterstützen. Zumindest kann man mit dem Werkzeug apt-metalink scheinbar von mehreren vorkonfigurierten Mirrors gleichzeitig herunterladen (siehe auch aria2).

Nennenswert in diesem Kontext sind auch noch apt-proxy, apt-cacher, apt-cacher-ng und approx.

Veröffentlicht unter Informatik | Hinterlasse einen Kommentar

Sensitivity of email headers

Encryption of mail bodies
Nowadays it seems to be a must to encrypt one’s communication, in the light of the intransparent and uncontrolled spying of US-american and british secret services upon innocent people. S/MIME and PGP, i.e. PGP/INLINE and PGP/MIME, are common methods which enable users to encrypt their email messages.

However, the encryption of emails usually doesn’t involve encryption of the email headers. The sensitivity of email headers is often underestimated. It deserves more attention, as headers contain metadata with potentially sensitive information, which allow for automated profiling e.g. of a person’s habits and used software.

Sender and Recipient headers
Several headers accompany mail delivery, among them From,To,CC,BCC,Received,Envelope-to and Return-path. Understandably it is not possible to have them end-to-end encrypted without a change in mailing infrastructure. However in general some if not all of them could be end-to-end encrypted between servers. E.g. for the delivery over a mail provider only the domain name of the receiving server is required, as the receiving host handles the assorting of messages into it’s local mailboxes itself. The complete sender address and the user part of the recipient address could be encrypted using a public key, which the receiving but no other host can decrypt. The DKIM key jumps to mind.

Subject
Another example of a sensitive email header is the Subject line. It’s purpose is to summarize the content of the message body. Therefore it naturally is often written in a way that gives away the main statement of the message, rendering an encryption of the message partially useless. At the very least the content of the Subject header allows an attacker to focus it’s cracking effort on messages with a particularly interesting Subject. Furthermore it allows to track message topics, replies and forwardings and provides input to categorize interests and activity of a person. Subject headers should therefore be encrypted end-to-end, which they are usually not, even when message encryption is used.

Conflicting interests
It is sometimes argued, that mail systems must be designed in a way that spam and virus filtering are possible on the mail server, as it is realized e.g. in „De-Mail“. This idea however stands in direct contradiction with the idea of end-to-end encryption, as this sort of message filtering requires access to the plaintext message by a third party.

Dark Mail
Ladar Levision and others are currently working on a specification for DMTP (as opposed to the current mail transfer protocol SMTP), which shall provide for a maximum of privacy through several layers of encryption, where every computer involved in the relay of a message is only able to decrypt the information absolutely necessary for successfull mail delivery.

Read more about Dark Mail:

Veröffentlicht unter Sicherheit, Tagesthemen | Verschlagwortet mit , , , , , , , , | Hinterlasse einen Kommentar