SamyGO: replacing television firmware

By Jake Edge
November 14, 2009

While it is quite common for consumer electronics—TVs, DVRs, and the like—to be running Linux these days, it is less common to see projects geared towards replacing and upgrading the Linux firmware in that class of devices. But that is exactly what the SamyGO project is doing for Samsung televisions. By using the source provided by Samsung, along with quite a bit of ingenuity, SamyGO allows users to telnet into their television—an amusing concept—but also to enable functionality beyond that which ships with the device.

The SamyGO wiki lists several modifications that can be made to the TV firmware. One of the main modifications seems to be enabling NFS or SMB/CIFS support so that media files from servers on the network can be played. The TVs already support getting media from the local network using Digital Living Network Alliance (DLNA) protocols, but there are restrictions on the audio and video formats and some playback functionality (pause, forward, rewind) depending on the DLNA server. By using NFS or CIFS, all of the formats and features available for USB-based playback are also available across the network.

Obviously, these are fairly high-end TVs, with both Ethernet connectivity and USB ports. The devices "supported" by SamyGO are LCD models in the LE-32-55Bxxx series and LED models from the UE-xx-B70xx series. The USB ports are available for viewing/playing additional media or for games. Using the "Games" menu with programs stored on a USB stick is one of the ways to run programs on the TV.

The USB ports are also used for a Samsung-branded WiFi "dongle" that owners can buy to avoid the wiring hassle of Ethernet. But, Linux supports far more wireless devices than just the Samsung devices, so SamyGO developers are working to enable others as well. In fact, the Ralink rt73 and rt2870 drivers have been modified in the kernel source supplied by Samsung to remove many additional device IDs, so that only the Samsung devices will work. There are now drivers available without that restriction.

The early efforts have been to get telnet working so that the TV filesystem could be explored. This is done by patching the firmware binaries provided by Samsung and then using the TV's firmware upgrade mechanism to install them on the device. The aptly named "Warning : Read Me First or Brick Your TV!" message in the SamyGO forum outlines the dangers of upgrading the firmware. For those that just want to try this all out, without upgrading any firmware, a safer method is also described, which masquerades as a game on a USB stick to enable telnet.

The kernel is 2.6.18-based with the addition of Samsung's Robust FAT File System (RFS), which is a filesystem for NAND flash devices. As the name would indicate, it is also FAT compatible. It is not in the mainline, however, nor have the SamyGO developers gotten it working for desktop distributions. For that reason, they have resorted to binary patching of the firmware.

Samsung has also released RFS source, along with a Linux porting guide that should be helpful in those efforts. Once RFS can be built for recent kernels, or a utility to create RFS images is made, developers will be able to build their own firmware images for these TVs. [ Update: see the comments below, there is no source RFS release. ]

The kernel source is available, but the project has not yet released any kernels built from it. The Ralink drivers were rebuilt after modifying the device IDs, though, so they can be inserted into the system. The kernel itself has been patched, adding OMAP architecture and sound support among other things, but there has been no mention of binary drivers on the forum, so it should be possible to build the released kernel—or something more recent.

So far, Samsung doesn't seem to have reacted to the project, either positively or negatively. Some concern has been expressed in the forum that working around the WiFi restrictions might raise the company's ire. But one would guess that the number of folks willing to risk bricking an expensive TV in order to use a cheaper WiFi dongle is relatively small—likely to go unnoticed by Samsung.

In the meantime, if the SamyGO hackers add other functionality that might be interesting to customers—there has been talk of web browsers for example—Samsung might just adopt it themselves. Either way, the code is out there for those who might want to give it a try.

Index entries for this article
Kernel	Embedded systems

SamyGO: replacing television firmware

Posted Nov 14, 2009 16:21 UTC (Sat) by kju (guest, #61936) [Link] (25 responses)

The article claims that samsung has released the RFS sources. Where? On the mentioned page there is no download and the downloadable kernel source for this device contains binary object files for RFS only. Samsung also states that RFS is not GPL but proprietary. So porting RFS to a newer kernel will apparently be a big problem.

SamyGO: replacing television firmware

Posted Nov 14, 2009 16:42 UTC (Sat) by jake (editor, #205) [Link] (24 responses)

> On the mentioned page there is no download and the downloadable kernel
> source for this device contains binary object files for RFS only.

You are indeed correct, and I will try to reflect that in the article. I saw rfs directories and such included with the source, along with some forum comments, and leapt to a conclusion. Interesting that they would provide object files for a binary-only module, doesn't seem like they would need to do that (assuming that the binary module is not a derivative work, which would, of course, require the source to be released as well).

My apologies, and thanks for pointing it out!

jake

SamyGO: replacing television firmware

Posted Nov 14, 2009 17:15 UTC (Sat) by johill (subscriber, #25196) [Link] (16 responses)

You'd think anything using the VFS is a derived work of it since it cannot have been created for another operating system and "just ported".

SamyGO: replacing television firmware

Posted Nov 14, 2009 21:27 UTC (Sat) by ewan (guest, #5533) [Link]

That's not necessarily true, one of the classic early examples of a kernel module that couldn't possibly be a derived work of the kernel was the Andrew File System that did use pre-existing code ported across.

SamyGO: replacing television firmware

Posted Nov 14, 2009 22:35 UTC (Sat) by giggls (subscriber, #48434) [Link]

Looks like they are providing a thin Layer with GPL-Licence just like the Nvidia folks do:

http://www.samsung.com/global/business/semiconductor/prod...

SamyGO: replacing television firmware

Posted Nov 16, 2009 7:25 UTC (Mon) by butlerm (subscriber, #13312) [Link] (13 responses)

"a derived work of it since it cannot have been created for another
operating system"

This is one of the most ridiculous definitions of "derivative work" ever
conceived. It makes absolutely no sense whatsoever.

Two classic tests for derivative work are "access" and "substantial
similarity". Access is a given here. But why should a filesystem first
developed for Linux necessarily have greater similarity to other operating
system source code than one that was ported from another operating system?

A difference so great that one is a derivative work and the other one
isn't? The end products are nearly equivalent. Both rely on access to the
Linux source code. The order of development or porting is completely
irrelevant - either both (in their final form) are derivative works of
Linux or both aren't.

And the theory that either one is a derivative work is pretty thin in any
case. Is a Windows application a derivative work of Windows because that
is the first platform it was developed for? Because it makes extensive use
of hundreds of Win32 APIs? What about a business management application
that relies on the special features of a certain database? Should it be
developed for some brain dead database first, just so it can avoid the
accusation of being a derived work of the good one?

Is the contagion of being ported to a kernel or operating system so great,
that the taint can never be removed in a version for a different kernel or
operating system. That is what SCO's theory was. Derivative status as a
viral construct.

SamyGO: replacing television firmware

Posted Nov 16, 2009 8:39 UTC (Mon) by dwmw2 (subscriber, #2063) [Link] (12 responses)

" This is one of the most ridiculous definitions of "derivative work" ever conceived. It makes absolutely no sense whatsoever."

It's also completely irrelevant; I'm disappointed that johill brought it up.

It actually doesn't matter at all whether the module is a derived work. Let's consider it, for the sake of argument, to be an independent and separate work in itself. And then let's see what the GPL has to say...

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

That's the nVidia situation which giggls mentioned (given the above-stated assumption, for the sake of argument, that it's not a derived work).
But read on...

But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

And that's the Samsung situation. Looks like a clear GPL violation to me.

Even if the module is not a derived work.

SamyGO: replacing television firmware

Posted Nov 16, 2009 21:04 UTC (Mon) by jmm82 (guest, #59425) [Link] (2 responses)

"It's also completely irrelevant; I'm disappointed that johill brought it up."

As long as you are not *surprised* someone brought it up. It is a rare occasion that a product using Linux is discussed on LWN without a sub-thread about the GPL and derived work.

Have there been any concrete court decisions in this field lately? I am tired of hearing peoples unprovable interpretations of a derived work. I would love to know what a derived work really is, but have searched far and wide with no solid answers.

SamyGO: replacing television firmware

Posted Nov 16, 2009 21:47 UTC (Mon) by dwmw2 (subscriber, #2063) [Link] (1 responses)

You have missed the point completely.

SamyGO: replacing television firmware

Posted Nov 16, 2009 22:05 UTC (Mon) by jmm82 (guest, #59425) [Link]

Agreed, as soon as I hear the words "derived work" my mind blanks out. I have heard so many different opinions on derived work my head immediately begins to swell up upon hearing those words.

In this case it is irrelevant, your point was taken.

SamyGO: replacing television firmware

Posted Nov 16, 2009 22:05 UTC (Mon) by jake (editor, #205) [Link] (8 responses)

But, isn't "work based on the Program" just another way of saying "derived work"?

I don't think the GPL can affect code that is not derived. That's all that copyright law allows it to do.

Or am I missing something?

jake

SamyGO: replacing television firmware

Posted Nov 16, 2009 22:38 UTC (Mon) by dwmw2 (subscriber, #2063) [Link] (7 responses)

You're right; the GPL can't directly affect those other works, which are "independent and separate works in themselves." All it can do is grant or deny you permission to copy, modify and distribute the original GPL'd work.

It can grant you permission with conditions attached. Copyright law does allow that. And unless you abide by those conditions, you don't have permission to distribute the original GPL'd work.

So I can release code under a licence which says "you can only use this if you send me a postcard," or "if you name you first-born son after me," or "if all software you ever write is released under the GPL," or "if I like your face."

It's my prerogative to grant or deny permission to use my own code as I see fit, under copyright law.

And I most certainly can release it under a licence which says that you may only redistribute it if you don't do so in combination with other software which is under a different licence. Copyright law most definitely does allow that, and that's what the GPL does.

SamyGO: replacing television firmware

Posted Nov 16, 2009 22:48 UTC (Mon) by jake (editor, #205) [Link] (6 responses)

> And I most certainly can release it under a licence which says
> that you may only redistribute it if you don't do so in combination
> with other software which is under a different licence. Copyright
> law most definitely does allow that, and that's what the GPL does.

Interesting. If I am understanding you correctly, you are saying that anyone who distributes a Linux kernel with a binary driver (many, if not most, embedded Linux devices out there would qualify) is in violation of the GPL.

Not an interpretation I had heard (or, perhaps more likely, understood) before.

jake

SamyGO: replacing television firmware

Posted Nov 16, 2009 23:09 UTC (Mon) by dwmw2 (subscriber, #2063) [Link] (5 responses)

"Interesting. If I am understanding you correctly, you are saying that anyone who distributes a Linux kernel with a binary driver (many, if not most, embedded Linux devices out there would qualify) is in violation of the GPL."

Given the above direct quote from the §2 of the GPL, I find it hard to find an alternative interpretation. Although I understand that some people don't like it, so they'll clutch at straws to find one.

One of the tenuous counter-arguments which is often presented (other than the "copyright law doesn't allow that" fallacy) is the final paragraph of §2, which states that "mere aggregation ... on a volume of a storage or distribution medium" doesn't count.

Some people argue that that "exception" is so wide-ranging that it might as well be rephrased as "Oh, actually just disregard the previous two paragraphs, even where we explicitly spelled out that we meant this to apply even to works which are independent and separate works in themselves; we didn't really mean that."

Some people go so far as to claim that all forms of "aggregation" are permitted by the exception — so since linking to non-GPL'd work is merely a form of aggregation, that's allowed too. Under that interpretation, the GPL would actually become more like the LGPL.

Personally, I feel it's much more likely that that "exception" clause applies to stuff like magazine cover CDs, where mostly unrelated software is just aggregated together for distribution. Or where it happens to sit on the same hard drive or backup tape as if by coincidence.

I definitely don't believe that any sane interpretation of the "mere aggregation" exception can apply to a coherent product where both the GPL'd work and the non-GPL'd work are fundamental and necessary parts without which it could not operate.

But of course nobody is right or wrong until it's been heard in court.

OT - Rant against case law

Posted Nov 17, 2009 12:10 UTC (Tue) by Felix.Braun (guest, #3032) [Link] (4 responses)

But of course nobody is right or wrong until it's been heard in court.

Just for the record, the quoted statement would only be true if courts could never be wrong. That is, if they had an authoritative say on what the law should be.

As a (non common law) lawyer, I take exception at this view. Judges are just opinionated people who have been handed some robes (and in the UK maybe some wigs) by the politicians. They are just as likely to make mistakes as the next guy. They are not inherently more likely to be right than anybody else, even *gasp* non-lawyers. Of course, judges themselves know this, and they therefore appreciate a well reasoned argument, no matter who makes it. Generally speaking, even after having decided a case.

Of course, in practice the legal traditions work out to be remarkably similar. But I really do blame the case law system with it's principle of stare decisis for instilling such an attitude of unreflected acceptance in otherwise critically thinking legal laymen.

SCNR </completly off-topic rant>

OT - Rant against case law

Posted Nov 17, 2009 12:47 UTC (Tue) by dwmw2 (subscriber, #2063) [Link] (3 responses)

I understand your objection; allow me to rephrase that final sentence for you, to properly express the implicit subtext...

But nobody is right or wrong; it's not black and white. It's just a document written in English and there can be many different interpretations of it; ranging from the sane interpretations to the utterly nonsensical ones such as the "counter-arguments" I mentioned above.

There are very few interpretations which actually matter, though. The first one which matters to you might be the opinion of your company lawyer, when you consider shipping a product which violates the GPL by including both a kernel and a binary-only module in the same coherent whole. Or, as the GPL phrases it, in a "derivative or collective work based on" Linux.

If he is doing his job properly, he will prevent you from doing that. On the other hand if he doesn't do his job properly, you may well end up bumping up against an opinion which takes precedence over his — the opinion expressed by the (final appeal) court when you are sued for copyright violation.

That opinion, ultimately, is the only one which really matters. It doesn't make it right, and there's plenty of examples of cases where the courts have got things "wrong" in the eyes of many people. But it is the only interpretation which really matters in the end, in practical terms.

Unless, of course, you think the revolution is going to be triggered by a copyright case... :)

OT - Rant against case law

Posted Nov 17, 2009 14:51 UTC (Tue) by Felix.Braun (guest, #3032) [Link]

Thank you for that. That makes me feel much better :-)

OT - Rant against case law

Posted Nov 18, 2009 4:53 UTC (Wed) by butlerm (subscriber, #13312) [Link] (1 responses)

I think the implication against joint (collective) distribution is entirely
reasonable. My problem is when people say something like "this filesystem
was first developed for Linux", therefore it (in any form) is a derived
work of the Linux kernel, and that derivative status infects it to the
degree that it remains a derivative work even when all the Linux related
code is stripped out.

That was SCO's theory regarding JFS. It was first developed for a
proprietary Unix licensed from source code SCO claimed it had the copyright
to, therefore (so they claimed) any version for any other operating system
was also a derivative work of Unix System V (and they were owed billions in
royalties).

I call that the "derivative work by contagion" theory, and it is one of the
reasons why people shouldn't blindly go around claiming things are
derivative works when there is no rational theory for why that should be
the case. Combination may produce a copyright protected collective work,
but the mere fact of combination certainly does not necessarily infect each
of the original components with derivative status when considered
separately, and more especially when the kernel specific binding code is
removed. That would be like saying if a photo is printed in a magazine,
not only is the photo a derivative work of the magazine, the magazine is a
derivative work of the photo.

OT - Rant against case law

Posted Nov 18, 2009 10:27 UTC (Wed) by anselm (subscriber, #2796) [Link]

The fun thing about IBM's JFS as available in the Linux kernel was that the JFS code IBM contributed to Linux didn't in fact have anything to do with the JFS code in AIX (which SCO claimed was a derived work of Unix).

The Linux JFS code is a port of the reimplementation from scratch of JFS that IBM did for OS/2, so it couldn't have been »infected« with SCO-owned code because it never actually came in contact with any.

RFS = FAT + journal? Robust - sigh...

Posted Nov 15, 2009 15:12 UTC (Sun) by pflugstad (subscriber, #224) [Link] (6 responses)

Samsung's RFS page kills me - they add a journal to FAT, tweak it for flash and call it robust FAT filesystem. Ye gads, FAT itself is about the most trivial file system you can get, and making it robust... there's only so much you can do and still be FAT compatible. And then they go to all the effort to keep it binary only, with the GPL shim layer.

I see companies do this all the time: some engineer adds 1 + 1 and suddenly the company treats it likes it's a prize possession, and then they jump through hoops to keep the fact that they added 1+1 a huge secret. When in reality the engineer probably did it as a quick one-off, with little thought and almost zero experience in what he was doing (state of the art filesystem design - yeah, right). As such, it's probably got a couple dozen stupid bugs and could do for some serious peer review.

Just release the code Samsung - if it's any good, the community will incorporate it and it'll get even better. And if it sucks, the community will probably fix it. And the amount of value you're getting from using Linux vastly outweighs any benefit some competitor of yours might get by seeing this silly journalling FAT filesytem.

Oh, and get this: if you google for "journaling FAT", the first result is a PATENT on such a thing. The idiots at the PTO strike again. And there are dozens of other journaling or robust FAT filesystem results.

RFS = FAT + journal? Robust - sigh...

Posted Nov 16, 2009 16:56 UTC (Mon) by drag (guest, #31333) [Link] (5 responses)

This is actually pretty normal.

Microsoft themselves have 'Transaction Safe' FAT version they offer for
embedded systems running Windows CE 5.x (and probably others). Since people
expect that it's 'ok' to simply pull the power from handheld devices and
such then it's obvious that FAT itself is not really that suitable.
Customers will have a strong tendency to corrupt things after a while. So
transaction safe FAT is designed to deal with that.

It's simply a FAT file system with two file allocation tables. I guess the
goal is to make file system changes a fully atomic event.

And the Linux FAT driver actually works with it, mostly. You can read from
it quite easily, and write. I don't think it's a good idea to use the file
system back in the embedded system after that.. but it's easily to pull the
information off of one.

RFS = FAT + journal? Robust - sigh...

Posted Nov 16, 2009 19:38 UTC (Mon) by pflugstad (subscriber, #224) [Link] (2 responses)

I know it's normal. That's my main point: what on earth does Samsung think they are gaining by trying to keep their super-duper RFS secret?

It was also to point out that companies need to start understanding that 99% of the stuff their engineers come up with is totally obvious and has been done before (and is even patented in this case), so that they don't end up wasting vast quantities of everyone's time and money on silly crap like the GPL shim layer. Not that the stuff is useless, but come on, a *television* company doing "state of the art" filesystem work. GET REAL...

Pete

PS: I guess it was the Samsung website for RFS that set me off... gawd what a load of marketing drivel...

RFS = FAT + journal? Robust - sigh...

Posted Nov 28, 2009 20:15 UTC (Sat) by efexis (guest, #26355) [Link] (1 responses)

Wow that's a lot of assumptions there, like that things are *ever* that simple. Okay, sometimes things are that simple, but most of the time, when something's screaming "this is so simple why can't they see it?" at you, that's usually a strong sign that it's not and there are other factors you're not considering. As much as there are GPL constraints pulling in one direction, there's a fair chance that there are several other licenses on what they can do with the code pulling them in other directions. For a start, we know it's a VFAT compatible filesystem, and from what we've seen recently with TomTom, Microsoft's ownership of that IP will stand up in court, which means chances are Samsung (or "Flash Software Group") currently have a licensing agreement with MS to allow them to use the code, and who knows whom else they've licensed code or other IP that covers what else they can do with it. Judging by the fact that there's other open source driver downloads on their website for other parts of the system or other products, I'm definitely inclined to believe that it's simply a case of contending licensing issues...

But really, it's a FAT based filesystem that open implementations can still read/write to should the need be there, who cares? Let 'em have their locked away filesystem add-ons, there's so much better out there and on the way.

As far as patenting goes, that covers implementation, if they do their transactional IO differently then it doesn't come under that patent, and if they don't do it different, then the patent holder is probably just someone else who Samsung have a licensing agreement with adding constraints. It's just business.

RFS = FAT + journal? Robust - sigh...

Posted Dec 2, 2009 7:34 UTC (Wed) by tdwebste (guest, #18154) [Link]

>For a start, we know it's a VFAT compatible filesystem,
>and from what we've seen recently with TomTom, Microsoft's
>ownership of that IP will stand up in court

We do NOT know if VFAT would stand up in court. All we know is TomTom and Microsoft were willing to settle out of court.

RFS = FAT + journal? Robust - sigh...

Posted Nov 16, 2009 22:06 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

It's simply a FAT file system with two file allocation tables.

Er, didn't the FAT filesystem *always* have two file allocation tables? (Or did FAT32 drop one of them? I had switched to Linux everywhere and stopped paying much attention to such sucky filesystems by then.)

RFS = FAT + journal? Robust - sigh...

Posted Nov 19, 2009 12:58 UTC (Thu) by arnd (subscriber, #8866) [Link]

The point where you get transaction safety with FATfs is when each of the two FAT copies resides on exactly one erase block of the underlying flash, and you do all updates as a copy-on-write operation, like:

1. write modified data blocks and directories in previously unused clusters of the file system, without updating the FAT
2. erase the first copy of the FAT
3. write the modified FAT with the new state to the first copy
4. erase the second copy of the FAT
5. write the modified FAT with the new state to the second copy

Upon mounting, you have to detect which copy to use, normally they are identical, and if they are not you should have an out-of-band checksum in the flash that tells you which copy is garbage (unless you have a fatal hardware problem, one of them is guaranteed to be intact) and you overwrite the broken copy with the good one.

It's an extremely simple operation that works exactly because the FAT design is so trivial that it keeps all block allocation data in one place.
If you file sizes are a large multiple of your cluster size (e.g. when storing audio and video data), it's also highly efficient on flash media.
Considering that FAT was designed for 160kb floppy disks without subdirectories, it works extremely well for todays applications.

SamyGO: replacing television firmware

Posted Nov 14, 2009 22:47 UTC (Sat) by Trelane (subscriber, #56877) [Link] (8 responses)

Alternate firmware was the main reason I bought a WRT router. I'd not thought about TVs, but if it's relatively foolproof to use alternate firmware (the "bricking" comment hit home), I might well consider the price and equipment upgrade when it comes time for us to upgrade to HD.

Cool catch; thanks!

SamyGO: replacing television firmware

Posted Nov 15, 2009 2:57 UTC (Sun) by yokem_55 (subscriber, #10498) [Link] (7 responses)

These are really high end TV's. The cheapest I could find start out at
~$1200. Frankly, at this point, one could get much better functionality,
with less money by getting a "cheap" LCD TV and hooking it up to an HTPC. No
worries about bricking the device, and a far more flexible hardware
platform.

SamyGO: replacing television firmware

Posted Nov 15, 2009 3:19 UTC (Sun) by elanthis (guest, #6227) [Link] (6 responses)

The TVs are also freaking gorgeous. My Samsung Plasma isn't even two years old yet, and I don't even watch much TV, but I drool every time I'm in Fry's and see the high end Samsung LED TVs. Thin, light, low power, crisp and brilliant images, and good overall design. I'm so tempted to "accidentally" drop my current 42" HDTV so I have a valid excuse to go guy a new 56" 1080 LED Samsung. ;)

SamyGO: replacing television firmware

Posted Nov 15, 2009 21:51 UTC (Sun) by Los__D (guest, #15263) [Link] (5 responses)

Strange idea... Replacing a plasma with LCD is like replacing Linux with Windows... :p

(ok, I have no idea how good Samsung plasmas are, but I'd NEVER trade my Pioneer plasma for any "LED" TV).

SamyGO: replacing television firmware

Posted Nov 16, 2009 1:52 UTC (Mon) by cventers (guest, #31465) [Link] (1 responses)

I have an LG 52" 720P Plasma and a Samsung 52" 1080P LCD... I much prefer the LCD. (Keep in mind, "HD" cable only runs up to 720p here, so it is a 1:1 comparison). Plasma also has problems with burn-in.

SamyGO: replacing television firmware

Posted Nov 17, 2009 22:20 UTC (Tue) by rahvin (guest, #16953) [Link]

I'm no expert but the cost difference and the tendency of the more cost competitive plasmas to be 720p rather than 1080p (like most LCD's these days) had essentially eliminated the plasma market (and coincidentally the DLP market as well). I had also understood that most of the manufacturers had dropped their plasma production and were focusing solely on LCD's these days.

SamyGO: replacing television firmware

Posted Nov 19, 2009 5:46 UTC (Thu) by roelofs (guest, #2599) [Link] (2 responses)

Strange idea... Replacing a plasma with LCD is like replacing Linux with Windows... :p

Um...he said "LED", not "LCD". Big difference. ;-)

Greg

SamyGO: replacing television firmware

Posted Nov 19, 2009 6:50 UTC (Thu) by Los__D (guest, #15263) [Link] (1 responses)

Uhm, no. A "LED" TV is still a LCD TV. The only difference is the backlight source.

For full LED backlight, the difference from old-style can be quite big through making dynamic contrast being an actual advantage, instead of a liability. With edge LED, which 90% "LED" TVs has, it's not completely the same backlight-bleeding, no-blacks junk, but not that far off.

When/if we see real OLED TVs, it will probably be another matter. Until then black levels, contrast, screen update (do NOT get me started on "100/200/400 Hz technology") and general quality are all completely in the hands of plasmas.

Only advantages for LCDs are brightness/anti-glare (if you have a really bright living room, or strong lightsources in front of the screen) and power usage, and maybe small-screen resolution, but 1080 on a 30" set is a joke anyway (unless you sit 1 meter from the screen). Burn-in is a non-issue in modern plasmas.

SamyGO: replacing television firmware

Posted Nov 19, 2009 12:37 UTC (Thu) by Los__D (guest, #15263) [Link]

To be fair, there's one more thing about plasmas that can be hugely annoying to those sensitive to it: phosphor trails.

SamyGO: replacing television firmware

Posted Nov 15, 2009 1:22 UTC (Sun) by tdwebste (guest, #18154) [Link]

"The kernel is 2.6.18-based with the addition of Samsung's Robust FAT File System (RFS),..."

Open access to RFS source trees would make porting forward to current kernel releases possible. This mutual benefit to Samsung and the community is the whole point of open source development. As it stands Samsung must bare the cost of reworking RFS and porting it forward off the past end of life 2.6.18 kernel.

Developing new projects around 2.6.18 is going to requires a lot of out of tree maintenance. However I am not surprised Samsung developed custom FAT for flash, we nearly did the same.

SamyGO: replacing television firmware

Posted Nov 15, 2009 22:02 UTC (Sun) by jimparis (guest, #38647) [Link] (6 responses)

I would love to replace the firmware on my Westinghouse TX-47F430S -- it has some crippling bugs, like enabling DPMS mode causes the TV to freeze and require a reboot. I found a firmware image for a similar TV and it is Linux-based, but there is no GPL notice or any source release. And they never responded to my requests. At least Samsung is using Linux legally...

SamyGO: replacing television firmware

Posted Nov 15, 2009 22:37 UTC (Sun) by Trelane (subscriber, #56877) [Link] (5 responses)

Should notify the SFLC and/or Linux foundation. Some resources:
http://www.gnu.org/licenses/gpl-violation.html
http://www.softwarefreedom.org/blog/2009/nov/09/gpl-enfor...

SamyGO: replacing television firmware

Posted Nov 16, 2009 0:20 UTC (Mon) by jimparis (guest, #38647) [Link] (4 responses)

I found BusyBox in the image so I sent a letter to gpl@busybox.net. If anyone else is interested, look at:
http://207.38.27.164/firmware/SW/SusanII_v1.6.3.rar
Uncompress it, then starting at offset 2601216 in safe-kernel.img1 you'll find a ramdisk image that contains busybox. There's other stuff around too.

SamyGO: replacing television firmware

Posted Nov 16, 2009 9:08 UTC (Mon) by mjthayer (guest, #39183) [Link] (3 responses)

Will Samsung be asked nicely before people get out the sledge hammers? Nasty legal letters may not be the best way to engage their community enthusiasm.

SamyGO: replacing television firmware

Posted Nov 16, 2009 12:43 UTC (Mon) by wesmo (guest, #50706) [Link] (2 responses)

Don't the SFLC usually ask nicely first? Harald Welte previously had some discussions with Samsung System LSI - http://laforge.gnumonks.org/weblog/linux/samsung/index.html

SamyGO: replacing television firmware

Posted Nov 16, 2009 22:10 UTC (Mon) by jimparis (guest, #38647) [Link] (1 responses)

Just to be clear, this is Westinghouse with apparent violations, not Samsung.

SamyGO: replacing television firmware

Posted Nov 16, 2009 22:18 UTC (Mon) by mjthayer (guest, #39183) [Link]

Aaargh, sorry for not reading carefully enough.

LG tv set are linux and quite open.

Posted Nov 28, 2009 23:09 UTC (Sat) by GnuFan (guest, #62205) [Link]

very interesting this SamyGo project. this could bring some interesting new features on a fairly open platform. i hope the same could happen for LG too.

i have a tv set made by LG 42LH4000 and i found that i can get a boot loader prompt if i press the ESC button on the serial port (using minicom) during power up..
when i have mstar# i can give lots of commands, for example i can make more verbose the tv set with "silent nothing" and at next reboot see the kernel dmesg.

i'm looking to put in place a community like the samsung one. if there's people interested let's try to do something together!