OSD support area

This is a real rough'n'ready place where dev stuff is dumped. The not-so-big-chip inside the OSD is an ARM+DSP combo. If you don't know what either of those acronyms mean, you probably shouldn't be here...

For downloading, you'll probably want to right-click and choose "Save target as..." or however it is phrased in your browser.

Log

Here is a log of the bsp build process. It is missing error messages (these were written to stderr, not stdout...) but it shows what goes in in the build:

build-bsp.txt - 242KiB

Get involved!

There are details on the Neuros site about how to get yourself involved in coding for the OSD. Most of it relies upon having a working Linux/Debian system running.
However, for those of us used to Windows, this isn't so much good. So I have written a guide showing how to cheat and use Portable Ubuntu / CoLinux to set up a full OSD development system (plus, actually, a slow but working Ubuntu!) which can live on an SD card and integrate fully with Windows.

Rick's crash course in compiling for the OSD under Windows (Windows XP).

Why should you get involved? Well, it is easy to moan on the forum about this and that, but the basic bottom line is we have the ability to maintain the OSD ourselves. You can argue about whether or not Neuros should be doing this, but given they're working on the OSD3, I think we already know the answer.
And make no mistake. This is an awesome opportunity. You see, I have another PVR. It is the same basic chipset as the OSD (no network and USB only) but otherwise pretty similar. The firmware is lightning quick but looks like an '80s computer. The machine works but there are so many bugs and quirks that I looked to something better. Now, I don't portray myself as the God of programming. I would love to make the OSD firmware in my possession do the same stuff as OSDng but I don't think I'm that smart. However there are numerous little quibbles that I do feel I could look at.
And, when you get down to it, I'm sure anybody who has ever used a smart device (media player, mobile phone, programmable toaster, etc) has come across something that seems to be so damned simple, yet is so damned annoying, that you would sell your soul in order to have the source code to make that three-line modification to fix that issue that's been bugging you, like, forever. Hell, I have been in touch with companies and OFFERED to resolve some of the issues completely for FREE... and I still hear nothing but silence.
So if Neuros has mostly given up on the OSD, it's only because they are a business and the world is moving to super-sexy HD and they have to keep with the times. But this doesn't mean that we have to give up on it too. I have no plans to go the HD route (can't afford it). My satellite receiver spits S-video and my little eeePC can play back MP4 files. See where I'm going with this? The OSD fulfils a need. It fulfils a need that I have and will have for the forseeable future.

Some itty-bitty tools and stuff

Some utils compiled for the OSD. I'm not sure how exactly to use them under Arizona as my OSD runs OSDng which offers a read/write filesystem. I may merge these into the main source so they are available.
My sources are released under the EUPL 1.1. This is like GPL 2, but was designed in response to the restrictive nonsense that was GPL 3. EUPL website

checkvideo 0.01 2011/01/04 3.8KiB (and source 3.5KiB)
This program checks the input video signal type and responds "NONE", "PAL", "NTSC", or "SECAM". It also sets a return code. Look at the comments at the top of the source for details.
hexdump 0.01 2011/01/08 5.1KiB (and source 3.6KiB)
This provides a hex dump. There is a "hexdump" as part of the standard set of tools, however this one provides both a hex and ASCII dump, plus start offset and length options.
type 0.01 2011/01/08 3.9KiB (and source 2.2KiB)
Types the contents of a file. Unlike using cat, this one is binary-safe because all control codes and high-ASCII are converted to '.' characters.

What's to come?

Nothing concrete. When there's code, there'll be something. However I scribbled a few notes while on break at work. You'll be pleased to know I've scaled this up so you can read it (the original is A5 size).
While there are numerous things to be done, I think the priority right now should be immediate gratification. It has been suggested to upgrade to a newer Linux kernel, and to change to a more modern build system. While these are both good ideas, the end user is going to be a bit "Meh" when all that work gives them an OSD that looks and feels just like their OSD prior to the update.
On the other hand, if we can get some of this immediate gratification stuff rolling, the world will see that positive changes are being made, and maybe more people will join in the effort. For me, this will be essential as I frankly can't make any sense at all of the build process.
One of my big hopes is now that Arizona is all whoo-hoo too big for Flash, I hope for a build where the kernel is in Flash and the rest of the system lives entirely on the CF, fully read/write and able to be customised/modified as required by the user - along with a compatible package manager for updates. You know it makes sense. If, for example, I get the YouTube application fixed up, standard Arizona might need an entire new rootfs update. OSDng will require you to delete "youtube" and copy in the replacement. With a package manager, you just select it in the menu and hit "install", but I'd like to think of taking it a step further with the auto-update system capable of looking for both new firmware AND new packages.
But, hey, one step at a time. Let's get some ideas running here. Something like this: Some ideas.

Anything to add? Comments? Ideas? Girlfriend proposals (well, by cute Japanese Engrish-speaking non-smokers only)?
Email me - heyrick1973 -at- yahoo -dot- co -dot- uk