ucodes & co

[pcgeil]

ne ne :-) ich meinte, ob es das romfs auch bei der X300t gibt.

Dass es die Acror Box hat, das weiß ich.

[Hoernchen]

Nö, wie gesagt, xenv, bootloader, certs, nochmal xenv, das wars.

[sirius01]

Nur mal so eine Idee ? ? ? ?

Wenn man während des Bootvorganges die CPU kurzzeitig auserhalb der Spezifikation betreibt (gepulste Unterschreitung der Betriebspannung oder ähnlich)
könnte es doch passieren das einige Befehle übersprungen oder gar nicht richtig ausgeführt werden. In diesen Falle wären die Logs ganz interessant. Es ist eine ziemliche Glücksache. Dieses Verfahren hatte bei Smarten Karten  vor Jahren zum Erfolg geführt. Ich habe derzeit leider :'( keine Möglichkeit dieses Auszuprobieren. Es ist halt nur eine Idee. Vielleicht hilft es uns ja weiter.

gruß sirius01    

[Hoernchen]

Geht nicht, das ist nicht nur eine CPU, ich würde dann den gesamten SOC ins Chaos stürzen so das überall irgendwas passiert. Um das selektiv nur bei der XPU zu machen müsste ich ja den Chip decappen, wenn jemand die Mögichkeit hat direkt am Chip rumzuspielen könnte derjenige aber auch gleich direkt die Hardware angreifen.

[pcgeil]

also das direkt an der Hardware rum manipulieren ...
man müsste ja zuerst mal den kunstoff entfernen und dann anfangen, die einzelnen bereiche zu identifizieren

aber das blöde dabei ist ja, man kann den smp8634 Prozessor nicht bei den gänigen Distributoren kaufen. Also geht für jeden Versuch eine Box drauf.
Also wie man prinzipiell vorgeht, das weiß ich :-)

Hab vor kurzem ein CMOS NAND Gatter mit ESD Test gestresst und dann optisch überprüft, was genau kaputt gegangen ist.
Das PDIP Gehäuse haben wir sehr einfach entfernt gebracht 
Nur dürfte der Chip allein von der Struktur meilenweit heftiger sein.

Wenn man es richtig macht, dann funktioniert ja der Chip noch, obwohl der Waver frei gelegt ist.

[Hoernchen]

Klar kann man das machen, wenn man halt die nötige Ausrüstung und vor allem Zeit hat. Würde mich auch mal interessieren wie sicher denn die Hardware selbst ist, denn die besteht ja eigentlich "nur" aus einer Hand voll erworbener Hard- und Soft-IP-Cores (MIPS, ..) und viel glue logic dazwischen. Bei den meissten Leuten mit entsprechenden Kenntnissen und Ausrüstung scheiterts halt am Zeitaufwand.

[Hoernchen]

..Und es gibt es gibt doch neues.
Ich ging ja bisher immer davon aus das die wince ucodes im xloadformat vorhanden sind, was aber wohl falsch war. Nach mehreren genaueren Blicken auf die libprivate.a aus mrua 2.8.0.1 (auf der Suche nach macrovision & hdcp ) fiel mir auf das dort auch nur der irqhandler als xload eingebettet ist, alle anderen ucodes aber ein sehr seltsames Format das keine Ahnlichkeit mit den xrpc ucodes hat besitzen. Ich gehe nun also davon aus das in wince sehr wohl die ucodes in den dlls herumliegen, aber man (= ich mit xrpc scanner) sie halt bisher nie gefunden hat da das Format völlig anders ist. Leider muss ich zugeben das mein mips-assembler dann doch nicht ausreicht um die ucode-ladefunktion aus der libprivate wirklich zu verstehen ohne mehr zu raten und zu vermuten (nicht zuletzt dank unaligned access und damit verbundenem instruktionschaos und halfwordgetausche), wäre also gut wenn sich das mal einer anschaut...

[pcgeil]

Das hört sich doch schonmal ganz vielversprechend an 

@Hoernchen
Wie hast du die ucodes in der libprivate.a lokalisiert?
Bzw. gibt es auch einen Header, nach dem man suchen kann?

[Hoernchen]

Die ucodes selber sind relativ einfach zu finden, libprivate.a ist ein bzw mehrere "ar"-Archive, nach dem Entpacken (siehe topic "libprivate.a & IDA and mips elf....") kann man einfach den Dateinamen und -grösse folgen
Am sinnvollesten ist der Blick in libemhwlib.a_libmodules.a_AudioEngine.o, funktion set_Microcode, dort sieht man direkt den verweis auf audio_microcode_tango2_bin in der data section wo dann der ucode beginnt, dank diesem unauffälligen Namen erkennt man die ucodes & co auch sonst immer leicht. Diese Funktion ruft dann erstmal ucode_load_microcode aus der libemhwlib.a_libmodules.a_libucodeinterface.a_ucode_load_microcode.o auf, vorsicht, die relevantesten Argumente werden dem Stack übergeben, man muss also mal kurz herumrechnen.

Man muss das alles einmal selber nachvollziehen und anhand von

Code: [Select]

DCCSP(pDCC->pRUA, audio_engine0, RMAudioEnginePropertyID_Microcode, &audio_ucode, sizeof(audio_ucode));
in mrua_SMP8634_2.8.0.1_dev.mips\MRUA_src\dcc\src\dcc.c den Ablauf samt übergebener structs verfolgen.

Tipps:

• audio_ucode.Address = 0;
• DCCSP ist im ein komplexes makro was aber auch nur auf RuaSetProperty hinausläuft, siehe dazu http://www.t-hack.com/wiki/index.php/RUA.



• Allgemein existieren alle gbusfunktionen aus mrua nur im Kernel selber, als
  

Code: [Select]

RMuint32 gbus_read_uint32(struct gbus *pgbus, RMuint32 byte_address)
void gbus_write_uint32(struct gbus *pgbus, RMuint32 byte_address, RMuint32 data)

d.h. bei einem Aufruf ist zum Nachvollziehen einzig und allein relevant was in $a1 und danach in $v0 bzw zum schreiben in $a1 und $a2 steht weil

• die gbusstruct in $a0 die durch ganz mrua mitgeschleift wird kann man meisst völlig ignorieren.

[Hoernchen]

iptvplatform.dll:
audio_microcode_tango2_bin: .data:01D4C464
video_microcode_tango2_bin: .data:01E29100
crc_microcode_tango2_bin: .data:01E772FC
sha1consumer_tango2_demux_bin: .data:01E7FFAC erkennbar am padding, dem traurigen chinesensmiley ¦(
streamcapture_microcode_tango2_bin: .data:01E7FC88
xcrc_microcode_tango2_bin: .data:01E7EFC4 erkennbar am padding, 0xDEADFACE
demuxpsf_microcode_tango2_bin: .data:01E77B24

funktion ucode_load_microcode beginnt bei .text:02E22354

Nun müsste sich halt nur noch wer mit der Ladefunktion auseinandersetzen

[mce2222]

sehr schön... damit können wir uns nun ein linux kernel modul zusammenbauen das auf der x300t funktionieren wird (das ist der leichte teil)

die echte Herausforderung wird dann aber sein die API zu rekonstruieren.
hoffen wir mal das die nicht allzugrosse Änderungen im Vergleich zu der Linux API hat, wo wir die sourcen haben.

[chrishx]

Das Pinout is bekannt, da lässt sich nichts mit anfangen.

wo findet man das? selbst wenn man nichts damit anfangen kann, würds mich interessieren.

[Hoernchen]

http://narf.pastebin.com/m5ff29a84

[bazi]

Ich fange gerade erst an, mich mit dieser Box auseinander zu setzen, darum erschlagt mich bitte nicht gleich, wenn meine Idee schonmal wo genannt wurde oder abwegig ist

So wie ich das noch von meinen diversen Recherchen zu embedded Linux Geräten weiss, gibt es immer wieder den Ansatz, dass man, wenn man Hardwareteile nicht aktiviert bekommt, lädt man über einen kexec ähnlichen Bootloader einen Kernel, nachdem das originale Betriebssystem diese Teile aktiviert hatte.
Vielleicht ist dies hier ja auch möglich...
Zwar nicht ganz an die uCodes gekommen, aber vielleicht ist die Hardware nutzbar.

[Hoernchen]

Das Problem sind nun weniger die ucodes als viel mehr die Kommunikation die grösstenteils via IRQ-Handler stattfindet, da dieser WinCE-spezifisch ist hab ich also bestenfalls einen zwar prinzipiell funktionierenden Chip bei dem ich aber keine Ahnung habe wie ich ihn benutzen soll. Sieht alles nich so gut aus...