Rick's b.log - 2011/04/07
You are 3.21.248.105, pleased to meet you!
|
Rick's b.log - 2011/04/07 |
| It is the 24th of November 2024 You are 3.21.248.105, pleased to meet you! |
|
mailto: blog -at- heyrick -dot- eu
The caveat? It is bricked. A failed reflash has left us looking at a device that for all intents and purposes is completely dead. You don't even get a power LED, there's no code to turn it on. There is no code ... period.
My task, that I've been dumb enough to volunteer myself for, is to take this nifty-looking doorstop and cobble up something to hijack the processor via the JTAG interface to push some reflash code into the box. Enough, at least, to get us going again through the usual Neuros "emergency update procedure" (because it'll be time-consuming enough to flash in a copy of the Neuros U-Boot, never mind attempting the entire operating system!).
By the way, American power brick. Hehe, I'll have fun trying to find an adaptor for that! Might just wrap some wire around the pins and 'leccy-tape em secure. Consider that an "engineer's fix". After all, American plug pins have these holes... holes that just invite you to do something with them.
My aim is to present a piece of software and say that a 'bricked' OSD can be rescued by:
Here are the JTAG port connections:
It appears that holding TRST high while the processor is in reset will force debug-halt mode. We must halt the processor in order to take control of it. It looks as if there is an IC to hold the hardware in reset until the power input is stable. Will this suffice? Failing that, there is provision for a conveniently-placed reset button.
The general idea is as follows:
I must thank Gerry for sending me his dead unit. It'll be an interesting challenge, for sure!
Why am I doing this? Well, as sad as it may seem, the OSD is winding up. There will be no more.
It is a crying shame, for the OSD's processor core isn't quite powerful enough. And no, many people get by just fine with SD. If the material is engaging enough, the resolution doesn't matter.
But, let's not forget that the DM320 datasheet is dated 2003. Back in 2003, a 128MiB MP3 player would have been basic and expensive. Now the same sort of price will get me something with a reasonable sized full colour display, at least 8GiB onboard, and possible SD support, plus the ability to play back a variety of video formats. The state of the art moves rapidly, and the DM320 is showing its age.
The day has come for the OSD as a commercial venture. I understand that, Neuros have to make money - for if you miss that then you just can't survive as a company, and a product that doesn't have mass appeal is a product that won't be making money. There is stuff on the website about an OSD2 and an OSD3, but I don't know what these are like as I have nothing here that is HD. Hell, those HD animé fansubs even get scaled down, my computer's display is only 1024×600!
Even so, the OSD continues as a personal adventure. I have ulterior motives for wanting to recover this bricked unit, for I make a lot of use of my own OSD and I don't fancy using it as a testbed for every screwball idea that passes though my sorry excuse of a brain. This, OSD#2, should it be unbricked, will find itself volunteering to be the sacrificial lamb.
Actually, I'd like to write a little module to 'fake' a Linux environment, run the closed-source codecs in that, and have the backend be RISC OS with the UI provided by a monolithic program written in BBC BASIC. Tell me that isn't getting dangerously close to electronic steampunk! Any takers? 'cos I think porting RISC OS to this platform is kinda over my head. But I bet it'd run like greased lightning and fit, entirely, in the Flash. <grin>
So, to finish with, as I've got the thing opened up, let's take a quick wander around.
For recording:
Video is presented to the DM320 as if a CCD imager was attached. That being the picture sensor in generic digital cameras. Essentially the tvp5150 'fakes' being a digital camera imager. I think that is kinda cool.
From here, a lot of stuff happens internally in the DM320 - the image is scaled, MPEG4 encoded, and spat out to the relevant storage.
Memory:
For playback:
Other features:
Notice how clean and concise the board is. How it is laid out clearly, well marked, with an abundance of test points. My hat off to the designer.
Okay, that's it for now.
A new toy... sort of. ☺
In the post today arrived this:
I'm not overly happy about the first two steps, but Neuros didn't include JTAG sockets in the device (well, let's face it, there's probably a lot of OSDs in use that'd never need such a thing) and a special cable is imperative. That said, it is intended to be pretty simple all around, so if anybody feels like electronics is too much, any competent TV repairman ought to be able to do it all in around 10-15 minutes.
Anyway...
But all is not lost, far from it, for the ARM is clever enough to take itself out of debug, execute an instruction synced at system speed, then drop itself back into debug mode.
Our instruction? Try STMEA R8!, {R0-R7} to write eight 32 bit words to the address pointed to by R8, writing upwards (from zero) and with R8 pointing to the next free location.
How this would work is... set R8 initially. Then load data into R0-R7. Push the instruction code for the STMEA into the pipeline. Execute. Push NOP (MOV R0,R0) into the pipeline and execute three times (this clears the pipeline). Don't need to touch R8 any more (the ARM has updated it for us), so we load R0-R7 with new data. Push STMEA into the pipeline. Execute. NOP, three times. Get the idea? To write 264KiB of code (256KiB for the U-boot image, and 8KiB of code to do something with it... will require us to perform this merry dance a mere thirty three thousand seven hundred and ninety two times. Holy expletives!
But, on the bright side, anybody who has ever reflashed their OSD will be used to tedious waiting of epic proportion. No, I'm not abusing the word "epic", flashing 16MiB took in the order of an hour. I don't actually know for certain, I gave up keeping track and did something else. It was inordinately slow.
Let's face reality. It cannot handle H.264 so all that crap downloaded from YouTube just won't work (unless you are happy with 240p and usually mono audio). It cannot quite manage a full frame picture, in either record or playback. So all those 720×576 DVD rips? Won't play. For those who rip MPEG2 directly, it might play provided you don't try to hit it with 5.1 audio. It'll take a while figuring that out and you'll quickly lose sync. I like my OSD, so I won't hit it with an H.264 HD (1080×720) MKV. But I will tell you that my 1.6GHz Atom based machine struggles.
And, let's face a brutal reality. SD-only is a hard sell these days, when World+Kitten wants HD.
But this isn't to say that it is a dead duck. For I am perfectly willing to accept the limitations in resolution for the sheer flexibility afforded me. I have, hand on heart, never come across a video recorder that could do all the nifty stuff that the OSD makes easy. And having the ability to hack it to bits? Well, that's just icing on the cake.
There are plans afoot - for Gerry Boland is looking to get more from the back-end (more efficient kernel, etc). I myself will be looking to modify/update/patch the user interface. The question on everybody's minds is should we modify existing Neuros code, or rip it out and reimplement. I think the answer depends upon the code. Many agree that the scheduler code is sucky. It works, just, but it is astonishingly inflexible for anything other than the direct using-the-user-interface method. You can't, for example, reliably script timed recordings.
Sadly, the more I think about it, the more I'm leaning towards a rewrite. I am thinking the next version should be a sort of middle-ware where "actions" are handled by a "service". Play, record, pause, set schedule...
And what issues these actions? The user interface. A scripted web page. The user via telnet. Whatever.
So instead of a shiny program to handle user interactions and do what is requested, the user interaction handler will simply translate the desired activity into a request for the service to obey. Then multiple end points can control the behaviour of the OSD in a consistent manner. I set up to record Tokyo Eye and then went shopping. I forgot to set a duration. Never mind, I wait half an hour until the programme is done, then I use my mobile phone to log into my OSD. I tell it to finish the recording, and I check the status to see that it has done so. That is sort of what I envisage. But hey, that's just me. ☺
Now the OSD is, on the face of it, a really simple clean design. It works as follows:
Video is fed into the TVP5150 chip. This converts analogue video (composite or s-video y/c) into a digital representation. A miniscule sliver of a chip (I had a bigger piece break off my tooth after an unfortunate incident with a Ginger Nut), it is capable of some amazing stuff. It will automatically recognise and decode anything. PAL, SÉCAM, NTSC... even that bizarre 60Hz PAL. It has enhanced smarts to pull a half-decent picture from a really crappy dirty old videotape, and it can data-slice for teletext and closed-caption.
Audio is fed into the AIC23 chip. This is a "codec" in its rawest form, meaning coder/decoder. It converts analogue to a PCM representation. Nothing particularly clever there, though a nice feature is it can run both input and output simultaneously so you can hear what is going on.
The TMS320DM320 is the chip bang-smack in the middle of the board with the cute little moat around it. This may be crappy and slow by today's standards, but in its day it was quite the little powerhouse. A 200MHz ARM926EJ-S core, a 180MHz DSP, lots of other hardware assist (preview engine with hardware scaling, for example), it is a SoC (system-on-a-chip) aimed at photo/video applications.
It is capable of outputting a PAL or NTSC image from a layered framebuffer. The layering means you can do some nifty stuff like overlaying a menu on top of a live video. The OSD uses this sort of thing extensively.
Granted, the ARM is not terribly fast here, so we do see it start to struggle when it is coping with the demands of the Qt4 windowing system, and there isn't really enough bandwidth in the chip to properly handle a full-frame PAL video (720×576). Given the chip is specified to be capable, we have to wonder if the datasheet lies (most do...) or if the codec used is somewhat inefficient? Perhaps a bit of both (my other PVR on the same chip can manage 720×480), and perhaps the additional bandwidth that might have made higher resolutions possible is consumed with running the operating system itself?
It isn't that big a deal - I used to record 720×480 on my older PVR, but I soon stepped it back to 640×480 as I couldn't really tell the difference...
There is 64MiB SRAM onboard. The embedded Linux (based upon Debian) claims 34MiB, the rest is "unallocated", though in truth it is the DSP/video codec playground.
There is 16MiB Flash. This is supposed to hold the boot loader and the entire firmware. And it did. However as of the Arizona firmware, OSDs come with a small (128MiB) CF card because efficiency is not a concept known to Qt4. It is too big for the Flash. Coming from a RISC OS background where the entire OS fit into a 4MiB ROM pack, I will say nothing.
There isn't much to add. Video data is loaded, decoded, and pushed into the video framebuffer where it is then presented as a composite PAL or NTSC signal. The DM320 does not provide s-video output. Nor does it provide RGB, however there is an LCD interface (for using it in a digital camera) so it might be possible to mess with the timings to get it to spit out something close enough to RGB for a television to display? This is not 'standard' so it is no surprise it is unsupported on the Neuros OSD.
The DM320 itself can talk to Flash, SRAM, SD cards, USB devices, and IDE/CF. This makes it pretty flexible, and the OSD brings you all of this.
In addition, a DM9000 provides 10/100 ethernet capabilities. You are supposed to be able to record directly to NAS boxes and the like, but I pretty much just use it to telnet in and poke around. ☺
There is a small serial interface. This is primarily to talk to the bootloader to modify options (such as set up netboot to test new firmware).
Finally, there is another processor. A little microcontroller gadget MSP430 which handles the infra-red remote, the IR blaster, and the real-time clock. Unfortunately the source code for the firmware embedded in the MSP430 is not available, and the driver is closed source, so I cannot tell you what level of integration the MSP430 provides - as it is remarkably low-spec I am assuming it simply cleans up IR signals (instead of decoding them and returning a key-press value)? Just a guess...
This is looking west. On the right of the board (foreground) are two 16 bit SRAMs. Accessed in tandem, they provide the 32 bit word expected by the ARM.
The big round thing off the lower right of the picture is the button cell (a standard CR2032) that keeps the RTC running and correct.
Just behind it, the chip with the little gold blob on it, is the RTC/IR microcontroller. Just in front of that, the line of copper holes, is a different sort of JTAG for talking to the microcontroller.
The missing chip, on the left, is a power regulator and associated hardware for the CF card. I guess this was deemed not to be necessary in production hardware?
The DM320 is visible too.
This is looking east. We can see the DM320 from the other side. The big chip, the biggest on the board, is the 16MiB FlashROM. There appears to be space for another, but this was not fitted.
In the extreme foreground of the picture is the JTAG, provided as a set of holes. You'll need to add your own socket to plug stuff in to!
You can see, also, the space for a reset button.
We are looking south-east now (from the rear-left). The foreground chip, you can see, is the AIC23 - the audio chip. Just behind that is a PLL to provide the clocking for the audio sampling. If you look to the right, the titchy square thing is the video decoder chip. I told you it was tiny!
The big silver can is the ethernet socket. Just behind that is a big-ass protection/buffer chip to try to protect your OSD if there's anything unpleasant in the network cabling. And behind that, the DM9000 network chip.
The missing chip between the two can capacitors was to be a small serial EEPROM. Perhaps this was to be the original location for configuration storage? It doesn't appear to have been retained in the release versions.
Final picture, looking south-west. Battery quite visible. As is the video pass-through relay (the white thing). Tucked down at the front of the picture is an interfacing chip that converts the 3.3V serial signals (as used by the DM320) into +/-12V as expected in traditional serial applications. It is also capable of withstanding (and protecting from) a 15kV static shock on the serial input.
Everything else, we've met. Left-to-right, the SRAM, the little gold blob on the microcontroller, the DM320 in the heart of things, the DM9000 network chip towards the right, and you can just see the audio timing PLL on the far right.
No comments yet...
| © 2011 Rick Murray |
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted. RIPA notice: No consent is given for interception of page transmission. |