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.

all avaible : http://svn.gp2x.com/gp2x/tag/

Any idea why MagicEye are refusing? do they consider it a trade secret?

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!".

i thought decompilers for C existed or is it useless ?
http://boomerang.sourceforge.net/
http://www.backerstreet.com/rec/rec.htm
http://www.itee.uq.edu.au/~cristina/dcc.html

and this hexeditor has a nifty feature almost perfect for reverse engineering
http://www.sweetscape.com/010editor/#templates

From the DCC decompiler's site:

From Boomerang's site:

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 ?)

That is a standard header file, not directly related to the MMSP2 specific Linux implementation.

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.

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.

so the info im after is somewhere in dualcpu.o ?

Last time I looked it was in a header file. dualcpu.o just loaded the contents of the header file into ram.

Remember, the code runs on the 940, so all the kernel module can do is load it to ram.

Oh, and http://hexblog.com/decompilation/video/vd1.html

by any chance are these the files your looking for??
http://svn.gp2x.com/gp2x/tag/kernel/2.1.x/.../char/dualcpu.c
http://svn.gp2x.com/gp2x/tag/kernel/2.1.x/.../char/dualcpu.h

is it m4enc_encore.h ? (which i cant find)

Nope, it's 'drivers/char/arm940firm.h' (SVN Version)

yes i looked at that but im really just fishing for clues that points me in the direction of what chip they are using, like in the vrender0 they have other chips who handle 2d and so forth i bet they use some cheap eisc chip like the gmx-1000
http://www.adc.co.kr/product/chip_GMX-1000.asp

Wow, that chip can do a lot. Don't think the gp2x has one that versatile, do you?

Well, they definitely don't use the same chip for hw mpeg decoding in the mmsp that they use in the vrender3d, as I have the documentation for the later, and the mmsp hw is nothing like it.

Thats sounds great! So brilliant!!

Why dont you do it?

There's a vrender in the MMSP2. It's a 2D version of the vrender3d, which I believe is indeed called the vrender0. I don't know if it's a rebranded chip or if MagicEyes owns the chipset (doubt it).

EDIT: As for the idea above, I also doubt GPH can handle any sort of payment more or less for something considered worth money to MES. If GPH cared about developers, they would of gone about the GP2X completely differently, from the hardware and the inspiration behind it. I don't think they understood the market they were feeding with the GP2X, only that they wanted to build a new gadget and could. It seems to be a popular trend in SouthKorea.

after alot of digging i suspect its the 32bit EISC SE3208 cpu from Amazon in the vrender0.
it uses doublebuffered 2d (they call it 2d based on 3d ha!)

http://www.solutionway.com/datasheet/220%2...N_DataSheet.pdf

Edit: hmm.. i can see if they dont want that "opened" the original idea seems that they would ship it as a arcademachine board component

@suppafly: And give you a chance to have full playable PSX? no way

One way to find out, cut it open and compare them .

Seriously

Waait. mplkayer _can_ be compiled sure, but not _as is_. The magic eyes part isn't in a shared lib and dialed up on demand, its part of the binary. (Unless I'm wrong on that point.) As such, they _are_ in disagreement with the GPL.

If its a separate shared lib thats conditionally sucked in, then they would be compliant on that count.

jeff

I would think about the decoder module as a hw driver that mplayer needs to access to output anything, I don't think that conflicts with gpl?
Else closed source vga drivers would as well, wouldn't they?

If you have GPL code, and link in non-GPL code, it is in violation. ie: If someone cannot have everythign availabnle for recompilation of what they have, it is voilating.

If you can recompile "minus some features', thats not compliant. ie: People are losing features.

The GPL's entire purpose is to ensure that when you modify something, you must return it to the pool; if they're static linking in their wokr, but not releasing it, they're breaking the terms.

(I'm just being pedantic, but thats what this post is about

jeff

MMSP2 Decoder program(in 940T) is not static/dynamic linking with kernel/mplayer, only communication via memory/register/interrupt.

Jeff, you can compile mplayer and get exactly the same functions as the original mplayer, as the magiceyes part is distributed as a binary module to upload to >32mb so the 940 can see it. I don't see how this can be a GPL violation as the binary module is completely seperate from mplayer and is loaded via opening /dev/dualcpu.

@squidge if i understand you correctly dualcpu.o reserves
0x03000000~0x03FFFFFF (simplyfied)

it seems peculiar that the vrender0 Eisc Cpu uses that chunk for

GraphicEngineRegisters+TexturebufferMemory

can you tell me anything else about the mem layout for the gp2x that seems "strange" or noteworthy (i really would like to figure this out so bare with me plz, i know i can be uber n00bish)

None of it really feels "strange" as such, but what I can tell you is that Magiceye's "ported" WinCE to the MMSP2 a long time before Linux, and as such the first 32MB of RAM was reserved for the OS, and the second lot of 32MB was dedicated to the 940 (code+data).

The memory areas you state are the default memory areas. However, they can be changed - the reserved area can be dynamically allocated. You can also use pre-allocated or reserved 2D YUV sets. Also you can make your own 2D YUVallocator (940/MPEG processes YUV rather than RGB).

The only thing that is fixed is where the firmware is stored, and that is simply because of the address it was compiled for. Magiceye's can release a binary on request that will work from other locations (but obviously they will not do that for nothing...)

If this is the case (which is great), it might be worth updating the wikipedia page, which makes the situation sound a lot worse. Missing firmware, missing uboot, violation in mplayer.

I've tried to keep it up to date, but there are some very determined people out there who insist there are loads of problems. Recently somebody have been replacing the entire page with "GP2X SUCKS!!!!!".

As Orkie mentions, efforts have been made to clean that article up but people just seem determined to spam that article and overwrite what is 'correct' with misunderstood interpretations or outdated information. It is worth remembering that this is a hobby and should not be the chore it so very often becomes; maintaining Wikipedia against spam is a full time job with very few prospects .

In the end that article (on the subject of the GPL anyway) is much like a number of threads that pop up here every now and then, full of half truths or interpretations that are made from a incorrect understandings or outdated viewpoints. You have to take the view as of now, what is gone is gone and all that.

Whilst I have no great love for GPH as a company and feel they could have handled things very differently the result is the same, to all major intents they are in compliance with the GPL and to mark them otherwise (often on semantics) would be a disservice to them. Especially when you compare them to some of the 'big name' violators that flaunt the GPL.

If there are specific violations then please do inform GPH, inform the maintainers of the GPL code (after all they are the only people who can take direct action) and by all means inform the community but don’t speculate on ‘possible violations’ as it just serves to fuel the misinformation (well IMHO anyway ).
Again, facts always speak louder then speculation .

You also have to remember that the numerous people with 'standing' that banded together to inform GPH of there dissatisfaction with the situation and that also proposed taking further action have been satisfied with the code releases.

On the subject of the video decoding object it is maybe best to think of it on the same lines that mobile operators use to keep there radio code separate from say a Linux powered phone (often choosing to run that radio code on another CPU core). Over simple overview I know but it’s broadly appropriate.

This decoder interface is public and shown in the code (it does not necessarily have to be documented mind you or even clear what flies over that interface) but the resulting engine is as closed as can be.

The MagicEyes decoder implementation broadly complies with this ideal but is not as graceful or as well segregated as it might be but I don’t think any of the mplayer maintainers seem anxious to challenge anything. The same binary object is used in MagicEyes MMSP2 WinCE implementation also.

Ah, I see - thanks for the reply. When I saw the page, the information seemed quite out of date, and I was surprised. I didn't realise that there's been a sort of on-going battle there.

I apologise if my post seemed negative, it really wasn't intended that way. Quite the opposite - I often type in 'gp2x wiki' in my address bar to get to the gp2x wiki, but I did it the other way around by accident 'wiki gp2x' which took me to the gp2x page on wikipedia instead. I read through, and when I got to that part, I was rather surprised by the information in that it seemed out of date and incorrect, especially in light of all the efforts to clear up the controversy and the work (which is very much appreciated) that went into getting it all sorted out.

I thought maybe people didn't often read that bit and it had been left unupdated, so when I saw this thread, thought I would give a link (as it hadn't yet been mentioned) in case someone with better understanding could better correct it.

I'm not sure if your post was directly aimed at me, but I'm sorry if it seemed I was suggesting they were not in compliance and agreeing with the wikipedia article - that wasn't the case at all

My main concern was the fact that people often link to that page when talking about the GP2X (e.g. on slashdot), and people might read that part and be put off or given the wrong impression, which isn't overly fair, especially considering the work that went into getting it sorted out.

if it makes you feel any better, wikipedia is usually only accurate on matters related to buffy the vampire slayer or the like. the rest is a crapshoot as far as i'm concerned

Sorry mate, none of it was directed at you. It was far more of a 'scatter gun' rant .

John

and thats kinda reinforced by the fact that schools/colleges/etc ban the use of wikipedia, and some even go as far as a blanket ban on the site's url so you can't even reach it from inside the uni I guess they got annoyed that people were quoting that as there source, as the information held there was completely and utterly wrong.

yeah, unfortunately there's a big difference between a well-written article and a poorly-written one that has a sticker on the top saying "this article may not conform to wikipedia's standards"...

luckily none of articles on "lost" or pokemon suffer from this.

not to be hypocritical...i do use it for a quick fix very often, but stuff like this just shows you how much you need to take into consideration the accuracy of what you read on it...plus that bomis guy is sketchy as hell.

Please excuse my semi-hijacking. I did a Google search for "Wikipedia" and "accuracy", and the top results include the following:

-----------------------------

Wikipedia survives research test

The free online resource Wikipedia is about as accurate on science as the Encyclopedia Britannica, a study shows.

http://news.bbc.co.uk/1/hi/technology/4530930.stm

-----------------------------

Assessing Wikipedia's Accuracy

In the wake of questions of accuracy, a survey by the science journal Nature finds that science entries in the volunteer-driven, online encyclopedia Wikipedia are "not markedly less accurate" than those found in Encyclopaedia Britannica.

http://www.npr.org/templates/story/story.php?storyId=5055388

-----------------------------

Experts rate Wikipedia's accuracy higher than non-experts

Thomas Chesney, a Lecturer in Information Systems at the Nottingham University Business School, published the results of his own Wikipedia study in the most recent edition of the online journal First Monday, and he came up with a surprising conclusion: experts rate the articles more highly than do non-experts.

http://arstechnica.com/news.ars/post/20061127-8296.html

-----------------------------

Like rockcasbah implies (and as suggested in one of these articles): you should "trust but verify" if you're using Wikipedia for research work... but Wikipedia certainly isn't a quasi-graffiti board where people just routinely post opinionated, inaccurate crap. It's definitely not perfect, but it's not worthless, either. I think of it as a kind of "open source journalism".

We now return to your regularly scheduled episode of "Current Status of GNU/GPL Infringement?".

amen!

Its fairly good for some physics and math related topics though.

yeah the physics stuff is usually ok (sometimes i find it too dense and unreadable though, but even my dead-tree EB suffers from this with science).

however, anything closer to liberal arts gets crucified. in these cases, there's a lot more to being a good reference than just not getting the facts wrong. basically, i think NPOV is useless...a lot of what i read on wp falls into the "false objectivity" trap in that it sounds objective but really isn't, and basically represents what a limited group of people (mainly the blog community) feels, maybe with a disclaimer preceding the sentence.

for instance, truth "A" is held by one person, opposite truth "B" by another. assuming there's no revert war, the eventual compromise is something like "some people think A" or "select sources show that B, but this is debatable."

sometimes that's warranted, sometimes it isn't. this is where, in the print world, a good author or editor will just pick a side, state their case, and (ideally) reveal their biases.

also sometimes i think it's gay that there's 1 paragraph of text about something, and 5 paragraphs about which simpsons episodes referenced it. i love homer too, but save that shit for snpp.

what we need is a wiki that makes uses of the infinite monkey protocol suite.
http://www.faqs.org/rfcs/rfc2795.html

anyway, sorry, carry on. (edit: typos)