Current Status Of Gnu/gpl Infringement?


jose1711

Member
Joined
Apr 27, 2007
Messages
71
Age
42
Location
Slovakia
Website
Visit site
i am curious what is the current state of gnu/gpl fulfilling/infringement from the gph side. i have read some forum posts on this matter. so it seems that:

1) kernel sources + firmware 1.4.0 have been released - were some time ago and imo they are a bit outdated as compared to the current 3.0.0

2) incomplete mplayer sources are out as well - important parts regarding hw decoding are excluded rendering creation of improved movie player somewhat impossible

3) unknown status of uboot sources

please correct me and/or add some relevant info. i bet djwillis would be the man to ask first but i just don't have the heart to bug him with direct PM :)

cheers,

joe
 
1) the latest source is, to my knowledge, always in the gph svn
2) all gpled parts of mplayer are there as well, that excludes the kernel module which handles the hw decoding, but thats fine with gpl afaik.
3) no idea, afaik they are partially available.
 
The source to the mplayer module would be extremely helpful to developers, as I believe it would explain how to do some things currently unknown such as fine coarse scaling.
 
fw3.0 still uses and oldish kernel - not much as changed there.

incomplete mplayer sources GPH have no power over. Magiceye's themselves refuse to publish both source code and documentation concerning hardware mpeg decoding. However, since mplayer is compilable without those sources it's not a gpl violation.

uboot sources have been released, and people have built there own uboots, so I assume they are complete.
 
well, they licence individual codecs/functions of the mmsp2 separately, so i guess they wouldn't like it if someone did a free implementation.
 
Convincing, but can't anyone reverse engineer it/part of it? am just asking because I know very well how easy it is to reverse engineer software written in modern languages like Java\.Net\ActionScript etc...
What would be needed for it to be reverse engineered? or is that completly impossible?
And what about GPH giving MagicEye a good offer for part of the specifications? the sales of the GP2X will increase well if it had a fully playable PSX emulator/other applications that developers can come up with using these info (although I doubt GPH would ever consider this, they didn't even license wma\wmv as they were planning earlier).
 
funny dignsys who made the module states that
"Encoder works, but still have unknown problems" http://www.dignsys.com/multiboard/board/ab...um=2&down=1

and when you say video decoder chip do you mean the SA7113H ? (if its that then philips has the data sheets i think)
http://www.nxp.com/pip/SAA7113H_V2.html

the chip seems to communicate with the i2c spec http://www.nxp.com/acrobat/literature/9398/39340011.pdf

and another question do they use CX25874/5 as an encoder chip ?
http://www.conexantsystems.com/products/entry.jsp?id=116

i would really like to know what chip they use ? (im very interested in embedded hardware solutions)
 
I believe you can't get the specifications. If you license there codecs for playing divx/mp3/ogg/etc then you get send a binary module that contains those codecs and nothing else (well, apart from how to actually use the binary module of course)

The difference in reversing the binary module and reversing a modern language is great. In a modern language you can write lots of small modules and see what is created. You can then reverse the "what is created" back to an estimated of the original code. However, with the magiceyes code you the code but nothing to produce it. So you basically get "move 0 to register 42951, move 52 to register 42959, repeat until register 42926 = 1". Lot more difficult to reverse.

evol: I believe they are talking about the en/decoder chip built into the mmsp2 - the one that can decode mpeg in hardware.
 
In fact I would have to disagree with you Squidge about this, what happens when reverse engineering modern languages is more of the following: The executables here are not in machine language, but instead in the virtual machine's language, so they are less complicated, and thus, can be decompiled directly to the original code without having even an IDE set up, the code someone will get from decompiling a C# dll is the same exact code the developer wrote (but without the comments), you will even get all original variable names and function calls.
I made a research for simillar tools to decompile C and C++ codes, but there are non, I even remember hitting a wall in the end that had a sign on it saying "A C\C++ decompiler is an animal that doesn't exist!".
 
From the DCC decompiler's site:
QUOTE
We do not provide support for this decompiler, if you email, you'll get the standard reply. However, we participate in the Boomerang open source project

From Boomerang's site:
QUOTE
Machine code decompilation, unlike Java/.NET decompilation, is still a very immature technology, so if you're hoping to decompile a large binary with this release you will be disappointed.

And I have just tried REC 2.1 on a quiet simple executable, nothing useful, this animal still doesn't exist :(
 
Just to chip in on this and confirm what others have said.

At the current moment GPH are in full compliance with the letter of the GPL on there current release, all GPL code used is available from there SVN server and indeed builds, including U-Boot and mplayer (that said they can be a real bitch to build but that is not the same as ‘wont build’).

The issues people mention around the binary MMSP2 H/W module or the GPH menu apps and such are a non issue from the GPL point of view as they do not feature (as far as we know) any GPL infringements or (L)GPL code that is linked in a way that is not compatible with the licences.

It is fair to say GPH and its partners/suppliers could be well advised to take a more open and community focused approach with source code and specifications but there is no compelling or legal reason for them to do so.
 
/kernel/2.1.x/drivers/media/video/ibmmpeg2.h
seems to be for conexant CS3310 a seek error correction chip that should be used with a fieldprogrammablegatearray and in this case it,s a xilinx one (could they have used a fpga for video en/decoding ?)
 
sehs33 said:
In fact I would have to disagree with you Squidge about this, what happens when reverse engineering modern languages is more of the following: The executables here are not in machine language, but instead in the virtual machine's language, so they are less complicated, and thus, can be decompiled directly to the original code without having even an IDE set up, the code someone will get from decompiling a C# dll is the same exact code the developer wrote (but without the comments), you will even get all original variable names and function calls.
I made a research for simillar tools to decompile C and C++ codes, but there are non, I even remember hitting a wall in the end that had a sign on it saying "A C\C++ decompiler is an animal that doesn't exist!".
C\C++ decompiler does not exist because when you compile with proper optimization turned on, not only all variable/function names are removed, but also program's original structure is destroyed. The compiler's job is only to keep the functionality of the code, so it can (and does) reuse memory for variables, keep some of them in CPU registers, inserts some functions into others and does various other kind of mess. So it's simply impossible to get the original source code back.
Although the binaries can still be reverse engineered by analyzing the disassembled asm code with good amount of effort.
 
Last edited by a moderator:
evol said:
/kernel/2.1.x/drivers/media/video/ibmmpeg2.h
seems to be for conexant CS3310 a seek error correction chip that should be used with a fieldprogrammablegatearray and in this case it,s a xilinx one (could they have used a fpga for video en/decoding ?)
No, the registers are built into the mmsp2. I know which registers the binary lump users, but I've no idea as to actually what values to write.

For example, I know that 0xC0004020 is macroblock parameters, 408C/E is the quantizer matrix data save, RL buffer is at 0x4096/8, 419A/C is the h/w block line buffer, 4124 is Luma offset, 4126 is CB offset, 4128 is CR offset, there seems to be status bits at 4000, and appears to be a FIFO somewhere in there also. This is from just looking at a dead listing - I've no actually stepped through the code and tested.
 
Last edited by a moderator:
Back
Top