SamyGO

It's little different than caring. We don't have most of kernel modules as you indicated. SmartSmurf also interested to reverse engineering kernel modules... But It's not the solution because Samsung move most of modules code into exeDSP, which is ~36 MB ARM executable that is virtually responsible from everything on this TV... So even if you fully produce those kernel modules source codes, you can't use or understand that code.
Having ddwrt like distro is good but does it worth to all that reverse engineering or do we have enough developer power for the job?

Okey, I want to say that start first but it's already started.
You can join the development

Do you plan to create new project for just reverse engineering those kernel modules? Why do you think you can't make it here?

If anyone reverse engineered those modules and could release working real (not just wrapper code) modules, than we could already put re-created exeDSP from scratch for switching channels... or we could just try to port XBMC or LinuxMCE instead of Openwrt. Problem is that, there is no developer working for reverse engineering those modules... Also there is a cruel "time" constraint because TVs are not like routers that ddwrt or openWrt developed for.. You can hack a router and could use for 5 or 10 years. But TV's life is much shorter. Nearly 3-4 years. After, CCFL's light gone dimm or plasma doesn't work at it's first days. Also led shines dimmer too. So it doesn't mean anything if stable working code is ready at 2020...
~2 years ago, there is Samsung A series. Today, no one wanted to run program on it, nor wanted to develop. If some one develop any platform for A series TVs, probably no one will use it except the developers od that code. It will be same for B and C series soon, when D series introduced, with Tegra 2 or AMD Fusions CPU...
Also Google TV platform looks like will take over every other platform and leave no surrenders behind... We are playing here and enhance firmware as we could until that judgement day comes. So it's not really logical to try to put efforts to make new platform. Looks like futile job... Things might be different if we have true kernel module sources.

doctorzoidberg wrote:I think that reversing samdrv.ko is the first thing to do. Having an open source driver that works with the original exeDSP binary would be a good starting point.
About exeDSP, I know that disassembling a huge executable is a hard job, but...do we _need_ to reverse all that code? I don't think so, the only important part is the hardware access, the user interface can be completely skipped.
IMHO it's worth a try, even if we don't have enough "developer power" to finish the job. If we show the world that our job is valuable, I'm pretty sure that willing developers will join the project.

but if you rewrite the samdrv.ko you get just an interface from hardware <-> exeDSP and not from hardware <-> linux. so you need also to port all aplications to this "exeDSP" interface you like to use (dvbtools x server...).

arris