working linux ucodes

[Hoernchen]

They are loadable, but we have to find a matching mrua version for the wince/microsoft irqhandler.

[Mulder3]

They are loadable, but we have to find a matching mrua version for the wince/microsoft irqhandler.

Thats exact what i thought, i was unable o find the irqhandler microcode.
What about the APIs? are they compatible with Linux? (i.e. the microcode is the same on WinCE/Linux?) I read somewhere that sigma microcodes are now compatible with standard DirectFB APIs. this means that apps can now be coded without mrua/libemhwlib libs?

What about WinCE?i read somewhere on this forum that we can't code graphical programs using standard WinCE API(Or .net WinForms) because tv2engine talks directly to hardware(has sigma libemhwlib libs statically linked or something) to draw on screen? But the WinCE includes a SMP GDI driver...

Can someone clarify me on this... After the microcodes are loaded can we use standard Linux/WinCE APIs to draw on screen? If Linux has a sigma kernel module that implements DirectFB interface and WinCE has a sigma GDI driver, it should be possible... if not...why not?

[Hoernchen]

The most im important fact about the smp86xx this that the smp86xx is just a em862x on steroids, this means the main cpu is MIPS instead of ARM and there is a second cpu called the XPU, otherwise it's mostly the same, the demux/a/v/gfx/mpeg engines are just like those in the em862xx.
Back in the day of the em862x there was already an irqhandler, but without the xpu it was just unencrypted loadable ARM code running on the only cpu the em862x had, which handled specific interrupts for the demux/a/v/gfx/mpeg engine and communication between mrua and those chip parts like "automatic" dma transfer tasks from and to the demux engine buffer, all this while considering vync timings to prevent screen flickering, so it was more or less just an addition to the linux irqhandler.
On the smp86xx however this changed, probably due to high computational demands for handling HD content and the need for more security.
Now there is a second 200mhz MIPS cpu, called the, xpu and while the irqhandler is still just some code which lives at the end of dram controller 0, it is now encrypted and signed because it will be executed by the XPU.

So while the irqhandler is platform independent like the whole mrua package it looks like it is bound to microsoft specific certificates, so we can't just load an linux irqhandler, we have to find out which linux mrua package the wince irqhandler version corresponds to. This is necessary because the microcode seems to be rather static but the mrua<->irqhandler interface is not so using a random mrua version will fail.

There is a sigma designs directfb version which seems to be able to communicate directly with the irhandler/gfx engine, but all this sigma specific code has been stripped from the popcornhour directfb version - a common directfb release works, but without gfx engine support it has to rely on the 300mhz host cpu which is no reaaaally fast.

And as for the last question - http://www.t-hack.com/forum/index.php?topic=114.msg910#msg910, after starting the tv2client and hiding it it works.

[Mulder3]

The most im important fact about the smp86xx this that the smp86xx is just a em862x on steroids, this means the main cpu is MIPS instead of ARM and there is a second cpu called the XPU, otherwise it's mostly the same, the demux/a/v/gfx/mpeg engines are just like those in the em862xx.
Back in the day of the em862x there was already an irqhandler, but without the xpu it was just unencrypted loadable ARM code running on the only cpu the em862x had, which handled specific interrupts for the demux/a/v/gfx/mpeg engine and communication between mrua and those chip parts like "automatic" dma transfer tasks from and to the demux engine buffer, all this while considering vync timings to prevent screen flickering, so it was more or less just an addition to the linux irqhandler.
On the smp86xx however this changed, probably due to high computational demands for handling HD content and the need for more security.
Now there is a second 200mhz MIPS cpu, called the, xpu and while the irqhandler is still just some code which lives at the end of dram controller 0, it is now encrypted and signed because it will be executed by the XPU.
So while the irqhandler is platform independent like the whole mrua package it looks like it is bound to microsoft specific certificates, so we can't just load an linux irqhandler, we have to find out which linux mrua package the wince irqhandler version corresponds to. This is necessary because the microcode seems to be rather static but the mrua<->irqhandler interface is not so using a random mrua version will fail.

Yes, i understand this issue, what i was asking is that if we found the irqhandler in xrpc format in WinCE(it must be hidden on some dll, right? on previous versions the audio/video microcodes was in iptvplatform.dll) we can use it with Linux out-of-box? or the Linux microcodes are different? ie, assuming we can find all microcodes we need in wince(binded to our box) can we draw on screen using standard linux framebuffer access(or even PopCornHour DirectFB) out-of-box or the ABI to access microcodes are different?

There is a sigma designs directfb version which seems to be able to communicate directly with the irhandler/gfx engine, but all this sigma specific code has been stripped from the popcornhour directfb version - a common directfb release works, but without gfx engine support it has to rely on the 300mhz host cpu which is no reaaaally fast.

DirectFB is LGPL, unlesse they didn´t touch the original code and just linked it with their code, it should be a GPL violation...

<off-topic/rant>the use of smp86xx by PopCornHour is preventing me from buying it, the PopCornHour is a wonderful device in price/quality/features, no other MediaCenter can beat it on its price segment, but their choice of using that particular chipset was a bad choice in my opinion, why would we a want such a wonderfull Linux Mediacenter if it´s crippled with DRM???</off-topic/rant>

And as for the last question - http://www.t-hack.com/forum/index.php?topic=114.msg910#msg910, after starting the tv2client and hiding it it works.

I don´t understand German, and google translate does an awful job... So i couln't understand on the thread why tv2client has to be started...what about .NET C# winforms?

[Hoernchen]

The irqhandler is embedded in booter.dll, see http://www.t-hack.com/forum/index.php?topic=352.0
The microcodes are not encrypted, so the only thing we need is a mrua which is compatible with our wince irqhandler, then everything should work out of the box.

The tv2client has to be started because it loads all the other dlls and initializes the box, you could do the same thing with your own app.
I didnt't try any .net/c# gui stuff, but if mfc works, .net gui apps should work, too.

[Mulder3]

The irqhandler is embedded in booter.dll, see http://www.t-hack.com/forum/index.php?topic=352.0
The microcodes are not encrypted, so the only thing we need is a mrua which is compatible with our wince irqhandler, then everything should work out of the box.

OK, thanks for the explanation The challenge now is to adapt the mrua/emhwlib to use the WinCE irqhandler...
Sorry to bother you again with questions, but i need to understand this correctly

As far as i know Sigma provides two interfaces to code graphical apps on their platform: low-level libraries like mrua and the ones used in WinCE iptv edition and a more high-level libraries: DirectFB on Linux and DirectX on WinCE, since there is no other platform besides IPTV edition to run WinCE, so we don't have access to DirectX.
However, the majority of Linux based devices are using DirecFB abstraction implemented on top of mrua, so even that sigma doesn´t provide the complete DirectFB source, we could "rip" that DirectFB binary modules and use it? they are standard linux code, not encrypted/signed(assuming we can adapt the code the work with WinCE irqhandler) We don´t need the the DirectFB source code...

Another question is the xrpc certificates, can microcodes/xtasks/whatever run on different boxes from different providers? ie, the certificate the signs the Telekom X300T irqhandler is the same that signs, for example the Portugal Telecom X300T? while, for obvious reasons, the certificate that signs the firmware is unique per provider, i am wondering if the "things" that runs on XPU share a common certificate since they are part of the same iptv platform and providers don´t need to touch or bother with XPU related things(and probably Microsoft doesn't want to give them such control, since they could write custom xtasks that could be bugged and exploited to dump the MS iptv xtask that implements the DRM)

[Hoernchen]

Well, the challenge is not to adapt mrua, we have to find a comaptible version first
But yes, it would be possible to use the popcornhour directfb binary.

The microcodes included in the beta nk.bin are not encrypted, they are just plain binary code which runs on the demux/a/v cpus, so unless there is some magic involved they should work on any smp8634 based device. The Irhandler and other stuff however... while at least in theory any valid cert signed by sigma will be accepted by the xpu it is possible to bind specific certificates to cert types, so I'd say it is rather unlikely, unless the providers are not involved in the whole xpu cert mess at all and microsoft likes to reuse its certs. Or someone has a box which was never booted, so the bootloader never had the chance to bind ithe certificates...

[Hoernchen]

I think I am getting somewhere - there are 3 mrua packages, dev for development chips, facsprod for production chips with facsimile keys from the key package, and prod, the package for.. well.. no idea where the difference between prod and facsprod is, except that I have never seen a linux based stb which uses the prod package. Till now...
Now guess which irqhandler microsoft uses - prod ! There is no magic or secret sauce involved, microsoft just binds the bootloader and xtask1 cert ids to its own certificates, everything else is just prod stuff. I'm glad it took just a year to figure this out

[Hoernchen]

Success. Linux on the x300t, playing a mp3 file. With sound !!!!

[Hoernchen]

Playing a mp4 file actually works, although I had to decrease the linux ram to 38MB because mono tries to reserve memory in dram0, dram1 seems to be completely empty.

Code: [Select]

/ $ mono -nogui cavity_flow_movie.mp4
[dcc.c:41] dccOpen (RUA @ 0x0044e008 DCC @0x0044f038
[dcc.c:558] dccInitMicroCodeEx DCC @ 0x0044f038
[dcc.c:821] dcc_init_demux_microcode DCC @ 0x0044f038
[dcc.c:866] demux ucode doesn't need DRAM
[dcc.c:604] dcc_init_video_microcode DCC @ 0x0044f038
[dcc.c:671] video ucode cached addr: 0x13B808AC, size 0x0007C86A, end: 0x13BFD116
[dcc.c:724] dcc_init_audio_microcode DCC @ 0x0044f038
[dcc.c:788] audio ucode cached addr: 0x139FB23C, size 0x00185664, end: 0x13B808A0
[dcc.c:131] dccInitChainEx DCC @ 0x0044f038
[dcc.c:142] Display already configured and initDisplay=FALSE. Do not reconfigure it!
[dcc_display.c:247] Applying DoubleRate(FALSE)
Commands: (press enter to validate a command)
  q: Quit
  s,z - Stop, p - Play, <space> - Pause, n - Next picture (after PAUSE only)
  + increase speed, - decrease speed, = set speed
  ] Forward I-frame 1x, [ Backward I-frame 1x (if supported, adjust speed with +/-)
  f: seek (if supported)
  v: decrease volume - V: increase volume - _: mute
  E: toggle between dual modes (Stereo->LeftMono->RightMono->Mono)
  <, >: decrease/increase playback speed by 1 ppm
[dcc_video.c:776] Number of video engines: 2
[dcc_video.c:795] Number of video decoders: 32
[dcc_video.c:815] MpegEngine: 0x00000019
[dcc_video.c:822] VideoDecoder: 0x0000001A
[dcc_video.c:847] ALLOCATING 0_DRAM SCHEDULER MEMORY addr: 0x139FB13C, size 0x000000F4
[dcc_video.c:951] video UnprotectedAddress: 0x1297200C, size 0x01089124, end: 0x139FB130
[dcc_video.c:1079] DCCXSetVideoDecoderSourceCodec codec = 2
[dcc_video.c:50] current VIDEO state = Uninit
[dcc_video.c:52] send command = Uninit
[dcc_video.c:75] Now VIDEO state = Uninit
[dcc_video.c:50] current VIDEO state = Uninit
[dcc_video.c:52] send command = Init
[dcc_video.c:75] Now VIDEO state = Stop
Starting MMAP
End MMAP 0x0x2b952000
duration 41 secs
[mono.c:48] got stream info!
[dcc_stc.c:83] **********************DCCSTC SetTimeResolution, stc res: 600
[dcc_stc.c:83] **********************DCCSTC SetTimeResolution, video res: 600
[dcc_stc.c:83] **********************DCCSTC SetTimeResolution, audio res: 0
[dcc_stc.c:175] **********************DCCSTC SetTime, time: 0 res: 600
[dcc_stc.c:216] **********************DCCSTC SetSpeed, N: 1 M: 1
[dcc_video.c:50] current VIDEO state = Stop
[dcc_video.c:52] send command = PlayFwd
[dcc_video.c:75] Now VIDEO state = PlayFwd
[dcc_stc.c:305] **********************DCCSTC Stop
[mono.c:40] got dcc info @ 0x7fb414d8
[dcc_stc.c:175] **********************DCCSTC SetTime, time: 0 res: 600

*****************************
STC = 0 (0 secs)
Video :
Data 1a: st=138f2000 sz=1048576 wr=308415 rd=740160 --> f : 70.59
XFER 1a: st=139f431c sz=1025 wr=1024 rd=0 er=0 --> f : 0.00
XFER 1a: 0
*****************************
now playing
[dcc_stc.c:299] **********************DCCSTC Play
[dcc_video.c:50] current VIDEO state = PlayFwd
[dcc_video.c:52] send command = PlayFwd
[dcc_video.c:75] Now VIDEO state = PlayFwd
File ready 1 times, waiting for EOS
   wait 2 events [0x3 = 0x00020000] [0x1a = 0x00000008]
8< 8< 8< snip ... repeated a few hundred times>8 >8 >8
   wait 2 events [0x3 = 0x00020000] [0x1a = 0x00000008]
   get 0x1a = 0x00000008
inband_event 0x1a with tag=20010
WaitForEOS 0x1a OK
inband_event 0x1a without tag - hwlib already process it
   wait 1 events [0x3 = 0x00020000]
   wait 1 events [0x3 = 0x00020000]
   wait 1 events [0x3 = 0x00020000]
   wait 1 events [0x3 = 0x00020000]
   wait 1 events [0x3 = 0x00020000]
   wait 1 events [0x3 = 0x00020000]
   wait 1 events [0x3 = 0x00020000]
   wait 1 events [0x3 = 0x00020000]
   wait 1 events [0x3 = 0x00020000]
   wait 1 events [0x3 = 0x00020000]
   wait 1 events [0x3 = 0x00020000]
   get 0x3 = 0x00020000
display_inband_event with tag=20010
WaitForEOS display OK
inband_event display without tag - hwlib already process it
EOS_InbandCmd after 8220849 us
[mono.c:96] RMEOSCallback() called, awaiting a command
[mono.c:97] reset remote state to playing
[get_key.c:445] RMremoteResetState()
[dcc_stc.c:305] **********************DCCSTC Stop
[dcc_video.c:50] current VIDEO state = PlayFwd
[dcc_video.c:52] send command = Stop
[dcc_video.c:75] Now VIDEO state = Stop
[dcc_stc.c:305] **********************DCCSTC Stop
[dcc_video.c:50] current VIDEO state = Stop
[dcc_video.c:52] send command = Stop
[dcc_video.c:75] Now VIDEO state = Stop
[dcc_video.c:334] DCCCloseVideoSource()
[dcc_video.c:388] >>>closing video decoder
[dcc_video.c:466] FREE 0_DRAM SCHEDULER MEMORY addr=0x139fb13c size=0xf4!
[dcc.c:53] dccClose (DCC @ 0x0044f038
[dcc.c:56] DCCClose TANGO2 just stops the riscs, it doesn't reset them !


[asgard]

Success. Linux on the x300t, playing a mp3 file. With sound !!!!

Cool 

Well done!

[xmob]

Success. Linux on the x300t, playing a mp3 file. With sound !!!!

Just so I understand this right, you now have a box running Linux with audio and video?  If that's the case, that was exactly my plans for my collection of BT Vision boxes.  Top job!!!   

With a proper build environment, we should now be heading to an excellent network media player.

[Herman]

so youve managed to find a 'new' nix box which uses the correct ver of irqhandler (or just understood what has been around for a while) and then using a fresh install of nix or the pch binaries ?
Either way, top work

[dobo66]

Success. Linux on the x300t, playing a mp3 file. With sound !!!!

I see you have great siccess with linux.
Cool Job !
Unfortunately I'm not .
I booted diferent distribution of Linux but there isn't  any audio or video.
Could you explain where I can get working linux kernel drivers em8xxx.ko, llad.ko for 2.6.15 and coresponding xloads.
My box is kmm8006.
I will be happy for someone to help me get this box running linux.