MIDI-Firmware-Updates "entschlüsseln"

[Michael Engel (Gast)]

Hallo,

hat schonmal jemand von euch versucht, das Image für eine Firmware aus 
einem MIDI-Firmware-Update zu extrahieren?

Konkret geht es um den Roland A-01, da steckt (wenn die Fotos nicht 
lügen, die Hardware ist noch nicht angekommen) ein SiLabs 8051 drin:

https://www.roland.com/de/support/by_product/a-01/updates_drivers/a5ccc651-0ff6-40b3-ab43-c281c884509e/

Das Update-MIDI-File "a01updater.mid" ist ca. 360 kB gross, was doch 
recht viel für die 8 kB internen Flash des 8051 ist...

Einen Standard für Firmware-Updates via MIDI scheint es wohl nicht zu 
geben (zumindest habe ich per Google nichts gefunden), ich vermute mal, 
da bastelt jeder Hersteller sein eigenes Protokoll?

-- Michael

[Rene K. (xdraconix)]

Ich gehe mal zu 100% davon aus, das nicht das Midi-Protokoll an sich ein 
Update erfährt, sondern der Controller selbst. Und ja, jeder µC hat da 
seine eigene "Firmeware"... Weil ja auch jedes Gerät anders ist.

[moep (Gast)]

Rene K. schrieb:
> Ich gehe mal zu 100% davon aus, das nicht das Midi-Protokoll an sich ein
> Update erfährt, sondern der Controller selbst. Und ja, jeder µC hat da
> seine eigene "Firmeware"... Weil ja auch jedes Gerät anders ist.

Ich glaub du hast die Frage nicht verstanden :D

[Rene K. (xdraconix)]

moep schrieb:
> Rene K. schrieb:
>> Ich gehe mal zu 100% davon aus, das nicht das Midi-Protokoll an sich ein
>> Update erfährt, sondern der Controller selbst. Und ja, jeder µC hat da
>> seine eigene "Firmeware"... Weil ja auch jedes Gerät anders ist.
>
> Ich glaub du hast die Frage nicht verstanden :D

Ahhhh... Update ÜBER Midi... okay, ja da ging meine Antwort dran vorbei 
:-D Das hab ich falsch verstanden, ich dachte es ging um Update FÜR 
Midi.

[Michael Engel (Gast)]

Rene K. schrieb:
> Ahhhh... Update ÜBER Midi... okay, ja da ging meine Antwort dran vorbei
> :-D Das hab ich falsch verstanden, ich dachte es ging um Update FÜR
> Midi.

Ein Update für das MIDI-Protokoll würde viele Geräte unglücklich 
machen... es ist natürlich ein Update für (in dem Fall) den Synthesizer 
gemeint.

Viele Grüße,
    Michael

[Soul E. (Gast)]

Michael Engel schrieb:

> Einen Standard für Firmware-Updates via MIDI scheint es wohl nicht zu
> geben (zumindest habe ich per Google nichts gefunden), ich vermute mal,
> da bastelt jeder Hersteller sein eigenes Protokoll?

Die SYSEX-Befehle sind gerätespezifisch. D.h. da kann sich der 
Hersteller ausdenken was immer ihm beliebt. D.h. es wird ein 
proprietärer Datenstrom zum Gerät übertragen, wo irgendwie 
Authentisierung, ggf. Bootloader, die eigenliche Firmware und die 
anschließende Konfiguration drinstecken.

[Clemens L. (c_l)]

Michael Engel schrieb:
> da steckt ein SiLabs 8051 drin

Der Code ist aber für ARM.

> Das Update-MIDI-File "a01updater.mid" ist ca. 360 kB gross, was doch
> recht viel für die 8 kB internen Flash des 8051 ist...

Die eigentlichen Daten ohne SysEx-Verpackung sind 0x38000 Bytes (224 
KB).

[Michael Engel (Gast)]

Clemens L. schrieb:
> Der Code ist aber für ARM.

Interessant, vielen Dank!

Ist ja spannend, Roland verkauft den A-01 wie folgt:
https://www.roland.com/us/promos/roland_boutique/interview_3/

>One prominent feature of the Roland A-01 is that it's equipped with the "8-Bit 
CPU Synth," a unique sound-engine circuit like no other. Just as its name 
suggests, the 8-Bit CPU Synth is a "virtual analog" digital sound engine that 
reproduces a subtractive synthesizer with an 8-bit CPU.

Auf dem Foto auf der Webseite meine ich auch (daher kam meine 
Vermutung), einen Silabs 8051 zu erkennen (C8051F330?). Aber gut, das 
kann ja auch reines Marketing sein...

Verrätst du bitte, wie du das MIDI-File entschlüsselt hast? Ich habe 
angefangen, durch die SysEx-Messages durchzusteigen (habe die Messages 
mal auf einem virtuelle MIDI-Interface mitgeschnitten).

Wenn ich das richtig sehe, enthält jedes Paket 0x1C "Nutzbytes", z.B. 
die Pakete Nr. 1 und 2 sehen wie folgt aus:

Paket 1:

00  F0   // SysEx
01  41   // Roland
02  10   // Device 0x10
03  7F   // Model 0x7F
04  12   // Send
05  00 00 00  00   // Address 0x00

09  20 20 0B 01 20 15 04     // Daten
10  00 44 08 5D 20 00 08 05  
18  1D 48 00 08 59 20 00 08
20  35 19 12 00 08 63 4C 00  
28  08 

29  18  // Checksumme
2A  F7  // Ende

Hier wird an Adresse 0 geschrieben, das Folgepaket schreibt ab Adresse 
0x1c (und die folgenden jeweils 0x1c weiter). Damit gehe ich davon aus, 
dass eben 28 (dez.) "sinnvolle" Datenbytes enthalten sind. Real sind 32 
Byte enthalten, aber in der Message dürfen ja keine gesetzten High-Bytes 
vorkommen. Damit sind 32 Bytes zu 7 Bit = 224 = 28 * 8 Bit. Aus einigen 
Strings, die ich gefunden habe, vermute ich, dass jedes 8. Byte der 
Daten (unten in Klammern) die 7 High-Bits der vorher stehenden Bytes 
codiert - auch wenn mir grade nicht ersichtlich ist, in welcher Weise.

Das stimmt dann so ungefähr mit den von dir geposteten File überein:

SysEx-Daten: (20) 20 0B 01 20 18 04 00 (44) 08 5D 20 00 08 05 1D (48) 
Dein File:        A0 8B 81 A0 95 84 00      88 DD A0 80 88 85 9D
                  -- -- -- -- -- -- --      -- -- -- -- -- -- --
Differenz (Bit 7) 80 80 80 80 80 80 00      80 80 80 80 80 80 80

Eine schöne Knobelei auf jeden Fall :-).

-- Michael

[Clemens L. (c_l)]

Michael Engel schrieb:
> ... vermute ich, dass jedes 8. Byte der Daten (unten in Klammern) die 7
> High-Bits der vorher stehenden Bytes codiert

der 7 nachfolgenden Bytes

> auch wenn mir grade nicht ersichtlich ist, in welcher Weise

In der offensichtlichen Weise. Man sollte dann nur nicht in dem 
Python-Skript "and" und "&" verwechseln ...  :-(

Hier die korrekte Version.

[Michael Engel (Gast)]

Clemens L. schrieb:
>> auch wenn mir grade nicht ersichtlich ist, in welcher Weise
>
> In der offensichtlichen Weise. Man sollte dann nur nicht in dem
> Python-Skript "and" und "&" verwechseln ...  :-(
>
> Hier die korrekte Version.

Ah, besser :-) - danke nochmal!

Von der Annahme ausgehend, dass der Prozessor dann ein Cortex-M ist 
(also Thumb-only), sieht der Code noch nicht hundertprozentig sinnvoll 
aus, siehe unten (Resetvektor zeigt auf 0x08008415, das sollte 
vermutlich dann ab Adresse 0x8414 in der Datei sein (low-bit wegen 
Thumb-Modus)). Die restlichen Exception/IRQ-Vektoren sehen auch passend 
aus.

Dann bin ich mal auf die Hardware gespannt, morgen soll sie kommen. Der 
Schraubendreher läuft schon warm... ;-)

-- Michael

PS: Hier die ersten paar Instruktionen disassembliert, da werden 
Registerwerte ausgelesen, die nach Reset zufällig sein können. Es kann 
natürlich sein, dass der ARM ein Startup-ROM besitzt, das schon einiges 
vorinitialisiert...

0x8414:  LDR  R0, [R4]
0x8416:  CMP.W  R8, #0
0x841A:  ADR  R3, #0x1BC
0x841C:  MOV  R2, R5
0x841E:  MOV  R1, R6
0x8420:  BEQ  #0x8438
0x8422:  BL  #0x187C8
0x8426:  ADD.W  R6, SB, #2
0x842A:  B  #0x8448
0x842C:  MOVS  R2, #0
0x842E:  MOVS  R1, #3
0x8430:  LDR  R0, [R4]
0x8432:  BL  #0x18856
0x8436:  B  #0x8414
0x8438:  BL  #0x18744
0x843C:  ADR  R1, #0x198
0x843E:  LDR  R0, [R4]
0x8440:  BL  #0x188B0
0x8444:  ADD  R0, SB
0x8446:  ADDS  R6, R0, #2
0x8448:  ADD  R2, SP, #8
0x844A:  MOVS  R1, #2
0x844C:  MOV  R0, SL

[Michael Engel (Gast)]

So, der A-01 ist angekommen.

Und es ist (mindestens...) ein Dualprozessorsystem. Auf der Platine 
findet sich ein STM32F205VCT6 (Cortex M3 mit 256 kB Flash) und - leicht 
zu übersehen - ein SIL F330, also ein C8051F330 von SiLabs.

Ausserdem ist noch als weiteres großes IC ein (vermutlich) Custom-Chip 
von Roland zu finden mit der Aufschrift RS100036992-100.

Ganz schön viel Aufwand für das kleine Teil - aber mit Grafikdisplay, 
MIDI, USB und Bluetooth ist ja auch einiges an Funktionalität vorhanden.

-- Michael

[J. S. (engineer)]

Hast Du das nun hinbekommen, mit dem Extrahieren des updates? Was wäre 
das Ziel?