MIDI-Firmware-Updates "entschlüsseln"

Gast #5089190
Lesenswert?

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
Gast #5089215
Lesenswert?

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
#5089221
Lesenswert?

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.
Gast #5089273
Lesenswert?

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
Gast #5089282
Lesenswert?

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.
Gast #5089447
Lesenswert?

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:
1
Paket 1:
2

3
00  F0   // SysEx
4
01  41   // Roland
5
02  10   // Device 0x10
6
03  7F   // Model 0x7F
7
04  12   // Send
8
05  00 00 00  00   // Address 0x00
9

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

16
29  18  // Checksumme
17
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:
1
SysEx-Daten: (20) 20 0B 01 20 18 04 00 (44) 08 5D 20 00 08 05 1D (48) 
2
Dein File:        A0 8B 81 A0 95 84 00      88 DD A0 80 88 85 9D
3
                  -- -- -- -- -- -- --      -- -- -- -- -- -- --
4
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
#5089486
Lesenswert?

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.
Angehängte Dateien:
Gast #5089583
Lesenswert?

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...
1
0x8414:  LDR  R0, [R4]
2
0x8416:  CMP.W  R8, #0
3
0x841A:  ADR  R3, #0x1BC
4
0x841C:  MOV  R2, R5
5
0x841E:  MOV  R1, R6
6
0x8420:  BEQ  #0x8438
7
0x8422:  BL  #0x187C8
8
0x8426:  ADD.W  R6, SB, #2
9
0x842A:  B  #0x8448
10
0x842C:  MOVS  R2, #0
11
0x842E:  MOVS  R1, #3
12
0x8430:  LDR  R0, [R4]
13
0x8432:  BL  #0x18856
14
0x8436:  B  #0x8414
15
0x8438:  BL  #0x18744
16
0x843C:  ADR  R1, #0x198
17
0x843E:  LDR  R0, [R4]
18
0x8440:  BL  #0x188B0
19
0x8444:  ADD  R0, SB
20
0x8446:  ADDS  R6, R0, #2
21
0x8448:  ADD  R2, SP, #8
22
0x844A:  MOVS  R1, #2
23
0x844C:  MOV  R0, SL
Gast #5090663
Lesenswert?

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
Angehängte Dateien:

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren