Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - andi
31
hallo,
also ich setze ehrlich gesagt auf die linux variante! mir ist klar, das das ohne sdk oder zumindest ordentliche quellen und zusatzinfos nicht gehen wird!
aber ich hoffe einfach mal das irgendwann die die sourcen veröffentlicht werden und wir dann natürlich den vdr auf die box bringen! ich bin seit einigen jahren vdr'ler und für mich kommt eigentlich auch nix anderes in frage! eigentlich geht es nur noch darum für die zukunft auf das richtige pferd zu setzen ;-)
aber da wir ja von der nativen linux variante noch meilen weit entfernt sind meine frage ans forum, wie genau man nun eine neue firmware in die box bekommt? mce2222 spricht in einem anderen thread davon eine remote-debug session mit visualstudio laufen zu lassen .. da stellt sich für mich die frage, wie du an die quellen der anwendung/treiber kommst um diese überhaupt erstmal mit debug-symbolen etc. zu compilieren?? hast du da etwa sourcen?
grüße
andi
32
hallo,
also 20cm jtag-kabel könnten schon zu lang sein! habe beispielsweise zur programmierung von atmega8 uc ein selbstgebautes jtag genutzt, da konnte ich die "langen" kabel nur nutzen, wenn ich ein delay zwischen die einzelnen byte schreibe/lese operationen eingefügt habe!
also evtl. doch noch mal mit einem kürzerem kabel versuchen, die passiven adapter sind einfach zu anfällig!
grüße
andi
33
hallo,
>>alles richtig... aber unverschlüsselter boot code läuft nur auf development SMP863x der ES serie...und der XOS muss eine version Mxx und nicht Pxx sein.
also du denkst, da ist mit den versionen, die in den t-com boxen verbaut sind keine blumentöpfe zu gewinnen?
d.h. also ich muss, wenn ich fremden code starten will den umweg über NK.BIN gehen?
was gibt es denn sonst für möglichkeiten die box besser zu nutzen? an windows ce wird man auch nicht wirklich arbeiten können, da ist doch auch alles zu!
was schwebt dir da vor??
ich habe auch gehört das das sdk nicht der hit ist, die code qualität soll super schlecht sein, aber es gibt z.b. directfb treiber die über hdmi z.b. h264 videos hardware beschleunigt abspielen können. dann soll es noch einen closed-source treiber geben, der multi-layering usw. kann.
ob bei dem sdk auch die ucodes für die video-decoder dabei sind, weiß ich nicht.
kann man den vielleicht im laufenden betrieb bei einer box mit original sw auslesen? ich weiß nicht genau wo der liegt, ich kenne ucode nur von einigen freescale dma controllern, da liegt er nach dem laden bspw. einfach im sram!
ich denke die linux lösung wäre nur interessant, wenn man mehr infos bekommt und wenn mal eines tages in den untiefen des internets (irc, torrent, oder oder oder) das linux sdk auftaucht. dann hätte die opensource community auf jedenfall die beste basis für erweiterungen, das das aber nicht gewollt ist schon klar! aber schließlich gab es schon viele, bei denen die os-erweiterungen das eigentliche produkt erst so richtig interessant gemacht hat.
btw. ich habe noch keine box zum basteln, welche sollte ich denn dazu nutzen, die x300t oder die x301t?? evtl. gibt es ja neben den benannten unterschieden (thermische probleme, ..) noch andere hindernisse, welche z.b. die "alte" als bessere plattform erscheinen lassen??
grüße
andi
34
hallo leute,
ich vor kurzem auf die box gestoßen und würde gerne mithelfen diese etwas zu "erweitern".
ich bin noch dabei den bootprozess zu verstehen. als quellen dienen mir dabei nur die infos aus dem wiki, aber es scheint ja auch nicht mehr öffentlich zu geben ;-)
leider ist mir noch nicht ganz klar, welche schritte im bootprozess evtl. veränderbar sind (externer flash) und welche fix (sprich im sram des smp8634). im moment verstehe ich das so: XOS ist der erste bootloader, welcher wahrscheinlich im internen sram liegt. dieser wird nicht veränder sein, updates evtl. durch sigma selbst. er initialisiert die speicher (siehe parameter XENV) und evtl. auch weitere hardware, kopiert dann evtl. teile aus dem externen flash in den ram und springt dort hin (x.boot 0x00800000).
evtl. kann man den bootloader an dieser stelle auch dazu überreden unverschlüsselten code zu starten?!
leider ist es mir bisher noch nicht gelungen das linux sdk von sigma aufzutreiben, ich weiß das es das nur mit vertrag gibt und das dann auch noch mit verschiedenen leveln (mit/ohne grafiktreiber usw.) aber evtl. kann man es ja irgendwo her besorgen? hat da jemand ne' idee??
das sdk kann wahrscheinlich weiter auch einige offene fragen beantworten, beispielsweise liegt ihm auch der sigma bootloader "yamon" im quelltext bei!
meine vorstellung wäre ja, diesen gegen einen port von u-boot für die cpu auszutauschen. damit wäre auch eine perfekte basis um linux zu booten geschaffen. aber soweit ist man ja noch nicht ;-)
grüße und frohe weihnachten
andi
