This forum is NOT FOR DUMMY USERS questions or problems but DEVELOPER.My unordered TODO list:
1. Change the loader code so that it would not require keypress to activate.
2. Change the "power" button (DtvKillChild function) so that it would terminate the whole program tree (so you can run scripts from menu, and it would kill a program executed by /bin/sh, and not only the sh process).
3. Write API design as some text document, so it can be used/extended by others.
4. Make an installer, so mainmenu.so would be loaded from /mtd_rwarea/bin/plugins and not from the USB stick that can be removed and this would cause exeDSP crash.
x. Restore hidden menus like PVR, time-shift in C550.
x+1. Implement existing SamyGo features like ARFix, audio stream switcher, internet browser
exeDSP reverse engeneering
Re: exeDSP reverse engeneering
As IDA 5.50 has a bug in MIPS - it assumes that $gp has the same value in all functions in the whole program, while this is incorrect for huge apps like exeDSP
Here http://www.multiupload.com/YN3GIQUV4M I've uploaded modified IdaPython scripts that would manually fix operands and add xrefs in functions.
The original code was taken from here: http://syscall.eu/#mips I've just modified it so that $gp value is recalculated for every function. As I don;t know python - code is ugly, but it works.
Here http://www.multiupload.com/YN3GIQUV4M I've uploaded modified IdaPython scripts that would manually fix operands and add xrefs in functions.
The original code was taken from here: http://syscall.eu/#mips I've just modified it so that $gp value is recalculated for every function. As I don;t know python - code is ugly, but it works.
Re: exeDSP reverse engeneering
All Trident C550/C530 models are based on MIPS CPUs. There are 2 variants - MStar (T-MSX) and Trident (T-TDT). MStar is little-endian. Trident is big-endian and has 2 CPUs, though Linux runs only on first one (second is used for video decoding purposes).
So Samsung have published 2 toolkits for compilation and 2 variants of sources.
Published sources contain just kernel code. There is no driver for audio/video/tv-tuner or anything device-specific that may be reused by us in those sources. The only thing you can use these sources for - is to build NFS/SAMBA/USB mouse/etc drivers for your kernel and load them later on your TV.
Some time ago Samsung published monolithic.ko sources by mistake, but they were immediately removed from their site and those sources cannot be used by us as they are non-GPL.
So we need to continue reverse engeneering, and currently I have a good progress there. For example now I can set nearly any video mode on Trident-based TV and picture would be extended by hardware to fit whole screen. 256-color modes are extremely fast, 16-bit are nearly useless as video hardware short words are little-endiand while CPU is big-endian, and you'll lose time by double-buffering and switching bytes, 32-bit modes are slow and you have to add alpha channel to each pixel. Hardware specs from Trident would be extremely helpful here, but they've refused to send them to me.
Currently I have a problem outputting audio on TV ( just can't find how to do that), and dmesg errors in USB HID drivers with connection of USB mouse/keyboard. Maybe someone would have more luck there?
And one note regarding exeDSP reversing. We can't enable PVR. Period. There is no code for it. Just compare list of tasks registered in CTaskManager class from C650 and our C550 model - C650 have several tasks dedicated to PVR, while ours don't even have code for them. The same with 3D. But with 3D we don;t have hardware either.
But if you'll decompile libSDAL.so you'll see that it exports tons of functions with PVR in its names. So I assume that it can be used to write our own recorder. But it would require lots of time to figure out how to use these funcs.
So Samsung have published 2 toolkits for compilation and 2 variants of sources.
Published sources contain just kernel code. There is no driver for audio/video/tv-tuner or anything device-specific that may be reused by us in those sources. The only thing you can use these sources for - is to build NFS/SAMBA/USB mouse/etc drivers for your kernel and load them later on your TV.
Some time ago Samsung published monolithic.ko sources by mistake, but they were immediately removed from their site and those sources cannot be used by us as they are non-GPL.
So we need to continue reverse engeneering, and currently I have a good progress there. For example now I can set nearly any video mode on Trident-based TV and picture would be extended by hardware to fit whole screen. 256-color modes are extremely fast, 16-bit are nearly useless as video hardware short words are little-endiand while CPU is big-endian, and you'll lose time by double-buffering and switching bytes, 32-bit modes are slow and you have to add alpha channel to each pixel. Hardware specs from Trident would be extremely helpful here, but they've refused to send them to me.
Currently I have a problem outputting audio on TV ( just can't find how to do that), and dmesg errors in USB HID drivers with connection of USB mouse/keyboard. Maybe someone would have more luck there?
And one note regarding exeDSP reversing. We can't enable PVR. Period. There is no code for it. Just compare list of tasks registered in CTaskManager class from C650 and our C550 model - C650 have several tasks dedicated to PVR, while ours don't even have code for them. The same with 3D. But with 3D we don;t have hardware either.
But if you'll decompile libSDAL.so you'll see that it exports tons of functions with PVR in its names. So I assume that it can be used to write our own recorder. But it would require lots of time to figure out how to use these funcs.
Re: exeDSP reverse engeneering
Answer is very simple. There is no TV-Tuner driver in Linux OS or exeDSP. All TV decoding is done in hardware (may be by the second MIPS CPU as Trident has 2 CPUs), and Linux part only controls which channel to display on screen, sound volume, and that is all. TV channel data is not coming in any way through the linux part. You can find that yourself by hanging the first MIPS CPU, and TV would continue to play (of cause until TV would be reset by watchdog if it is not switched off).m-rupp wrote:we bypass all from tuner-level to an virtual-tuner that sitting between him and the os-level.
in case we use an open-source-tuner-driver to generate an v-tuner we can use the digital-signal from tuner for two tasks.
I would not tell that it is absolutely impossible to "catch" the data that passes through the second CPU, but this would be a complex task as we don't have any specifications on trident hardware, nor sources of binary files that are loaded to the second CPU.
Probably it would be somewhat easier to reverse engineer libSDAL.so and libTrident.so, seems that they provide code to capture data from a TV, at least function names give such hope. I have not looked at them (busy with some other task), but these functions don't look like stubs.