headers
Luca Olivetti | 13 Mar 2010 16:23

Re: LG violates gpl? take 2

En/na Luca Olivetti ha escrit:

>> We distributed the object files using our system. You can download the 
>> object files as the old ways. 
> 
> I got it, but there's no Makefile, so I cannot verify if, once linked 
> with the supplied uclibc, will produce the same program as currently 
> running on the tv, and, as with the kernel, it's very important that I 
> can verify the supplied sources against what's currently running on the 
> tv, you know, I don't want to turn my tv set into an expensive 
> paperweight ;-)

Well, a simple string comparison suggests that the executable running in 
the tv cannot be obtained from the objects you sent me.
First I obtained the strings in the running program

strings RELEASE | sort | uniq > ../strings.release

Then I did the same with all the objects you sent me

strings * | sort | uniq > ../strings.objects

Then I compared them with diff. Of course many differences are due to 
things stripped during the linking process, but there are various 
strings in the executables that are nowhere to be found in the objects, 
kernel sources, uClibc or nanox.

For example this block of text is only in RELEASE:

+[A2SNK]
(Continue reading)

Permalink | Reply |
headers
Kyoungae Kim | 16 Mar 2010 03:51

Re: LG violates gpl? take 2

Hello.  

I'm sorry that we've missed some object files which are complied separately. 
Also we don't distribute the object files that the toolchain libraries include. 
I redistributed object files again and you can download it. 

About two RELEASE files, that case can happen. 
The difference of creating time doesn't mean that the files are different. 
I don't think that I have responsibility to tell how we manage the firmware release. 

Thanks. 

Regards. 
K. Kim. 

On Mar 14, 2010, at 12:23 AM, Luca Olivetti wrote:

> En/na Luca Olivetti ha escrit:
> 
>>> We distributed the object files using our system. You can download the object files as the old ways. 
>> I got it, but there's no Makefile, so I cannot verify if, once linked with the supplied uclibc, will
produce the same program as currently running on the tv, and, as with the kernel, it's very important that I
can verify the supplied sources against what's currently running on the tv, you know, I don't want to turn
my tv set into an expensive paperweight ;-)
> 
> Well, a simple string comparison suggests that the executable running in the tv cannot be obtained from
the objects you sent me.
> First I obtained the strings in the running program
> 
> strings RELEASE | sort | uniq > ../strings.release
(Continue reading)

Permalink | Reply |
headers
Luca Olivetti | 16 Mar 2010 09:38

Re: LG violates gpl? take 2

En/na Kyoungae Kim ha escrit:

> About two RELEASE files, that case can happen. 
> The difference of creating time doesn't mean that the files are different. 
> I don't think that I have responsibility to tell how we manage the firmware release. 

Of course not, I was just asking about the missing strings in the object 
files, I mentioned the two different RELEASE files just to show that I 
tried to be thorough, sorry if the question seemed to be about the 
different RELEASE.

Bye
--

-- 
Luca
Permalink | Reply |
headers
Luca Olivetti | 16 Mar 2010 12:06

Re: LG violates gpl? take 2

En/na Kyoungae Kim ha escrit:

> Hello.  
> 
> I'm sorry that we've missed some object files which are complied separately. 
> Also we don't distribute the object files that the toolchain libraries include. 
> I redistributed object files again and you can download it. 

Could you provide the ld command line to link those, so that I can 
verify that it produces the same RELEASE I have?

Thank you.

Bye
--

-- 
Luca
Permalink | Reply |
headers
Luca Olivetti | 21 Mar 2010 17:39

Re: LG violates gpl? take 2

En/na Luca Olivetti ha escrit:
> En/na Kyoungae Kim ha escrit:
> 
>> Hello. 
>> I'm sorry that we've missed some object files which are complied 
>> separately. Also we don't distribute the object files that the 
>> toolchain libraries include. I redistributed object files again and 
>> you can download it. 
> 
> Could you provide the ld command line to link those, so that I can 
> verify that it produces the same RELEASE I have?

I still didn't receive the ld command line, so I cannot verify that you 
gave me the objects corresponding to my RELEASE.
In the mean time I rebuilt the kernel with the latest sources provided 
and, again, it doesn't match the kernel running in the tv.

Though I suppose the configuration corresponding to my tv is 
config-flash-pdp, I built it with each available configuration, e.g.

./mkclean.sh
cp config-flash-pdp obj-flash/.config
make O=obj-flash uImage_flash
cd obj-flash
mv vmlinuz vmlinuz.config-flash-pdp
cd ..

./mkclean.sh
cp config-flash obj-flash/.config
make O=obj-flash uImage_flash
(Continue reading)

Permalink | Reply |
headers
Kyoungae Kim | 23 Mar 2010 11:30

Re: LG violates gpl? take 2

Hello. 

I'm telling you that heard from development part. 

The size difference of kernel image can be happened due to source location of Mstar’s drivers.
After you change the directory location like that procedure, you can get the same image. 
You can build the source code that I delivered last time. 
 
i)                   cd (kernel_root_dir)    ex) linux-2.6.26-saturn6 
ii)                 cd drivers                   
iii)                 rm –rf mstar                (Delete invalid chip driver source directory)
iv)                 ln -s ../../../drv_saturn6/kdriver_2.6.26/ mstar    (Make symbolic link for valid chip driver source)
v)                 cd ../
vi)                ./mk.sh

We hope that you can get corresponding kernel image 
Thanks. 

Regards.
K. Kim. 

On Mar 22, 2010, at 1:39 AM, Luca Olivetti wrote:

En/na Luca Olivetti ha escrit:
En/na Kyoungae Kim ha escrit:
Hello. I'm sorry that we've missed some object files which are complied separately. Also we don't distribute the object files that the toolchain libraries include. I redistributed object files again and you can download it.
Could you provide the ld command line to link those, so that I can verify that it produces the same RELEASE I have?

I still didn't receive the ld command line, so I cannot verify that you gave me the objects corresponding to my RELEASE.
In the mean time I rebuilt the kernel with the latest sources provided and, again, it doesn't match the kernel running in the tv.

Though I suppose the configuration corresponding to my tv is config-flash-pdp, I built it with each available configuration, e.g.

./mkclean.sh
cp config-flash-pdp obj-flash/.config
make O=obj-flash uImage_flash
cd obj-flash
mv vmlinuz vmlinuz.config-flash-pdp
cd ..

./mkclean.sh
cp config-flash obj-flash/.config
make O=obj-flash uImage_flash
cd obj-flash
mv vmlinuz vmlinuz.config-flash
cd ..

./mkclean.sh
cp config-flash-s5 obj-flash/.config
make O=obj-flash uImage_flash
cd obj-flash
mv vmlinuz vmlinuz.config-flash-s5
cd ..

./mkclean.sh
cp config-flash-s6-atsc obj-flash/.config
make O=obj-flash uImage_flash
cd obj-flash
mv vmlinuz vmlinuz.config-flash-s6-atsc
cd ..


then I downloaded the running kernel from the tv

cat /dev/mtdblock7 > image_from_tv

then I removed the uboot header

dd bs=1 skip=64 if=image_from_tv of=image_from_tv.lzo

then I unpacked the image

../../../tools/lzopack -d image_from_tv.lzo image_from_tv.vmlinuz

I checked this image and it's the same in the epk file.

This is the result:

ls -l vmlinuz* image_from_tv.vmlinuz
-rw-r--r-- 1 luca luca 4394120 2010-03-21 17:32 image_from_tv.vmlinuz
-rwxr-xr-x 1 luca luca 4390024 2010-03-21 17:12 vmlinuz.config-flash*
-rwxr-xr-x 1 luca luca 4390024 2010-03-21 17:17 vmlinuz.config-flash-pdp*
-rwxr-xr-x 1 luca luca 4381688 2010-03-21 17:22 vmlinuz.config-flash-s5*
-rwxr-xr-x 1 luca luca 4390024 2010-03-21 17:26 vmlinuz.config-flash-s6-atsc*

As you can see none of the resulting images matches the kernel running on the tv.

Would you please send me the real sources and configuration corresponding to my tv?
Failing that, could you send me an epk file with the firmware corresponding to the sources I have?

Thank you.
Bye
--
Luca


Permalink | Reply |
headers
Thomas Charron | 23 Mar 2010 16:33
Picon

Re: LG violates gpl? take 2

On Tue, Mar 23, 2010 at 6:30 AM, Kyoungae Kim <kyoungae.kim <at> lge.com> wrote:
Hello. 

I'm telling you that heard from development part. 

The size difference of kernel image can be happened due to source location of Mstar’s drivers.
After you change the directory location like that procedure, you can get the same image. 
You can build the source code that I delivered last time. 
 
  While I'm not directly involved with this conversation, I'd like to point out that the image files are different enough that I do not believe a path could cause that much of a difference.
 
  Luca, have they provided you with the same compiler which they used?

--
-- Thomas
Permalink | Reply |
headers
Luca Olivetti | 23 Mar 2010 17:21

Re: LG violates gpl? take 2

En/na Thomas Charron ha escrit:
> On Tue, Mar 23, 2010 at 6:30 AM, Kyoungae Kim <kyoungae.kim <at> lge.com 
> <mailto:kyoungae.kim <at> lge.com>> wrote:
> 
>     Hello. 
> 
>     I'm telling you that heard from development part. 
> 
>     The size difference of kernel image can be happened due to source
>     location of Mstar’s drivers.
>     After you change the directory location like that procedure, you can
>     get the same image. 
>     You can build the source code that I delivered last time. 
> 
>  
>   While I'm not directly involved with this conversation, I'd like to 
> point out that the image files are different enough that I do not 
> believe a path could cause that much of a difference.

I don't believe it either. Anyway, I'll try the procedure suggested and 
report back.

>  
>   Luca, have they provided you with the same compiler which they used?

I think so, but, again, I cannot be 100% sure.

Bye
--

-- 
Luca
Permalink | Reply |
headers
Luca Olivetti | 23 Mar 2010 18:01

Re: LG violates gpl? take 2

En/na Luca Olivetti ha escrit:

>>  
>>   While I'm not directly involved with this conversation, I'd like to 
>> point out that the image files are different enough that I do not 
>> believe a path could cause that much of a difference.
> 
> I don't believe it either. Anyway, I'll try the procedure suggested and 
> report back.

It turns out that it wasn't just a path, but a different set of drivers.
As you see in the other message, now the size of the image matches but 
the content doesn't.

Bye
--

-- 
Luca
Permalink | Reply |
headers
Luca Olivetti | 23 Mar 2010 18:00

Re: LG violates gpl? take 2

En/na Kyoungae Kim ha escrit:
> Hello. 
> 
> I'm telling you that heard from development part. 
> 
> The size difference of kernel image can be happened due to source 
> location of Mstar’s drivers.
> After you change the directory location like that procedure, you can get 
> the same image. 
> You can build the source code that I delivered last time. 
>  
> i)                   cd (kernel_root_dir)    ex) linux-2.6.26-saturn6 
> ii)                 cd drivers                   
> iii)                 rm –rf mstar                (Delete invalid chip 
> driver source directory)
> iv)                 ln -s ../../../drv_saturn6/kdriver_2.6.26/ mstar   
>  (Make symbolic link for valid chip driver source)
> v)                 cd ../
> vi)                ./mk.sh
> 
> We hope that you can get corresponding kernel image 

No. This time the size matches, but the content doesn't.

$ ls -l image_from_tv.vmlinuz vmlinuz.config-flash
-rw-r--r-- 1 luca luca 4394120 2010-03-21 17:32 image_from_tv.vmlinuz
-rwxr-xr-x 1 luca luca 4394120 2010-03-23 17:42 vmlinuz.config-flash*

$ cmp -b -l image_from_tv.vmlinuz vmlinuz.config-flash | wc --lines
2224535

I also tried with config-flash-pdp with the same result.

Bye
-- 
Luca

> Thanks. 
> 
> Regards.
> K. Kim. 
> 
> On Mar 22, 2010, at 1:39 AM, Luca Olivetti wrote:
> 
>> En/na Luca Olivetti ha escrit:
>>> En/na Kyoungae Kim ha escrit:
>>>> Hello. I'm sorry that we've missed some object files which are 
>>>> complied separately. Also we don't distribute the object files that 
>>>> the toolchain libraries include. I redistributed object files again 
>>>> and you can download it.
>>> Could you provide the ld command line to link those, so that I can 
>>> verify that it produces the same RELEASE I have?
>>
>> I still didn't receive the ld command line, so I cannot verify that 
>> you gave me the objects corresponding to my RELEASE.
>> In the mean time I rebuilt the kernel with the latest sources provided 
>> and, again, it doesn't match the kernel running in the tv.
>>
>> Though I suppose the configuration corresponding to my tv is 
>> config-flash-pdp, I built it with each available configuration, e.g.
>>
>> ./mkclean.sh
>> cp config-flash-pdp obj-flash/.config
>> make O=obj-flash uImage_flash
>> cd obj-flash
>> mv vmlinuz vmlinuz.config-flash-pdp
>> cd ..
>>
>> ./mkclean.sh
>> cp config-flash obj-flash/.config
>> make O=obj-flash uImage_flash
>> cd obj-flash
>> mv vmlinuz vmlinuz.config-flash
>> cd ..
>>
>> ./mkclean.sh
>> cp config-flash-s5 obj-flash/.config
>> make O=obj-flash uImage_flash
>> cd obj-flash
>> mv vmlinuz vmlinuz.config-flash-s5
>> cd ..
>>
>> ./mkclean.sh
>> cp config-flash-s6-atsc obj-flash/.config
>> make O=obj-flash uImage_flash
>> cd obj-flash
>> mv vmlinuz vmlinuz.config-flash-s6-atsc
>> cd ..
>>
>>
>> then I downloaded the running kernel from the tv
>>
>> cat /dev/mtdblock7 > image_from_tv
>>
>> then I removed the uboot header
>>
>> dd bs=1 skip=64 if=image_from_tv of=image_from_tv.lzo
>>
>> then I unpacked the image
>>
>> ../../../tools/lzopack -d image_from_tv.lzo image_from_tv.vmlinuz
>>
>> I checked this image and it's the same in the epk file.
>>
>> This is the result:
>>
>> ls -l vmlinuz* image_from_tv.vmlinuz
>> -rw-r--r-- 1 luca luca 4394120 2010-03-21 17:32 image_from_tv.vmlinuz
>> -rwxr-xr-x 1 luca luca 4390024 2010-03-21 17:12 vmlinuz.config-flash*
>> -rwxr-xr-x 1 luca luca 4390024 2010-03-21 17:17 vmlinuz.config-flash-pdp*
>> -rwxr-xr-x 1 luca luca 4381688 2010-03-21 17:22 vmlinuz.config-flash-s5*
>> -rwxr-xr-x 1 luca luca 4390024 2010-03-21 17:26 
>> vmlinuz.config-flash-s6-atsc*
>>
>> As you can see none of the resulting images matches the kernel running 
>> on the tv.
>>
>> Would you please send me the real sources and configuration 
>> corresponding to my tv?
>> Failing that, could you send me an epk file with the firmware 
>> corresponding to the sources I have?
>>
>> Thank you.
>> Bye
>> -- 
>> Luca
>>
>
Permalink | Reply |
headers
Ralph Corderoy | 24 Mar 2010 14:55
Picon

Re: LG violates gpl? take 2


Hi,

> No. This time the size matches, but the content doesn't.
> 
> $ ls -l image_from_tv.vmlinuz vmlinuz.config-flash
> -rw-r--r-- 1 luca luca 4394120 2010-03-21 17:32 image_from_tv.vmlinuz
> -rwxr-xr-x 1 luca luca 4394120 2010-03-23 17:42 vmlinuz.config-flash*
> 
> $ cmp -b -l image_from_tv.vmlinuz vmlinuz.config-flash | wc --lines
> 2224535

If the two binaries are out of sync, then the number of lines from `cmp
-l' can be misleading.  Have you tried

    hex() { hexdump -ve '/1 "%x\n"' "$ <at> "; }
    diff <(hex image_from_tv.vmlinuz) <(hex vmlinuz.config-flash) | less

and see on what scale those differences are?  Also, the location of a
difference may mean you can investigate more and see it's due to object
foo.o.

Cheers,
Ralph.
Permalink | Reply |
headers
Luca Olivetti | 24 Mar 2010 16:34

Re: LG violates gpl? take 2

En/na Ralph Corderoy ha escrit:
> Hi,
> 
>> No. This time the size matches, but the content doesn't.
>>
>> $ ls -l image_from_tv.vmlinuz vmlinuz.config-flash
>> -rw-r--r-- 1 luca luca 4394120 2010-03-21 17:32 image_from_tv.vmlinuz
>> -rwxr-xr-x 1 luca luca 4394120 2010-03-23 17:42 vmlinuz.config-flash*
>>
>> $ cmp -b -l image_from_tv.vmlinuz vmlinuz.config-flash | wc --lines
>> 2224535
> 
> If the two binaries are out of sync, then the number of lines from `cmp
> -l' can be misleading.  Have you tried
> 
>     hex() { hexdump -ve '/1 "%x\n"' "$ <at> "; }
>     diff <(hex image_from_tv.vmlinuz) <(hex vmlinuz.config-flash) | less

Yes (actually I couldn't get the correct incantation for hexdump so I 
wrote a python script to to the same).

> 
> and see on what scale those differences are?  Also, the location of a
> difference may mean you can investigate more and see it's due to object
> foo.o.

Well, the differences are scattered all around the place, it doesn't 
seem just a couple of out-of-sync bytes.

Bye
--

-- 
Luca
Permalink | Reply |
headers
Luca Olivetti | 24 Mar 2010 19:36

Re: LG violates gpl? take 2

En/na Ralph Corderoy ha escrit:
> Hi,
> 
>> No. This time the size matches, but the content doesn't.
>>
>> $ ls -l image_from_tv.vmlinuz vmlinuz.config-flash
>> -rw-r--r-- 1 luca luca 4394120 2010-03-21 17:32 image_from_tv.vmlinuz
>> -rwxr-xr-x 1 luca luca 4394120 2010-03-23 17:42 vmlinuz.config-flash*
>>
>> $ cmp -b -l image_from_tv.vmlinuz vmlinuz.config-flash | wc --lines
>> 2224535
> 
> If the two binaries are out of sync, then the number of lines from `cmp
> -l' can be misleading.  Have you tried
> 
>     hex() { hexdump -ve '/1 "%x\n"' "$ <at> "; }
>     diff <(hex image_from_tv.vmlinuz) <(hex vmlinuz.config-flash) | less
> 
> and see on what scale those differences are?  Also, the location of a
> difference may mean you can investigate more and see it's due to object
> foo.o.

I piped that to a simple python script that counts the differences (how 
many times the difference has substituted "from" bytes with "to" bytes), 
and, while the result is not as dramatic, it still points to a 
significant difference:

from 1 to 1: 24924
from 2 to 2: 14199
from 1 to 0: 184
from 3 to 3: 171
from 0 to 1: 111
from 1 to 2: 42
from 1 to 6: 36
from 0 to 5: 35
from 5 to 2: 35
from 0 to 11: 33
from 3 to 6: 33
from 1 to 5: 19
from 5 to 1: 18
from 0 to 3: 14
from 0 to 2: 14
from 3 to 0: 12
from 0 to 4: 12
from 4 to 0: 11
from 2 to 0: 10
from 6 to 2: 8
from 2 to 6: 6
from 10 to 2: 6
from 9 to 1: 5
from 2 to 1: 5
from 8 to 0: 4
from 2 to 10: 3
from 1 to 9: 3
from 0 to 8: 3
from 0 to 16: 3
from 7 to 0: 3
from 1 to 3: 2
from 9 to 4: 2
from 14 to 2: 2
from 0 to 20: 2
from 3 to 2: 2
from 7 to 1: 2
from 0 to 12: 2
from 192 to 0: 1
from 2 to 18: 1
from 2 to 8: 1
from 206 to 39: 1
from 1 to 29: 1
from 0 to 28: 1
from 17 to 1: 1
from 0 to 56: 1
from 1 to 45: 1
from 4 to 46: 1
from 37 to 1: 1
from 0 to 99: 1
from 1 to 17: 1
from 1 to 85: 1
from 1 to 13: 1
from 4 to 14: 1
from 16 to 0: 1
from 4 to 2: 1
from 5 to 3: 1
from 13 to 1: 1
from 32 to 0: 1
from 0 to 52: 1
from 680 to 0: 1
from 28 to 0: 1
from 2 to 3: 1

Bye
--

-- 
Luca
Permalink | Reply |
headers
Ralph Corderoy | 24 Mar 2010 23:28
Picon

Re: LG violates gpl? take 2


Hi Luca,

> > If the two binaries are out of sync, then the number of lines from
> > `cmp -l' can be misleading.  Have you tried
> > 
> >     hex() { hexdump -ve '/1 "%x\n"' "$ <at> "; }
> >     diff <(hex image_from_tv.vmlinuz) <(hex vmlinuz.config-flash) | less
> > 
> > and see on what scale those differences are?  Also, the location of
> > a difference may mean you can investigate more and see it's due to
> > object foo.o.
> 
> I piped that to a simple python script that counts the differences
> (how many times the difference has substituted "from" bytes with "to"
> bytes), and, while the result is not as dramatic, it still points to a
> significant difference:

I don't think it's very meaningful?  Due to size changes, addresses and
offsets may change on a wide scale?

> from 1 to 1: 24924
> from 2 to 2: 14199
> from 3 to 3: 171
> from 680 to 0: 1

These four are odd?

Cheers,
Ralph.
Permalink | Reply |
headers
Luca Olivetti | 25 Mar 2010 00:06

Re: LG violates gpl? take 2

En/na Ralph Corderoy ha escrit:

>> I piped that to a simple python script that counts the differences
>> (how many times the difference has substituted "from" bytes with "to"
>> bytes), and, while the result is not as dramatic, it still points to a
>> significant difference:
> 
> I don't think it's very meaningful?  Due to size changes, addresses and
> offsets may change on a wide scale?

I may be wrong but I still maintain that the only difference should be 
in the timestamps. Anything else means that the source (or the 
configuration or the build system) is not the same.

> 
>> from 1 to 1: 24924
>> from 2 to 2: 14199
>> from 3 to 3: 171
>> from 680 to 0: 1
> 
> These four are odd?

Why?
The first two says that the bulk of the differences are 1 or 2 bytes 
changed, there are only 172 groups where 3 bytes are changed and 1 group 
where 680 bytes were eliminated. Throughout the list there are places 
were bytes were added.
My guess (but it's just a guess) is that the firmware of the various 
devices (which is embedded in the sources, generated by some external 
tools at lg) is different.

Bye
--

-- 
Luca
Permalink | Reply |
headers
Ralph Corderoy | 25 Mar 2010 14:45
Picon

Re: LG violates gpl? take 2


Hi Luca,

> En/na Ralph Corderoy ha escrit:
> > > I piped that to a simple python script that counts the differences
> > > (how many times the difference has substituted "from" bytes with
> > > "to" bytes)...
> > >
> > > from 1 to 1: 24924
> > > from 2 to 2: 14199
> > > from 3 to 3: 171
> > > from 680 to 0: 1
> > 
> > These four are odd?
> 
> Why?  The first two says that the bulk of the differences are 1 or 2
> bytes changed, there are only 172 groups where 3 bytes are changed and
> 1 group where 680 bytes were eliminated.

Sorry, I misunderstood.  I thought you were saying 24,924 bytes with the
value of 1 changed to have the value of 1.

Cheers,
Ralph.
Permalink | Reply |

Gmane