Mediagate MG-35 -- new firmware available

[amaroc]

I'm really impressed to see how far you've already come debugging the MG-35. I don't own one by myself but some information on the J7 connector might be helpful for you.

1) connector J7:
I'm very confident that this is the JTAG connector for the Altera CPLD EPM3032. The pinning fits to the Altera-programming-adaptor like Byte-Blaster, USB-Blaster etc. The purpose here is to flash the CPLD via the Blaster. This can be done during development or in production-line as well. I guess is takes about 10..20 sec. for erase+program+verify, so production-line would still be possible.

2) purpose of EPM3032:
As mentioned earlier the EPM3032 is a CPLD that is electrically erasable and programmable. It contains only 32 macrocells and thus makes it very unlikely to be the glue-logic in order to flash the parallel flashes. 2x16MBit flashes of x16 organization would need more than 32 flip-flops in order to allow serial-to-parallel conversion, address-counter, flashing-state machine, etc. So, some glue-logic for eg. address-decoder is more likely.

3) JTAG i/f to EM8511:
In theory it's possible to do a JTAG chain between EPM3032 and EM8511 and also to use the J7. But that would mean the debug-interface to the EM8511 (ARM) would rely on an Altera standard-connector and interface - very unlikely. One could verify this by using an USB-Balster and the QuartusII-programmer ("Scan chain" button), but I don't think it's worth the effort. So, if there is any JTAG-i/f to the EM8511 it must be somewhere else - maybe TP45 ff. as mentioned by Ian earlier.

4) parallel flash:
I would bet that the parallel flashes will be populated pre-programmed. Flashing the device within the production-line would need too much time for an efficient production process. The normal flash update from a functional system is well known to all MG-35 owners, but assuming something goes wrong and the flash gets totally corrupted (incl. flash-loader) there should be some way to reflash the system easily (without soldering). Because J7 is unlikely from above assumption there is only J9 left - and Ian seems on the right track already.
I'm quite sure that there is also a mechanism of bootstrapping the system with something useful even if the flash-loader is corrupted. Normally this bootstrap will be initiated by sending some magic bytes via the serial short after reset. But to get this information without a datsheet seems to be almost impossible.

Hope this helps a little bit - and good luck on debugging.

[EmuMannen]

Originally Posted by PBee

Maybe an idea to look at a (better ?) player with Sigma core system where I know that users are enthusiast about the player, if you guys take a look at the firmware of this player is this one similar ? Can parts be used ?

Please take a look at the site of the HD Mediabox from PixelMagix,
user forum and ftp site for firmware

The HD Mediabox from PixelMagix is a great product but it is unfortunately based on Sigma Designs EM8621L and not Sigma Designs EM8511 (as MG-35). What we got is not a generic Linux device with a custom frame buffer (like an Xbox). The ARM processor isn’t the most powerful one (200MHz) and we therefore need some additional hardware support (provided by Sigma Designs chipset). That’s why we can’t just through in something like MPlayer instead of the default software used for media playback.

But maybe we could scavenge some software from other Sigma Designs EM8511 based players (and maybe include EM8510 based players, I don’t know how compatible they might be)? They all look pretty similar in design and function (even using the same OEM remote control).

Here is my start of a list of Sigma Designs EM8511 based players:

Mediagate MG-35
Freecom Network Media Player-35
MODIX HD-3510
TViX mini C-2000U / C-2000U Lite
AivX (DVP-254)
LaCie SliverScreen
iZak Portable Media Device
Vantec AVOX Jukebox

[EmuMannen]

The above Sigma Designs EM8511 based media players got to have some hardware similarities, the same for the GUI even though there are a lot of differences too (I bet mainly design wise, not functionality)...

LaCie SliverScreen:


Modix HD-3510:

[EmuMannen]

Sigma Designs EM8511 based media players GUI cont.

Vantec AVOX Jukebox:


iZak Portable Media Device:

[EmuMannen]

The GUI of the Vantec AVOX Jukebox looks almost identical to the one on MG-35 (just a bit more colorful and nicer). Anyone know where I could get hold of a copy of it’s firmware?

[teddystacker]

@EmuMannen

Cant find that one yet , but LG also do another MG25 clone - F/w in the same format and extracts with PB's tools...


http://www.lgnetwork.com/lgnetwork/d...q=70&ca_no=021

[teddystacker]

@EmuMannen

Took some finding but here it is - firmware for Vantec AVOX Jukebox - This is Chineese , but reading various forums its the only one around , and does display in English.. Hope this helps..

http://rapidshare.de/files/28460567/...7_CHN.zip.html

Interesting point here is that this MG-25 clone has a screensaver , so it must be super easy for al Tech to add one to the MG-35?

[J. L.]

Originally Posted by teddystacker

Interesting point here is that this MG-25 clone has a screensaver , so it must be super easy for al Tech to add one to the MG-35?

I spotted that too... It would be really nice if the screen-saver was a separate program and not internal to dvdplayer.

Joe L.

[TheKrell]

Originally Posted by teddystacker

Interesting point here is that this MG-25 clone...

Hmmm. Now that you mention it, both the Vantec and the Mediagate MG-25 use firmware that ends in .update. I wonder if this would wreak havoc or simply ignore the network components on the MG-35 and otherwise work? The MG-25 in particular has firmware V 1.4.6 out already, and it has a readme that mentions the JPEG fade-in/fade-out that we got with the MG-35 1.4.5 firmware. It would be very interesting if the MG-25 firmware could handle the media that's troubling my MG-35.

[EmuMannen]

Thanks all! Looks like we got another "clone" (with built in networking) in the "DIGITAL/MOVIE COWBOY":





Take a look at the following page, it hosts firmwares for several models, DC-MC35UL2, DC-MC35UL/N and DC-MC35UL etc...

[gadgetmind]

Originally Posted by amaroc

1) connector J7:
I'm very confident that this is the JTAG connector for the Altera CPLD EPM3032.
-snip-
It contains only 32 macrocells and thus makes it very unlikely to be the glue-logic in order to flash the parallel flashes.
-snip-
In theory it's possible to do a JTAG chain between EPM3032 and EM8511 and also to use the J7.
-snip-
I would bet that the parallel flashes will be populated pre-programmed.

Yup, I agree with all of that. J7 is for the EPM3032 as I have buzzed TDI and TDO from the chip to J7. This also tells us that the EM8511 isn't on this scan chain. And the CPLD doesn't have enough pins to wiggle-program the flash.

The parallel flashes have paint blobs, presumably to show they are programmed and to mark high and low.

Let's just say that I have lost interest in J7 and am now planning to sniff around the set of pads by the EM8511 marked "D" - hires pictures in the yahoo group.

Normally this bootstrap will be initiated by sending some magic bytes via the serial short after reset. But to get this information without a datsheet seems to be almost impossible.

There might be an on-chip ROM handling a bootstrap - interesting idea, but as you say, hard to exploit.

Ian

[gadgetmind]

A few thoughts -

1)
We really need an FAQ and ideally on a wiki page. I'm finding myself having to look back through this thread to find stuff, and it isn't easy!

2)
I suspect the romfs is loaded at 0x1400000 so that the kernel can be decompressed to 0x1008000 and the cramFS then placed (uncompressed) after it in RAM. This means we'll only lose as much ram as the cramFS takes. The serial loader will take care of passing the new cramFS arena address into the kernel (it must as the existing kernel doesn't know where it was decompressed from without something passing in such information)

3)
The config data seems rather large. And I seem to have lots of copies already. This leads me to believe that the serial loader NV data and the kernel NV data are in the same area. Is it khwl.o that provides access to this? If so, then I'm sure there is spare room, and if we can figure out the driver calls, we can then get NV data of our own to configure our customisations. I'll hunt for docs on khwl and/or an intercept driver to capture all access to khwl.

Ian

[pbarrette]

Hi All,

My box is working again..

What I did was this:
1) Use the serial port to access the bootloader.
2) download serial romfs
3) flash romfs

The "romfs" file format is composed of the following parts:
1) 4 bytes locating the offset of the cramfs image.
2) Linux.bin.gz
3) Cramfs.img

The 4 byte "header" can be found in the complete firmware image. To get the correct one, I took a ".upgrade" firmware image and deleted everything up to 4bytes before the start of the compressed kernel.

In fact, the ".upgrade" image has a section called "ROFS" and requires a checksum in the firmware image for /bin/upgrader to accept it as valid. The ROFS section is exactly the same as the ROMFS that the bootloader is looking for.

Hope that makes sense.

-------------------------------------------------------

@Gadgetmind..

How did you determine that it was looking at 0x40004 for the kernel? That was the clincher. I kept loading the kernel image at 0x40000 and it kept failing to boot. To be honest, I'm not sure if the initial 4 bytes are just padding or not. I should probably zero out that first dword and try again, but for now, I'm happy with my working MG35.

----------------------------------------------------

@EmuMannen,

Your custom graphics are great. A hell of a lot nicer on the eyes than the boring grey. I do have a few comments though..
1) The logon image doesn't really fit with the rest of the Blue/Yellow theme.
2) The smiley face selection circle is a bit much. How about just a circle?
3) Images with rounded edges have an odd scan-shift problem.

The last is difficult to describe, so I'll take some pictures when I get home.

Otherwise, great job! The graphics work fine, look a lot better, and my palette injection works.

-------------------------------------------------------

@All,

I now know why my firmware flash killed my new box. I created a new cramfs image using mkcramfs in debian emulated through QEMU. The cramfs image checked out fine with cramfsck on debian and cygwin. It even opened fine with FSExtractor. But when I tried to extract a file with FSExtractor, the extracted file would be 0 bytes every time.

So, somehow I made a cramfs image that appeared to be OK, but extracted as 0byte files. Needless to say, the MG35 didn't like that very much.

From now on, I'm sticking with mkcramfs in cygwin. The cygwin generated cramfs images work fine.

pb

[zand]

Sigma em8511 based players:

- zioncom hv0102
- Auvisio HV0102A by Pearl
- MV-4000U by Mvix
- MV-4000U by Unicorn
- playTIME H35 by EFM
- MV-160 by MS-Tech
- BX-NMP101 by SUZA
- TMV-100 by Techsolo

- Auvisio HV0102B by Pearl
- MV-5000U by Mvix
- MV-5000U by Unicorn

Skins, firmware and link to a dedicated forum at:

mediabox_dnsalias_com

(sorry, I can't post urls).

[gadgetmind]

Originally Posted by pbarrette

My box is working again..

Woot! Great news!

The "romfs" file format is composed of the following parts:
1) 4 bytes locating the offset of the cramfs image.
2) Linux.bin.gz
3) Cramfs.img

Hmmm, I'm sure I tried roughly that. But my "offset" was the actually address of the cramfs in the ROM, but I'd have thought that would be ignored until boot time.

BTW, did you try "boot image"? This should boot the new romfs without flashing it.

The 4 byte "header" can be found in the complete firmware image.

I'm pretty sure this is the address of the cramFS in ROM. It matches the arena message printed by the booting kernel and the dump command shows the cramFS at this address.

[quote]
The ROFS section is exactly the same as the ROMFS that the bootloader is looking for.
[/QUOTE/

Great, so we should be able to use a command line tool to extract these? No, scratch that, we only need to distribute one for people to use for recovery. If you make one available for your new version with fancy graphics I can experiment with booting without flashing.

How did you determine that it was looking at 0x40004 for the kernel?
That was the clincher. I kept loading the kernel image at 0x40000 and it kept failing to boot. To be honest, I'm not sure if the initial 4 bytes are just padding or not. I should probably zero out that first dword and try again, but for now, I'm happy with my working MG35.

I took the address of the cramFS (0xE2809) and subtracted the size of the compressed kernel (0xA27FD) and got 0x4000C. I then looked around here for bytes matching Linux.bin and found them at 0x40004. The dword at 0x40000 is the address of the cramFS - I guess this is passed to the kernel so it can find it. The other 8 bytes are the uncompressed size and checksum that follow the compressed kernel in ROM. See my earlier messages with dumps.

My guess is that if you zero out this dword, the kernel will boot but won't find its cramFS. I think the "boot flash" command will play with this pointer after it decompresses the kernel to ram and copies the cramFS after it in ram. But the behaviour of "boot flash" is guesswork at the moment.

I now know why my firmware flash killed my new box. I created a new cramfs image using mkcramfs in debian emulated through QEMU.

That's the kind of thing that's scared me off making new images so far. I'm not sure I trust the windows tools and would like everything on Linux. I know this isn't for everyone, though.

Anyway, great progress.

So far you have -
Sussed the .upgrade format
Created and flashed the first home-brew upgrade
Sussed the pallette
Worked out the serial pinout
Worked out the serial password
Sussed the serial download and reflash procedure.
And much more.

Slow down - you're making us all look bad. :-)

I'm going to play with tftp tonight and try and get a new romfs into the beast this way. Should make development faster and less risky.

We can then take the big step of trying to build a working kernel!

Ian

[gadgetmind]

I guess what I'd really like is a tool that takes a kernel and a cramFS and builds either/both a .upgrade file and a romfs.m35 file complete with all headers and checksums. I'd like this to be multi-platform and ideally not need someone to install .net, python, etc.

It should also cope with larger/smaller kernels and cramFS and warn if the size of the whole lot exceeds 4MBytes-256KBytes (which is what I think our maximum size is)

The tool will need to either compress the kernel as part of the process or use zlib to find the uncompressed size and checksum (is it a zlib checksum?)

We seem to have some C coders raring to go, so maybe we can draw a diagram to specify the output file formats that are required and someone can knock something together?

Ian

[gadgetmind]

How did you determine that it was looking at 0x40004 for the kernel? That was the clincher. I kept loading the kernel image at 0x40000 and it kept failing to boot.

Note that you can't load anything at 0x40000 - it's ROM at this location.

The "download <media> romfs" command loads to ram at 0x1400000 The "flash romfs" then programs this into flash. I think the "boot romfs" command should boot it, but the more I think about it, the more I'm convinced that what I was putting into memory yesterday should have booted if this theory is correct.

I tried
memcpy 0x1400000 0x40000 0x3C0000
boot image
and it failed to deflate. Or maybe I typed it wrong. Will try again
BTW, the 0x3C0000 is 4MBytes (end of ROM - 0x400000) - 256KBytes (start of kernel+cramFS in ROM - 0x40000)

I think the serial loader is in the first 64k (0 - 0x10000) with NV data after it. I guess much of the serial loader is copied to ram (probably at 0x1000000) to run as otherwise it would struggle when reflashing.

Ian

[gadgetmind]

OK, how's this for a summary of what we know so far regards the format of .upgrade and romfs.m35 files.

----------------------------------------------------------------------
"UPGI" ascii
"XM02" ascii
dword = version (0x00010404 = version 1.44)

This next section seems to be optional
"BOOT" ascii
dword = checksum of bootloader (sum of dwords)
dword = 0 = flash location for bootloader?
dword = size of bootloader
bootloader data

This next section to EOF is the romfs.m35/image file that is used with the serial bootloader (but without the "ROFS" ID string)
"ROFS" ascii
dword = checksum of rom filesystem (sum of dwords)
dword = 0x00040000 - location to program in flash
dword = size of rom filesystem
--- from here to end of file is the rom file system
dword = location in flash of cramfs (0x40000 + size of compressed kernel + 4)
linux.gz (last 8 bytes are - crc32 and uncompressed size of kernel)
cramfs.img (last 8 bytes as for above)
----------------------------------------------------------------------

It looks like my copying and "boot image" failed as I needed an extra 12 byte header that's used for flashing but (I guess) not booting. Will try 12 bytes of junk tonight.

I guess we now have everything required to write a utility that will take an arbitrary Linux.gz and cramFS.img and make an output file with all checksums and sizes correct. I suggest command line options for whether to build a romfs or to include the full .update header and in the latter case for which version to inject. I suggest we *don't* include the boot data!

Ian

[EmuMannen]

Originally Posted by pbarrette

My box is working again..

Thats great!

Originally Posted by pbarrette

Your custom graphics are great. A hell of a lot nicer on the eyes than the boring grey. I do have a few comments though..

Shoot...

Originally Posted by pbarrette

1) The logon image doesn't really fit with the rest of the Blue/Yellow theme.

I know but did you like the logon image?

Originally Posted by pbarrette

2) The smiley face selection circle is a bit much. How about just a circle?

I was planning for a plain circle but I then played around a bit, will correct ASAP...

Originally Posted by pbarrette

3) Images with rounded edges have an odd scan-shift problem.

I guess it's because I did'n dither the final images and the combination of high color originals and the limited palette at hand for the final result. A screenshot would be valuable for evaluation and for future corrections (or alternative strategies)...

Originally Posted by pbarrette

The last is difficult to describe, so I'll take some pictures when I get home.

That would help a lot, I did everything more or less blind, just trying to eye-ball the final result based on different layers I had in Photoshop...

Originally Posted by pbarrette

Otherwise, great job! The graphics work fine, look a lot better, and my palette injection works.

Thanks and great news regarding the palette...

[austinv]

just fyi you can safely flash the Mediagate MG-35 to the "Digital Cowboy" firmware 1.4.5.

tried it, it works, but DC version is even uglier than AL Tech's version of 1.4.5 and doesn't seem to add any new features or bugfixes so i flashed it back.

>> i don't know if others have this problem, but my MG-35 can't seem to play 2GB avi files (Xvid/AC3 coded with AutoGK)... while the same files play fine on my PC and the TViX 3000. the MG-35 always starts at the last ~30 seconds of the file and i can't even time search to the beginning. suxx

[gadgetmind]

My message 1218 has been edited 3-4 times now as I've found cockups.

Depending on where you get the info from, the compressed size of the kernel either includes the size and crc dwords on the end or it doesn't. The most useful number is the one with these extra 8 bytes.

I'm really hoping that tftp and "boot image" will work - developing without reflashing will be *really* nice.

pbarrette: Any chance I can get the ROMFS section for your new firmware with pretty graphics?

Ian

[teddystacker]

@austinv

Can you please post a url for the "digital Cowboy" 1.4.5 Firmware..

[TheKrell]

EmuMannen posted it above. It's http://www.digitalcowboy.jp/support/index.html

[davidpeele]

Have been following the work you guys have done. I cant believe what you have accomplished!!
I understand almost nothing of the details :-) But it seems to me that we may have some home-brew firmware for our MG-35 sometime in the future and that is awesome!!! I really like my MG-35 but hope it can be improved.

Originally Posted by gadgetmind

A few thoughts -

1)
We really need an FAQ and ideally on a wiki page. I'm finding myself having to look back through this thread to find stuff, and it isn't easy!
Ian

Thats an great idea. I was thinking the same thing as there seems to be a lot of info scattered throughout the thread.
Anybody here know how to set up a wiki?
Is there anyway we non-programers can help support the work?
I think I'll go ahead an send a donation for the test box.

I think there are many mg-35 owners that are watching to see what happens here, but not commenting because this is (technically) way over our heads.

Keep up the good work!

[gadgetmind]

Originally Posted by davidpeele

Anybody here know how to set up a wiki?

http://pbwiki.com/ seems like one of the best.

How about "MediaGate" for the name of our wiki, with flyduck as a password and the first page called, "Mg35Faq"?

I'm happy to kick it off but am aware there are a lot of other enthusiastic people out there and I'm already tackling a few technical areas.

Is there anyway we non-programers can help support the work?
I think I'll go ahead an send a donation for the test box.

Yes, money works. There are still a few risky stages and we're really lucky that no-one has had a box out of action for too long yet. Getting a development MG-35 to send to whoever most has the need at the time will help a lot.

If we do start a wiki, there are lots of non-technical issues that can go into an FAQ.

Ian

[teddystacker]

I would be papared to get a "archive of what we have found" on a wiki page , but would need some of the more techie guys to write this all out first.I could go back thru alot of the old messages , but not really sure what has chanced and what has not.I have some techie knowledge but dont want to mess things up and publish incorrect data/findings

[gadgetmind]

Originally Posted by teddystacker

I would be papared to get a "archive of what we have found" on a wiki page , but would need some of the more techie guys to write this all out first.

There is nothing worse than a blank sheet of paper. If some gets the structure and questions in place, others can flesh it out.

but dont want to mess things up and publish incorrect data/findings

Wikis thrive on people being bold. Stick the raw info up there and others will correct it.

I do a lot of thinking out loud on this forum. Some is right, some is wrong, but even the wrong bits can get someone's mental cogs whirring, and before too long they will have put me right.

Ian

[teddystacker]

Ok I will get something going later or tomorrow , off out for the day now..

[EmuMannen]

I have unpacked several firmwares (just for fun) and compared the content. As already noted, the “Digital Cowboy” is more or less identical (if not) to MG-35. It has a “bluish” theme but rather ugly if you ask me.

The Vantec AVOX Jukebox has the nicest GUI but it’s a bit different set of graphics. Took a look at the device and it’s a 2.5” device without a RJ45 socket. So I assumed that there are EM8511 based media players (based on the same development kit) that are network enabled like MG-35, Freecom & Digital Cowboy. And that there are the ones without network support like MG-25, Modix HD-3510, Vantec AVOX Jukebox etc.

Reasonable assumption I guess and maybe that’s why the following lines in \CRAMFS\etc\sashrc in the Vantec AVOX Jukebox firmware are commented out:

#!/bin/sh
echo
echo "Welcome to the EM85xx Shell"
echo

#mount -t proc proc /proc
#mount -t ramfs ramfs /hosts
#mount -t ramfs ramfs /net

/dvdplayer.bin &

#sleep 3

#/sbin/ifconfig eth0 192.168.0.222 up

But it still include: \CRAMFS\kernel\drivers\net\dm9000x_32.o and some of the graphics read “Network Setup” (net0.png, net1.png & net2.png). It also got an image named “list_netdisk.png” etc.

This made me all confused and I can’t find a users manual for the Vantec AVOX Jukebox so I can’t verify if the GUI got support for LAN configuration or not (but why should it if the unit doesn’t have a network connector)? I wonder if the graphics are leftovers from a development kit…

[gadgetmind]

OK, I decided to take my own advice and have created a wiki.

The first page is at - http://mediagate.pbwiki.com

Not much content yet!

[later]

OK, I've added an embryonic FAQ and an unfinished page on serial reflash. It's a pretty fast wiki and the adverts down the RHS are from Google and don't get in your face.

Ian