Rick's b.log - entry 2011/03/08

The perils of not-quite open source

Years back, when the OSD was new, this was like a breath of fresh air. Hardware hacking is an ongoing occupation, just ask Sony who are in an ongoing battle against people trying to hack their PlayStation console (but I have no sympathy, they removed the "OtherOS" feature in a firmware update, and the sort of people who know what to do with such a feature are the sort of people who want it back...). The thing is, most companies don't want to provide details of their gadgets. Look at the troubles I had trying to get anywhere at all with my older PVR and its selection of bugs. Likewise media players, printers, routers, all sorts of gadgets are on the market, and while many work well, straying outside the narrow confines of what the manufacturer envisioned leads to behaviour that can be quirky, or just plain wrong.
We are starting to see a community build over routers, with "OpenWRT", and there is a media player software called "rockbox", both of which add a lot of possibilities over stock firmware. But in many cases, these are people way smarter than me working out how the device behaves with datasheets and examining the circuit board inside their own.

Enter the OSD. Neuros' aims were admirable, but ultimately flawed. Through, I should point out, no fault of their own. It was hoped that a community would develop around the OSD, but this never happened in the same way as, say, OpenWRT.

I'll tell you why. The first, greatest, flaw is that Texas Instruments are unwilling to provide datasheets. I have collected them from various places, but none of them from TI. Indeed, the DM320 datasheet says all over it that it is subject to a non-disclosure agreement. It is a bit ridiculous to use this chip in an "open source" project, but Neuros didn't really have a lot of choice in the matter. On the side of TI, it is ridiculous to keep this up for a chip you won't even find mentioned on their website any more. But as TI were pleased to give me the brush off, they've made it quite clear that they have no interest in the little guy.

But even this is only a part of the problem. You see, Neuros provide all their source code. It is a standard version of Debian Linux booted from a slightly-modified (for emergency reflash) version of U-Boot. It runs Qt4, and a bunch of Neuros applications for menuing, programme scheduling, etc. But how does the video stuff work? I'll tell you how - it is a bunch of closed source libraries provided under a licence from Ingenient (now Sasken Inc). A pile of .ko files.

Now, the thing with this is that there is practically nothing to do with the OSD. Okay, people have added stuff like Lua, a VNC server, and other apps. I could, if I wasn't using it, rejig it to be a webserver reading my site off an SD card - much of the stuff in the Debian repository which has an ARM version ought to work, and I have a toolchain to allow me to build stuff.
But the hardware pretty much remains a black box. Both at chip level due to lack of official documentation, and at API level due to, pretty much, a lack of any documentation whatsoever.

Here's an example, from SVN /Neuros-Cooler/cooler/core/src/video-control.c, and as an aside, it is nice to see somebody who uses brackets clearly and logically:

  int CoolVideoPassthrough(int enable)
  {
     int fd;
     int ret = 0;

     fd = open_fd();
     if (fd >0)
     {
        int passthru = 0;
        ioctl( fd, 0x77, &passthru );

        if ((enable == TRUE) && (passthru <= 0))
        {
           ret = 1;
           ioctl( fd, 1, 2);
           // TODO: enable audio passthrough too...
        }
        else if ((enable == FALSE) && (passthru > 0))
        {
           ret = 1;
           ioctl( fd, 1, 3);
           // TODO: disable audio passthrough too...
        }
     }
     return ret;
   }

This code talks to the driver for the TVP5150 chip, which is the chip responsible for converting analogue video (either composite or s-video, PAL/NTSC/SÉCAM) into digitised video.
Now there are loads of controls available for this chip. It can do all sorts of clever stuff like VBI data slicing for WST teletext, closed captioning, etc. It also has controls over the brightness, contrast, picture sharpness, etc. It seems a common complaint of the OSD is that recordings are too dark. This is not something I observe myself, but nevermind... it would be fairly trivial to have provided a setup screen where all of this could be tweaked, just like a real TV.

But no. The driver isn't interested. In fact, I'd go a step further and say the driver is too braindead to be able to cope with such things.

Recall the ioctl calls above. Here's the code:

.tvp5150_ioctl
&060C : STMDB  SP!, {R4, R5, R6, R7, R8, R11, R12, LR, PC}
&0610 : SUB    R11, R12, &4
&0614 : SUB    SP, SP, &4
&0618 : MOV    R8, &0
&061C : CMP    R1, &8C           ; Read from TVP5150 Status Register #5
&0620 : MOV    R7, R1
&0624 : MOV    R6, R2
&0628 : STR    R8, [R11, -&24]
&062C : BEQ    &7C4

&0630 : BHI    &64C              ; if higher, polling control
&0634 : CMP    R1, &1            ; select video input / blanking state
&0638 : BEQ    &6C8

&063C : BCC    &680

&0640 : CMP    R1, &77           ; engage/disengage the video pass-through relay
&0644 : BEQ    &884

&0648 : B      &8E0

                                 ; appears to be polling control
&064C : CMP    R1, &AA           ; something to do with device polling
&0650 : LDREQ  R3, =polling_stop
&0654 : STREQ  R8, [R3]
&0658 : BEQ    &8F0              ; another jumptable
&065C : BHI    &66C
&0660 : CMP    R1, &99           ; something to do with device polling
&0664 : BEQ    &8D4
&0668 : B      &8E0

&066C : CMP    R1, &BB           ; sets the polling time (1=50ms)
&0670 : LDREQ  R3, =max_times
&0674 : STREQ  R2, [R3]
&0678 : BEQ    &8F0
&067C : B      &8E0

One of the big problems is these magic values have specific purpose within the OSD, as we've witnessed the video chip driver accessing the DM320's GPIO to control the video relay. For this reason, any attempt to use the generic Linux tvp5150 driver will fail. Instead, we'd need to take apart this code to figure out exactly what it does before we could think of devising a replacement.

Now extrapolate that through several orders of magnitude for the codecs. It probably isn't hard to take apart an MKV (Matroska) file containing H.263 video, but this is perhaps best handled within the codec system itself, along with AVIs, MP4s, etc. However we've already seen some limitations here as Neuros had to pull apart FLV files more or less on the fly in order to support them (look at the code in the YouTube app). How about AVIs with multiple sound tracks or embedded subtitles? Or .divx files which are, pretty much, AVIs with a cherry on top. More or less anything that touches the hardware is tied up in an Ingenient library, which is an unknown entity to us.

In essence we have an open source design with undocumented hardware and rather a lot of undocumented kernel modules. This, I believe, is why the OSD didn't flourish. It is no big fault of Neuros, it is more a failing in the other companies that didn't quite share the same vision. But then again, not so much has changed. This isn't to say that everything should have a "please hack me" sticker on it, but most companies get a product to market and then pretty much forget about it as newer better things are developed. Indeed the OSD stuff on the Neuros website is ages old as they moved on to bigger better plans, like HD capable devices. This, again, is nothing new. You expect firmware updates if the device was rushed to market with bugs, but other than that, the fact that something has a flashable firmware does not mean that it is there for your convenience. These days EPROMs are pretty much dead as flash chips offer many advantages, plus in-situ programming if necessary. So they are convenient. But don't expect much support for purchased gadgets, the company concerned is already working on the next great thing...

...which makes me ask the obvious question - when a device is 'old' and no longer commercially important, what is the harm in releasing docs and code for it? Consider my old Zen. Creative still has a Zen range, but they are rather more advanced devices. My Zen is lovely, but there is a lot of stuff it could do better, and there are a few features that would be pretty cool (drop-in subtitles from an .srt file, for instance). Could these things be added by the user community?

Which brings us back to the OSD. A person called Gerry is looking to revamp the toolchain and the base kernel (interested? take a look at https://github.com/gerboland/OSD-re/). The Neuros toolchain is a shell script that calls an unholy mess of makefiles. And the kernel is a later version with a different (faster) type of floating point support. This is working, the framebuffer driver and the kernel image, built with a newer toolchain (buildroot, I think?). The thing is, he hasn't yet tackled the issue of the rest of the firmware, which begins with loading in the other codec modules. Will they even work with the new stuff? It hasn't been plain sailing, but he has certainly done some sterling work!

Me? I get the easier slice of the pie. ☺ While Gerry is interested in updating the basic system that makes the OSD go (plus dabbling with ways to make Qt more responsive), I want to tackle the UI side. To give the interface more bells and whistles, to make it more functional, to make it more logical (no more "Copy"/"Cut" then "Paste" metaphor, but instead a "Copy to..." and "Move to..."), fix up the YouTube app, and generate a version of the firmware that holds the bare minimum in Flash and instead keeps most of the stuff on a mounted partition on the CF card. I plan to work, initially, with the original Neuros firmware, though once Gerry's version is stable, it would make sense to switch, this is all about moving the goalposts forward.
My early dabbles are here, but there's nothing of much use yet, which is why I've not bothered to design a webpage that looks better than something HTML 2.0 could offer. ☺ I have written up, however, a heinously fiendish way to get a build environment running under a version of Linux running within Windows. And no, I don't mean a dual boot, I mean right there inside Windows, as if it was a part of it! It even, actually, works!

Along the way, as I am one of those shameful hackers that considers the compiler and the screwdriver to be equal tools, I plan to attempt to revive a "bricked" unit with a homebrew JTAG lead and custom software. Sorry for all you high fliers, this will require a computer with an actual real parallel port, and a version of Windows old enough that a DOS-based program can hijack the computer and prod the port directly without starting an international crisis. This pretty much rules out anything XP or later. :-(
For those of you lucky enough to own a piece-of-crap 486 machine (!!!), I plan to provide complete details for how to revive the OSD, should I manage to get this working.

So that's two of us looking to do work with the OSD. Some stuff is a little clearer now I've collected up datasheets to get an idea of what is actually going on inside the thing, but there are still many questions and I am not sure if we'll get much luck on the codec modules. There were some plans (buried in the Neuros wiki) to replace some (most?) of the libraries with open source versions, but given these magic values and likely dependencies between them, it would be risky to try to replace anything without, at the least, a full API description.

But we continue. And it is my hope that companies will get over their inherent sense of protectionism and realise that there are people out there who want to improve their gadgets, and will do a lot of stuff "unpaid" partly for the good of the community, and partly for their own good. It might be worth pointing out that anybody who delves into the Linux kernel code will come across the name "Russell King" in the ARM parts. I've met him, nice bloke. It was his goal to bring Linux to the Acorn/RISC OS platform, so the machine could boot to either RISC OS or ARMLinux.
Fast-forward a decade and a bit, and there's quite a lot of stuff that is probably completely overlooked now. The OSD's code archive contains code for RISC OS time, Econet packets, ADFS partitions and FileCore discs... I can't help but raise a wry smile at seeing all of this. Did Russell, all those years ago, imagine his code would be running in my video recorder? Not to mention routers, printers, and other ARM-based gadgets with a Linux core? Just think if more companies were willing to make information available, not just to unis and other businesses, but to ordinary people too, where we could be and what could be achieved.
It seems the likes of Sony just don't get this. But, then, what do you expect for a company that wanted to rootkit its customers, and then offered a "removal" program that was even worse.

The melted eyeball

[if you don't know what I'm on about, read the previous entry...]

There has been a change in me, however. I now play five lines a week on the euroloto. It's a little more than I would like to spend (€10 a week), but I think I've about reached my limit of dealing with "corrosive" chemicals, both with splash risk and breathing the stuff in. I'm not out to win... what is it now, something jawdropping like €80,000,000? Hell, I'm not sure what I'd do with that sort of sum (asides from the obvious - wet myself, have a heart attack, die, in that order...). But yes, I'm looking for a sum sufficient I can hand in my notice and not have to worry about chemical agents ever again (and, <cough> go find somebody like this ☺).
Don't hold your breath, though. There was a guy in Brittany who bought a French lottery scratchcard. He won €10. He got an instant win card, and won another tenner. He played that on the French lottery, scooped the jackpot, eight million (article here, in French). While smart maths guys ponder the probabilities, I can say one thing - I am not the sort of person that has luck like that... But, I'll have more chance than if I just didn't bother, right?

Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
 
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

Rick, 24th October 2019, 20:24

Hello, I'm not sure if you can help me but I did see you posting on the Neuros forums often.    I moved over to using my new Android phone instead of my Neuros II. I was able to get a phone that will accept a 256GB memory card, so more than double the 120GB that I had on my Neuros.     I have, however, had less than good luck syncing my files to the phone. I have been trying for months to successfully get all the music that I want on my phone.     I was hoping to find a way to use NSM to sync to my phone. Do you know of any way to add the phone as a new device to NSM? I know that people have said that the other sync managers were better, but I never had any problems with NSM except that it takes awhile to sync. If I set it up before I go to bed it's usually ready in the morning so that's good enough for me.     I don't know anything about programming or coding so if there is any way to do this with limited skills that would be best for me.    Thanks in advance for any help or info you can share.     You can contact me by email or on Facebook Messenger @ https://m.me/rick.miner.562

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 86153 backwards.
		Your comment