Mediagate MG-35 -- new firmware available [Text View] - Page 4

supertoast

04-25-06, 08:41 AM

Just found out about NDAS today - great. Then I thought I'd ask Freecom for an NDAS key, also great.

I did that, about half hour ago, came here and read a few threads, checked my inbox and - yep, low and behold, my key and everything.

Can't say fairer than that! I'm blown away!

But...

I have told them and communicated with thier main r&d in Europe, and directly with product research in the Uk telling them they need to do something about the firmare and OS/Menu system to make this product truly outstanding, they really do not realise just how close they are to having a spectacular product.

For the life of me I can't understand why things are so clunky and unfinished on this unit, playlists, different backgrounds per folder (this would really liven up the product), continuous fast forward with button depressed, and all the other little fixes that are needed would really boost this product, yet still they seem not to want to put the work in - they're nuts, and more the fools them because they could really earn and reap the rewards for 'tuning' this little box up.

Still, they did get my NDAS codes to me in the same hour - that's amazing, and free.

Note: I didn't mention any model or anything, just my MAC address. Not that I am encouraging anyone to try and pull a fast one, it just made me wonder. Obviously Freecom have a cover-all license agreement for their range of other NDAS products.

Chris UK

teddystacker

04-25-06, 10:46 AM

@Chris Uk,

Well, I think the really bad news for us all here ,is that I myself don't think we will ever see any more major developments with the MG-35 firmware..

I agree with you totally,that they have the basis for a truly awesome product here.

But the way that Mediagate approach this,seems VERY VERY similar to many OEM producers in the far East..

I Run a Yahoo support/discussion group for a 2.5" Media player from a company called Keelai in China,I have done everything to help them sell and support their products,mostly in the hope that we may get some firmware improvements , but its seems impossible,as they just don't seem interested in giving any real support or discussing their product.

I suspect that Medigate are very similar - amazing that you develope a superb product,but just fall at the last hurdle and fail to answer the buyers requests..

I think the best hope we have here,is that at some point in the future someone may dump the firmware and make their own improvements.This is what happened with the Sampo line of dvd players a few years ago,when they produced a dvd player that you could add a hard disk to,but did not develope the idea any more - so it was left to people like us to made mods etc to the firmware.But in those days,things were much easier ,as many firmware chips were in sockets,rather than being surface mounted..

Just my take on the future of the MG-35...

Geekdragon

04-25-06, 12:46 PM

For my needs, I find the firmware with the MG-35 to be quite excellent already. Additional features, while welcome, would not greatly impact my opinion of the player. This is probably the view the developers are taking as well.

I may be easier to impress, however, since the MG-35 is already light years ahead of the D-Link DSM-320 I tried a year ago, before selling a month later. I don't think any amount of firmware revision would have fixed that pile. They failed to answer buyer's requests as well, except in that case the request typically was "make this thing work". Simply having a remote control that doesn't feel like it's communicating by messenger pigeon is a nice change of pace.

dcoleman

04-25-06, 04:11 PM

supertoast,

Please supply the email at Freecom that supplied your NDAS key, I have previously tried both Freecom and MediaGate with no luck...

supertoast

04-25-06, 04:30 PM

Funny you should say that GeekD, as one of my current gripes with the MG35 is the responsiveness of the remote!

I hear what you are saying though, it's just that to me there is a distinct and disapointing difference between the exciting specification of the unit, and the actual quality of feel using of the unit - if that makes to you? lol

It just needs polishing. I even designed some proper backdrops for them and have enquired about delving into the Firmware with new icons etc (this is why i wanted different backdrops per dir like the TVIX, then you can have your Music backdrop for your Music Dir, and Movies for - you catch my drift.)

Over a year ago I designed TVIX ones too. I do lots of designing for software and also marketing, it's what I do - possibly why I am so eagle eyed on this product - I just know it could be much better with little tweaks and would be so much more marketable to a wider audience, rather than just the technohead who will make do with the odd annoyance.

Anyway, that email addy...

supertoast

04-25-06, 04:31 PM

supportuk at freecom d0t com

supertoast

04-25-06, 04:56 PM

I've uploaded some of the older TVIX backdrops to my site, you can see how the backdrops change depending on what Dir you go into on the TVIX - it's a nice touch that I would like to see on the Mediagate - it would make it more visually appealing to my clients, I could sell it better.

Also on here - you will find my Freecom Backdrop I hand designed, I've cludged a quick version for Mediagate users too - I think you'll like the placement of the bubbles - ;)

http://www.digitalturntables.co.uk/media/

Bytre

04-25-06, 07:27 PM

How about a screen saver after a certain amount of time of non activity.

Really sucks when you own a plasma and you want to stop movie for a few mins (answer phone, have a smoke etc). Most current DVD players have screen savers for this reason.

Does not even need to be a screen saver just a blank screen will do !!!!!!!!!!!

No kidding! Came home a few weeks ago to find that the TV (Rear projection CRT) had been on all day at a mediagate menu.

supertoast

04-26-06, 12:20 PM

Anyone know how to bust open the firmware, and then repack it again?

I notice something about Jasper Bootloader v1 in the file when I open it in a text editor. I think it may be something to do with Unix/Linux.

I want to get in there and alter the icons, letters etc.

Any ideas?

ommm

04-26-06, 07:48 PM

No idea how to do it but when and if you work it out can you try and add more codecs into it so it will play everything and then send it my way :)

Good Luck!!!

Thanks

rowe001

04-27-06, 02:21 AM

Hello all,

I have been reading this forum for awhile now and decide due to the increased interest in making the mediagate software better I would share what I have learned so far. If others know otherwise please correct me so we can all learn.

The mediagate uses an embedded linux operating system called uClinux which is open source and can be found at "uclinux org".

Sorry can't post links until I posted 5 times to the forum.

The chip that does all the work in the mediagate is created by sigma designs and is a common component in DVD players. "sigmadesigns com"

The filesystem of choice for the mediagate is a CramFS "Linux Compressed filesystem". I found the following article that pointed me in the write direction
"urbangiraffe com/2005/03/03/mg25/7/"

I have successfully taken a mediagate firmware and pulled apart the filesystem to see the executables that are used and its structure. A mediagate firmware is actually a boot manager followed by a CramFS. Searching for specific characters allows you to find the start of the CramFS and throwing away the start upto this. After saving the remainder in a new file you can mount it under linux.

I think it is possible to recreate a firmware for the mediagate ourself, however if I flash something that does not work as expected and lets assume I damaged the ability to reflash the unit I would have a dead mediagate. I wanted a default mechanism to reload the original firmware. Wasn't interested in having a Mediagate for a door stop.

I investigated the internals of the Mediagate and it seems to me there is a serial port on the board, under the plastic that holds the HDD. Serial ports are a common way to reflash an embedded device if something goes wrong. Generally its a slower process, but would work. You should just need a serial cable, possibly "null modem" and a computer. What I don't know is its configuration, baud, stop bits and parity.

I was in communication with a guy at AL Tech who explained that they were not able to release the source code, due to it being his companies policy, personally I think this is stupid since they make money on the sale of the unit. Therefore if other people wrote good software for it they would make more money.

I asked about enhancements and was told a few were on the cards i.e. play lists, but nothing visual. They don't feel there is much benefit in changing the visual and usability. They only see it as a risk without much return. I guess this is a issue with the amount of memory available an how it is used.

I think they forget about the increased sales it would give. However when I started asking questions about the serial port and how to upload the firmware if the normal method did not work, they stopped answering me.

Anyway my background is in software engineering and currently I work on embedded software so I'm happy to work on this from time to time, but at this point I have hit a brick wall. Not really intersted in flashing my mediagate without a backup method I know works.

Frenik

04-27-06, 07:21 AM

Thanks for the info rowe... it would be good to see some open source firmwares for the MG-35.. I'm guessing that the mediagate was based on the Sigma Designs SDK, so there are probably agreements in place that say they are not allowed to distribute the source..

However, if the SDK is based on a GPL linux, then by all rights Sigma should provide the source for at least part of it.

teddystacker

04-27-06, 10:26 AM

@rowe001

I fully understand the problem here , this was similar with the Sampo line of DVD players a few years back,the only good thing about those is that that they had a flash rom mounted in a socket,so was alot Easier if re-programming was needed..

I for onem would be more than willing to donate some $ (say $15) towards buying a "test" MG-35 for you to work on , if enough of us did this, I think it would be worth risking the small amount of $ should the unit end up dead..

When you took apart the firmware was it easy to find the graphics screens? ie are they stored in a regular jpg or .bmp format?

Thanks for you input on this,as I said in my post above its pretty clear we will never get any major improvements from the maker of this unit.. - People like yourself are our only hope.. and I know I and many others are very grateful for your effortts..

supertoast

04-27-06, 12:09 PM

I would certainly contribute design to the icons and GUI layout, I've done this for other software in the past.

I too would donat some cash, and possibly supply the unit as, running my own IT company, I would be able to buy at trade cost, UK that is.

Where are you based Rowe?

raoulle

04-27-06, 05:42 PM

Please excuse me for asking what will appear to be a simple question - but I've really no idea at all how to use the NDAS features of the drive and e-mails to freecom have gone unanswered - What software do I need to have for windows XP in order to communicate with the mediaplayer 3.5 over the network? I have the NDAS key and the write key, I've even installed the NDAS management tool from smartdisk but to no avail :confused:

thanks for any help :)

erpel42

04-27-06, 06:22 PM

Since today 20060427 Freecom.com in Germany finally spreads the upgrade 1.4.3 in their support box!
When you have downloaded and unpacked the upgrade, you can find a .doc file. And here you can find the information, THAT if you want to use NDAS you may send your MAC-address and they will return you the keys.
I did this thursday morning and (waiting since decembre) and received the keys the afternoon.

As all of us know, it is not fast. But we do not have to run stairs with a device and an external ac-adapter.

Happy... erpel42

supertoast

04-28-06, 04:18 AM

Interesting this, as 1.4.3 is not an available Mediagate version, only 1.4.4 - I wonder if there are any differences at all?

I won't install it just yet, are there any adjustments to the User interface at all, any branding or anything?

matthammy

04-28-06, 10:47 AM

davei1

04-29-06, 05:45 AM

I'd be up for Paypaling $10 bucks as a group buy/effort to give a knowledgeable person a test unit to see if they can dump the code and figure it out...I'm mostly interested in the addition of CODECs and M3U (which we should have now), and most importantly to me solving the audio/video sync problem on some DIVX rips.
Better interface would be nice but is not most important to me...

I knew I recognized your name teddystacker...BTW my SAMPO DVE-620 is still going strong :D

@rowe001

I fully understand the problem here , this was similar with the Sampo line of DVD players a few years back,the only good thing about those is that that they had a flash rom mounted in a socket,so was alot Easier if re-programming was needed..

I for onem would be more than willing to donate some $ (say $15) towards buying a "test" MG-35 for you to work on , if enough of us did this, I think it would be worth risking the small amount of $ should the unit end up dead..

When you took apart the firmware was it easy to find the graphics screens? ie are they stored in a regular jpg or .bmp format?

Thanks for you input on this,as I said in my post above its pretty clear we will never get any major improvements from the maker of this unit.. - People like yourself are our only hope.. and I know I and many others are very grateful for your effortts..

ommm

04-29-06, 06:13 AM

I agree with the codecs as the major issue and would be prepared to donate to the fund as well

PBee

04-29-06, 11:04 AM

I agree with the codecs as the major issue and would be prepared to donate to the fund as well

Me too !!

Frenik

04-29-06, 02:51 PM

I wouldn't get my hopes up about adding codecs. I think whatever the EM8510 chip can decode now is all you will get.

M3U and Matroska file support would be good though.

davei1

04-30-06, 03:01 AM

Doesn't the chip just contain the instructions and routines? Therefore if CODECs were added to the section of instructions that contain the other CODECs wouldn't that work? Or is there some limitation with the chip (memory-wise) that would limit it's handling the additional instructions?

I wouldn't get my hopes up about adding codecs. I think whatever the EM8510 chip can decode now is all you will get.

M3U and Matroska file support would be good though.

snyd3r

05-01-06, 12:05 AM

i got one of these today with an 200gb hdd
i have to format the hdd but when i go to disk management it says that logical disk manager is disabled and inside word onto what that is?

much appreciated

gunrunnerjohn

05-01-06, 07:55 AM

Doesn't the chip just contain the instructions and routines? Therefore if CODECs were added to the section of instructions that contain the other CODECs wouldn't that work? Or is there some limitation with the chip (memory-wise) that would limit it's handling the additional instructions?The EM8510 is pre-programmed with the decoding algorithims used, here's the chip used: Sigma Designes EM8510 Series (http://www.sigmadesigns.com/products/em8510.htm). You can't "add" any new decoding.

hreasons

05-01-06, 08:53 PM

gunrunnerjohn,

Surely the Sigma EM8510 chip is not responsible for the out-of-sync divx files? The same divx files work perfectly on my Philips DIVX player which has a MediaTek chipset... I really hope this is not a flaw in the Sigma, else we're stuck with it (assuming someone can make homebrew firmware to fix this annoying issue).

Regarding homebrew firmware and the serial door on the MG35.. I had problems flashing my Philips player and had to flash it using the serial door on the main board. I had to build a custom serial adaptor.. using a MAX232 CMOS chip, a regular serial cable would fry the device, as the PC serial port knocks out 12 volts, it may be the same case for the MG35 as well.. assuming it uses a similar EEPROM chip where it holds the firmware. You can use Mobile Phone data-cables, they have the same CMOS converter chip inside the serial-plug. Before flashing it, I'd attempt to make a successful "read" of the existing firmware of the device before making attempts to write to it.

hreasons

05-02-06, 05:28 AM

Hi,

I have just bought one of these units and have a questions regarding the NDAS functionality vs the network functionality straight out of the box.

Is NDAS just for copying/deleting files to/from the internal HDD or can it be used to stream content from a PC/server/NAS/etc?

The reason I ask is that I have read on this forum and others that the default method of sharing (& streaming) files over a network involves enabling the guest account and disabling the windows firewall, which would seem a fairly insecure way of doing things?

thanks

Matt

Matt,

NDAS actually mounts the hard drive in your MG35 as a driver letter under Windows. And it behaves as if it were a local disk.. I didn't have to disable my Windows Firewall, the only problem with NDAS is that is very very slow. It can be frustrating copying movies etc. over, although I mainly use it for file management and copying subtitles over.

gunrunnerjohn

05-02-06, 08:04 AM

I don't have an issue with out-of-sync DIVX, how are you producing them? I use AutoGK (http://www.autogk.me.uk/), and I haven't had any out-of-sync issues with mine.

skymatrix

05-02-06, 08:36 AM

As I've mentioned before, I had no a/v lip sync problems with firmware versions prior to 1.4.0, but I now find that on all DivX avi files that I create with Dr DivX, I have to Re-Interleave the files to fix the problem. You might want to view my previous post (http://www.avsforum.com/avs-vb/showthread.php?p=6409074&#post6409074) about a fix for this. Note that AutoGK doesn't cause this problem because it uses an interleave setting which the MG-35 likes.

gunrunnerjohn

05-02-06, 08:55 AM

OK, I confess. I didn't go back six months looking for the problem. :)

RaZeR2

05-02-06, 12:03 PM

The filesystem of choice for the mediagate is a CramFS "Linux Compressed filesystem". I found the following article that pointed me in the write direction
"urbangiraffe com/2005/03/03/mg25/7/"

I have successfully taken a mediagate firmware and pulled apart the filesystem to see the executables that are used and its structure. A mediagate firmware is actually a boot manager followed by a CramFS. Searching for specific characters allows you to find the start of the CramFS and throwing away the start upto this. After saving the remainder in a new file you can mount it under linux.

I think it is possible to recreate a firmware for the mediagate ourself, however if I flash something that does not work as expected and lets assume I damaged the ability to reflash the unit I would have a dead mediagate. I wanted a default mechanism to reload the original firmware. Wasn't interested in having a Mediagate for a door stop.

If we could modify the image, maybe it would be possible to do things like get it to reveal the NDAS keys instead of having to pay for them - I personally believe it should be free anyway because it is available in a BIOS update.

Other possibilities could be removing some functionality to make room for new functionality, for example, I never use the MG-35 for MP3 playback, but I'd love it to run it's own SAMBA server. I know this wouldn't suit everyone, but I'd sure like the option, assuming that there wasn't enough room to implement a SAMBA daemon.

It would be great if it recognized .img (DVDDecrypter ISO image) as an ISO too for DVD playback.

hreasons

05-02-06, 01:27 PM

I don't have an issue with out-of-sync DIVX, how are you producing them? I use AutoGKand I haven't had any out-of-sync issues with mine.

John, I didn't say you had, but I have personally and so have a lot of other people on this and other forums. It's annoying because My Philips CD-based DIVX player plays them just fine. I got the MG35 purely for convenience, no more burning cds etc. My comment was, is it the firmware or the chipset at fault for the sync problems. Well, the sync problems have been DIVX's produced by other people that I've downloaded. ;) However, I've tested AutoGK (both DIVX and XVID) and I get out of sync files! I tried encoding same movie using Dr.DivX and it produces perfect DIVX's. (I got AutoGK to re-encode XVID QPEL encoded movies etc.) If you would be kind enough to share your AutoGK settings so I can try again.

Thanks.

Incidentally, I'm using latest firmware, 1.4.4.

RaZeR2, err.. I use DVDDecrypter to ISO my DVD's.. and they play just fine, no .img is produced, its just .iso... try renaming it?

skymatrix, I found your guide for fixing the interleave, I shall try it.. Cheers.

oneworld

05-02-06, 08:12 PM

I recently tried to create some mpg files with a higher resolution and more bps.
With no luck I tried 1024x576 and 2000 kbps.
Although the file plays fine with mplayer, it will not play in the MG 3.5.
Screen is blank but there are no messages. Is there some kind of limitation
that I've hit?

Frenik

05-03-06, 07:17 AM

If we could modify the image, maybe it would be possible to do things like get it to reveal the NDAS keys instead of having to pay for them - I personally believe it should be free anyway because it is available in a BIOS update.

I don't think the NDAS keys wouldn't be hidden in the MG-35 anywhere. They would be generated based on the MAC address.. As for paying, free would be nice, but it is another company's technology so AL Tech would have to pay licensing fees.

In future, that cost would be bundled in with the total cost of the players most likely.

millpub

05-03-06, 03:51 PM

Has anyone tried using the mg-35 to play back DVR-MS files. I have a media center in my living room, but my wife would like to access our movies and recorded tv shows in her bedroom. She doesn't care about streming live tv or the media center extender ui stuff, but I would like her to be able to access the DVR-MS files without having to convert them to a plain-vanilla mpg container or wmv. If anyone has tried it I would love to hear how it worked out.

geoffreyhan

05-04-06, 12:00 AM

I've just got the MG35, and tried to get it connected wireless using a Linksys WAP54G wireless access point. I've set the AP in client mode but seems still has no success.

Could anyone please give a bit more detailed procedure in setting up access point, connect with wireless modem/router and any issues that need to be cared about?

I use a Draytek wireless modem/router for internet connection. It connects with a PC through ethernet cable and wireless to other two laptops.

Thanks in advance.

Frenik

05-04-06, 01:45 AM

My guess would be no. I haven't tried DVR-MS files, but considering the MG-35 can't play WMV files, support for DVR-MS probaby isn't there either.

Has anyone tried using the mg-35 to play back DVR-MS files. I have a media center in my living room, but my wife would like to access our movies and recorded tv shows in her bedroom. She doesn't care about streming live tv or the media center extender ui stuff, but I would like her to be able to access the DVR-MS files without having to convert them to a plain-vanilla mpg container or wmv. If anyone has tried it I would love to hear how it worked out.

supertoast

05-04-06, 08:41 AM

Geoffrey:

Firstly, if your wireless access point uses Adhoc as well as Structured network, you may be better NOT selecting Adhoc to start with.

Try to lock down IP addresses on your AP and MG35, ie. specifiy them and write them down - it can be easier to track down, and ping devices later if you have issues.

Your subnet mask is likely to be 255.255.255.0 also, unless you have some unusual network setup/specific requirements.

Share a folder on your PC (My Music?) and see if your mediagate sees it.

Take it from there.

max_33

05-05-06, 06:05 PM

Well, I have installed the NDAS SW. Reading performance is somewhat ok (~5-6 MBit) but writing performance is really bad. I get only ~700k on the network interface.

Any ideas how to fix this?

I have tried it with 2 different hosts with direct connect and via a switch. -> no difference

Firmware: 1.4.4

gunrunnerjohn

05-05-06, 07:26 PM

There is no fix for the slow NDAS speed AFAIK. That's one of the major complaints.

supertoast

05-15-06, 09:01 AM

I've since bought a Roku M1000 to meet my audio needs.

...and I won't be looking back I'm afraid! It's absolutely fantastic.

Video needs? It'd called get your DVD out of the cupbard and watch it, when your done return it to whence it came and get it out in another 6 months when you need it instead of taking up storage space.

Shame though, because I liked the principle of the mediagate, but I'm afraid to say it's a little too little, too late.

Shame on you Altech you fools. You could have done a little work here and there to make this box great, but instead you chose not to do the work needed on the software.

Nevermind. Still a good unit in many respects - but I'm tired of "making do" with it. I need things to be "just right".

tc0fh

05-16-06, 07:26 AM

So has anyone figured out the pinout of the serial connector?

I'm sure you need a max232 to bring the TTL levels to serial levels, but which pin is TX and which is RX?

Regards

gunrunnerjohn

05-16-06, 08:15 AM

I don't even know what the serial connector is used for, never mind the pin-out! :D It really shouldn't be a challenge to figure out the pin-out if I needed the connection...

mrgrumpyaus

05-16-06, 10:08 AM

I have the network sharing working on my MG35, BUT.. I can't access external USB drives attached to the computer even if they are set as shared drives..

I can see them in the Mediagate, but none of the files will play.. yet they play fine if I put them on any of the shared local drives..

is this something in windows or???

teddystacker

05-16-06, 01:23 PM

@mrgrumpyaus

See My Post #713

Thomas J. Coyle

05-16-06, 03:26 PM

Hi all,

I own two MG-35s and they are not bad media clients except for the file oriented GUI which, to me, has very low WAF.

Since Altech will be bringing out the MG-350HD I doubt very much that they will spend much more of their programming time upgrading the MG-35. I think that expecting any further OS updates is a lost cause.

I have migrated to XBMC on the XBOX. A used XBOX on eBay is around $100 and a mod kit is about $60 so for around $160 and all of the freeware you can possibly use, you have a much better supported machine and GUI than the MG-35.

Ya, I know the XBOX is bigger, but you guys are not going to do anything with the MG-35 OS that hasn't already been done by the XBMC Team on the XBOX and the XBOX is much more user friendly to hacking.

Just a thought.

Regards
TCIII

mrgrumpyaus

05-16-06, 07:42 PM

@mrgrumpyaus

See My Post #713

Thanks for that but unfortunately it didn't work.. no change.. I can see the drive and bring up a file list, but it won't play them.. also any directories on the external disk are unreadable..

yet any other PC on the network can see the drive and play the files..

frustrating!!!!

mrgrumpyaus

05-16-06, 08:05 PM

Thanks for that but unfortunately it didn't work.. no change.. I can see the drive and bring up a file list, but it won't play them.. also any directories on the external disk are unreadable..

yet any other PC on the network can see the drive and play the files..

frustrating!!!!

Seems I have solved it.. Windows occasionally adds this weird permission group to shared folders.. its like.. s-1273-gfh-etc.. it was marked as the folder owner.. (i think this happens when the owner account is not on the machine your using, not sure but i've seen it before)

anyway if you change owners to a local account and delete this weird permission.. alls well!!

markusx

05-17-06, 04:49 PM

Hi All,

Was on the Ximeta website, they posted yesterday a new NDAS driver. Will give it a try on my network tonight.

I have my MG-35 for about a month now, and it works great, even works with my Buffalo Terastation, which the video streams without any problems. Purchased it from ewaggle, but it took almost 3 weeks to get my key!!! A bit slow transferring through the network, so I just hookup through the USB. My Ximeta is much faster transferring files across the network.

Regards,

Markusx

markusx

05-18-06, 10:43 PM

fx57

05-19-06, 02:08 AM

I tried installing the the newer driver, but now my MG-35 is no longer active. Cannot access it even though it is listed as connected with my Ximeta which is working. I emailed Saerom Kim at Al Tech and he said that they haven't tested the new driver yet but will. Had to re-install the previous driver, everything appears to back to normal. If anyone has success let me know.

I tried 3.11 and can see the MG-35 from Windows but cannot mount it either R or R/W. The MG-35 icon is a white block and the mount options are not even in the menu. I downgraded back to 3.10 and can mount again.

maxdeman

05-19-06, 07:59 AM

Don't bother, none of the upgrades allows you to scroll while playing a song, only the original firmware does (where can i find it?) but then you have the problem that you jump to the first file every time you switch directory (Very annoying with aprox. 15000 mp3's in a "jukebox" directory layout).
Freecom (finally) made available the 1.4.3. firmware on their website. Scrolling problem solved and no more switching directory problems.

adi999999999

05-19-06, 02:47 PM

I tried the Freecom 1.4.3 firmware but I still could not scroll whilst playing and the fast forward function would no longer work whilst playing mp3 files,I also noticed the Freecom firmware is a larger file size then the Mediagate firmware

markusx

05-19-06, 03:01 PM

I tried 3.11 and can see the MG-35 from Windows but cannot mount it either R or R/W. The MG-35 icon is a white block and the mount options are not even in the menu. I downgraded back to 3.10 and can mount again.

I had the same exact problem. At least we're able to mount again after re-installing :) . If I hear any new news from Saerom at Al Tech, will post here.

Regards,

Markusx

maxdeman

05-19-06, 03:15 PM

adi999999999

05-20-06, 05:05 AM

Tried the freecom firmware again scrolling does work with the freecom firmware but the fast forward function still does not work,rewind works OK ,I even downloaded it again incase it was a bad download or something anybody else having this problem??

maxdeman

05-20-06, 08:11 AM

gunrunnerjohn

05-20-06, 09:30 AM

I had the same exact problem. At least we're able to mount again after re-installing :) . If I hear any new news from Saerom at Al Tech, will post here.

Regards,

MarkusxObviously, the folks Ximeta have restricted the new driver to the MAC address range of their branded products. I tested it on one of my test systems, and the status says there are no NDAS compatible devices. That tells me they've decided to restrict the usage.

markusx

05-21-06, 01:06 AM

fx57

05-21-06, 02:44 AM

Obviously, the folks Ximeta have restricted the new driver to the MAC address range of their branded products. I tested it on one of my test systems, and the status says there are no NDAS compatible devices. That tells me they've decided to restrict the usage.

Yep, looks like that's the case.

A post from Ximeta tech support in thier forums:

> FYI - The MG-35 is NOT a Ximeta Product and does not support 3.11. MG-35 uses a > NDAS chip but was not manufactured by Ximeta.
>
> The NetDisk 3.11 software is ONLY for use with Ximeta NetDisk's.
> _________________
> Dennis Lewis
> Technical Support Manager
> Ximeta, Inc

Leyton01

05-21-06, 08:35 AM

Then why are media-gate making us pay $10 for "licensing"? That was supposed to be going to Ximeta to pay for the technology.

markusx

05-22-06, 05:24 PM

Then why are media-gate making us pay $10 for "licensing"? That was supposed to be going to Ximeta to pay for the technology.

I agree, doesn't make sense. Someone is pocketing the $$$. I actually paid US$20. Maybe there is no licensing fee to begin with? :D

Markusx

bendandthrow

05-28-06, 05:45 PM

Musket

05-29-06, 09:05 AM

I've just spent most of the day reading this entire thread, and very interesting reading it has been.

My primary interest in this system is to play photos and mp3's on my TV without having to have my laptop turned on, and to be able to control it with my Harmony 885 universal remote. I like the idea of storing my home video or other ripped video content on it for easy TV playback, but this is a secondary requirement.

Having read the numerous comments about how the system is more geared to video playback than music or photos, do you think this is the best system for me to buy? If not, any suggestions?

My other system requirement is that, having put all my key data (including my mp3s and photos) onto the MG-35 I want it to be both available to other network users and to be part of a RAID configuration to allow automatic and continuous backing up to another disk.

I think the network availability requirement is OK, but I have no idea whether the RAID idea is viable. Any comments?

Thanks

I use a harmony remote with this unit and it actually works better than the supplied remote which is kinda funny. I find it ok for photos and mp3 - but like others I mainly use it for video, followed by mp3s then lastly photos. I really like this device and use it a lot.

As for the network feature, playing music/videos/photos stored on other computers on your network works quite well BUT using this unit as network attached storage is not recommended. Particularly if you want to put stuff ON to the MG35 through the network. It works but it is extremely slow. Its only good when connected by usb. Taking stuff off it - from other computers - is not so bad.

Is it the best device for you. Possibly not from what you say. But the best devices for network attached backup/storage are much more expensive than this device. Check out the thread on the Infrant Ready Nas NV device a few posts below this one on this forum. That device plus an MG35 would be perfect for you (and me too!), but its hard to justify spending thatmuch for storage - plus i'd have to wire up the house with gigabit network. One day :)

lsco

05-30-06, 02:44 AM

I was in communication with a guy at AL Tech who explained that they were not able to release the source code, due to it being his companies policy, personally I think this is stupid since they make money on the sale of the unit. Therefore if other people wrote good software for it they would make more money.
...
Anyway my background is in software engineering and currently I work on embedded software so I'm happy to work on this from time to time, but at this point I have hit a brick wall. Not really intersted in flashing my mediagate without a backup method I know works.

You should find that the serial connector is a standard JTAG interface. You should be able to find a bit of information here hri d0t sourceforge d0t net slash tools slash jtag_faq_org d0t h t m l

One thing to keep in mind is that JTAG is usually 3.3V not 5V.

I haven't done anything like this but this information comes from someone who has :D

bendandthrow

05-30-06, 07:37 AM

Musket

05-30-06, 09:40 AM

Thanks Musket

I am still tempted by this unit, but am so new to the subject I think I need to do some more research before jumping in. I also need to write down and prioritise my whole system requirements as at present they keep changing everytime I find a new piece of kit. I'd never heard of media serving/streaming until I started looking for a suitable backup device, and now that has become my primary requirement (I think :rolleyes: )

For starters, as far as the media player is concerned the interface must be user (ie wife) friendly and the box itself must "fit" in with my other components. Comments in this thread suggest the MG-35's interface leaves a lot to be desired in terms of appearance, but is it easy and intuitive? Also, can this unit come in silver?

If you are looking at using a harmony remote, it makes it very easy - just create an activity called Use MediaPlayer, which makes it one press to get everything switched on and bring you in to the menu. Then you just pick music, movies or photos from the menu and browse the folders. click on the one you want to play.

The front of my unit is silver and the sides are black. I dont think it comes any other way. I must say it is a very small tidy unit - barely bigger than the hard drive inside it. For its price point, its a good unit, particularly if you are interested in storing media in the player as well as streaming it from other computers in your house. If not you may also want to look at the new Dlink unit ( http://www.dlink.com/products/?sec=1&pid=438 )

I think we'll see a lot of new/better media players in 2007 when devices built on intel's new viiv technology start to pick up speed. These will be more like a full mini-computer though - and so priced accordingly. I fully expect my MG35 to be gathering dust within 1 to 2 years, replaced by something else. Until then it does the job nicely.

bendandthrow

05-30-06, 02:58 PM

Musket

I'm still favouring this kind of vertical unit as it fits my set up better, and I like the price and versatility/portability over the D-link type units. A few questions about the MG-35 if you don't mind...

I have all my audio media saved under genres as follows: Pop Music, Classical Music, Audio Books. Does the MG-35 support genres like this?

If yes, and having chosen the pop music genre, would I be able to easily select random play of all in that genre? If it is not easy to quickly access the pop music genre my wife will not like it. The ability to randomly play all tracks in the pop music genre is important to me.

Even better could I get my Harmony to go to the Pop Music genre directly by adding a few key presses to the Media Player activity? ie create an activity "Play
Pop Music"?

Once playing a music track is it easy to rewind or skip to another track? I have heard the FF and RW buttons are unreliable.

With photos, if I want to display a slide show of all photos in a folder do I simply select that folder and press play (or similar)? If yes then presumably I can create my own slideshows off line and put them into one folder for easy playback on TV. Presumably I can pause the slideshow and rewind?

Thanks

Thomas J. Coyle

05-30-06, 07:07 PM

Hi all,

Since I have decided to go the XBMC route instead of the MG-35 because of the GUI's poor WAF (at least for my wife), I have two very low milage MG-35s with the latest firmware (v 1.4.4) that I will let go for $100 each plus exact shipping.

These units have no hard drives, of course, but have been used only in an adult, non-smoking environment and have never been transported out of my house.

If anyone is interested in either or both of these two units, please PM me and I will respond promptly. Otherwise these two units will be put on eBay shortly.

Regards,
TCIII

Musket

05-31-06, 08:41 AM

Hey Benandthrow, no the MG35 doesn't really work like that with music genres. You just browse folders and click on files to play a song or folders to play all the songs in that folder. Guess you could organise folders by genre. But yes you can shuffle tracks.

Skipping songs and rewinding works fine with my harmony remote.

As for photos and slideshows, it works exactly as you say, so yes you can do all of that. Also, if you create a top level folder called "music", then the unit plays the tracks in that folder as background music whenever you play a slideshow.

demusss

05-31-06, 07:35 PM

bendandthrow

06-01-06, 06:30 AM

Musket

06-01-06, 10:22 AM

Thanks again Musket

This is my first foray into media streaming and the MG-35, whilst not perfect for my needs, is relatively cheap. So I may just take a chance on it. I suspect that over the next 2-3 years (my planning horizon for getting a HD LCD screen) these players will improve and get cheaper still, so I am prepared to go with a cheaper option for now.

One other question: I have just ordered a Maxtor Shared NAS HDD. I intend to use it as my primary network data store (media and other data). If I get the MG-35 could I fit a HDD and use it for backups? ie Would I be able to schedule backups from the Maxtor to the HDD in the MG-35? Would this have to be via the ethernet connection or USB? Would having non media files on the MG-35's HDD cause any problems or complicate the User Interface on the TV?

Eric

No probs. The MG35 does fall short in a few areas, but at its price its not bad. Right now there is no one device that does everything I want. The closest I could get would be to build my own full scale media centre PC. That would cost many times the price of the MG35.

TO answer your question - it would work fine as a backup device plugged in by USB. If you use an ethernet connection, that would work too but can be painfully slow transferring files on to the MG35. The non-media files don't mess anything up - they simply dont show up on your TV screen in the MG35's interface.

Musket

06-01-06, 10:28 AM

following on from bendandthrows question

Is it possible to organise music into directories and sub directories?
Something like this

-- My Music
|-- Pop
| | |-- Pop Album 1
| | | |--- Track1
| | | |--- Track2
| | |-- Pop Album 2
| | | |--- Track1
| | | |--- Track2
| |-- Rock
| | |-- Rock Album 1
| | | |--- Track1
| | | |--- Track2
| | |-- Rock Album 2
| | | |--- Track1
| | | |--- Track2
| | |-- Rock Album 3
| | | |--- Track1
| | | |--- Track2

And then is it possible to select to play either, one whole album, All Pop albums, All of Rock Album 1 & 3, All My Music, and also to randomise the order of playback of the four options?

Also another little question, how slow is it to transfer over the network onto the internal HDD using NDAS? How long would it take to transfer a file of 100MB?

Thanks
demusss

Demusss - i'm not near my MG35 tonight - but yes I believe you can do that.

As for the transfer speed - I don't know exactly but its very slow going on to the MG35. I should add that I use a wireless connection (MG35 to Wireless bridge that then connects to my wireless network). This shouldnt make much difference to speed, but perhaps it does have some impact.

ecove

06-17-06, 08:34 AM

Frenik

06-17-06, 11:20 AM

The MG-35 can't play HD media files. It can only upscale SD files to HD output.

ecove

06-17-06, 01:28 PM

Thanks for responding, Frenik. I didn't realize the MG-35 wouldn't play HD files - goes to show you my ignorance (I assumed since it mentions HD resolutions in the specs that it would play HD files). So should I give up on the component out issue (that it's blue)? Will it make any difference using SD files retween RCA and component? Any what, exactly, is the use/need for the HD Video settings in the box?

Frenik

06-17-06, 07:29 PM

The MG-350HD uses a newer chipset that is HD capable.

I'd still use component for SD if available as you can still get a better picture out of component, or even s-video.

As for the blue issue, from memory, you can use composite (RCA) or s-video without any change to the settings, but component requires a change in the setup. I think you can also press the Video button on your remote to cycle through the modes.

LKupersmith

06-17-06, 07:44 PM

Maybe someone here can help? I just received my MG-35, and am trying to view HD using it. I'm certainly no expert on any of this stuff, so please bear with me. I have the MG-35 hooked up to an old Panasonic HDTV (PT-53WX53). The audio through my receiver via coaxial is fine. Using the standard yellow RCA for video is fine, but I'd like to view some HD content. So I used a component cable (tried 2 different ones), and image is blue, and blurry for SD video. And when I tried an HD movie (Xvid, 960x544), I saw nothing (still could hear audio though). Can I assume, for one, that I should have he MG-35 configured to "HD Component Out on 1080i? Could there be some problem with the component out from the MG-35 that it's not registering the red or green? I know the TV Component in works fine with other sources. Any help would be welcome.

Like Frenek said, the MG-35 won't play files in HD. However, that aside, you should still have an image on your Panasonic using the component outputs and it should be a lot better than the composite (yellow) RCA cable. My old Panasonic HD PT-56WF90? set didn't like the MG-35's 1080i output even though other sources at 1080i worked well. I set my MG-35 to 480P for the Panasonic and it worked great. Doesn't matter that it's only 480P since the MG-35 only scales up the output to 1080i anyway. In addition to using the setup screen, you can also simply press the Video button on the remote while at the main menu to change from one mode to the next to see what works best with your set. You probably will find modes that do not sync at all with the old Panny.

mackcomm

06-18-06, 12:42 PM

We are a computer company who sells MG-35's.
The NDAS Licence Key does not ship with the unit, and is a seperate purchase.
All we require for the keys is your MAC address of your MG-35.
We are currently selling these UNIQUE LICENCES for $15.00 AUSTRALIAN
More information can be found on our E-Commerce Website.

Regards
Mackinder Computers
Mackcomm Net

ecove

06-18-06, 01:28 PM

Thanks for all the suggestions. Ouch! The MG-350HD looks good - could have used both the DVI and HD capability. Wish I had done a little more DD before buying the MG-35.

dcoleman

06-19-06, 04:22 AM

mackcomm:
I struggle with the ethics of continuing to sell a licence for a software package, that the manufacturer (Ximeta) do not support on the MG-35, especially as the licence is available for free from Freecom who supply the badged version I have.

adi999999999

06-19-06, 02:15 PM

dcoleman:

You were lucky with Freecom! when I asked them for a licence a few months ago they refused to believe the MG-35 had NDAS capability!! so I had to pay for a licence from PC4USA ,which cost me $20.I'll never buy another Freecom product again.

Sommer3

06-25-06, 09:27 PM

Hello all,

Have Mediagate 35, but tend to agree with TCIII that WAF factor is a bit "weak" (trying to select the proper *.ifo or vob file from a list in the days of gui's and pics... hmm). Anybody had any luck with a better interface, a la XBMC or at least Named movie (listed), selected, started w/o having to drop to the VOB sub-directories and select the proper file?

Dave

dcoleman

06-26-06, 03:49 AM

Sommer3,
MG-35 plays .iso files fine, so just wrap up all the .vob, .ifo etc. into a .iso (e.g. with Folder2Iso, or Nero) and that should improve the WAF factor.

gjagga

06-26-06, 10:27 AM

Today I have received the Mediagate 35. It’s working fine without any problem. Now I am trying to connect through LINKSYS WET54G wireless bridge I am unable to connect to that.
When I use direct network cable it works fine. It’s recognizing the mediagate and I am able to mount the mediagate drive.
When I connect through LINKSYS WET54G wireless bridge I am unable to connect to that.
My network doesn’t recognize the Mediagate. I have installed NDAS software. I applied the registration key. Everything works fine.
I have unable to connect Wireless WET54G through mediagate.
I have enabled the DHCP server “ON”.
I have enabled the NDAS “ON”.
Anything I am missing here?
When I connect WET54G through my computer it works fine. I have configured WET54G.
Please let me know how to solve this issue and let me know how to connect mediagate through WET54G?

markoz

06-27-06, 08:13 AM

The EM8510 is pre-programmed with the decoding algorithims used, here's the chip used:

...url removed as I cant post them yet! ...

You can't "add" any new decoding.

yes this maybe true but couldnt you build a "codec's codec"?? By that I mean, an intermediate codec that would present the chip with a format it can handle?

Just a thought.

Regards

Mark

malore82

06-27-06, 06:56 PM

You need to configure samba to accept anonymous guests.

You should use an entry like

[Movies]
path = /Volumes/Movies
public = yes
read only = yes
only guest = yes

In the global section you may need

auth methods = guest opendirectory
guest account = nobody

The samba daemon (or the host) may have to be restarted in order to
take effect.

I'm attempting to use 10.4 as my file server and was wondering if anyone else has gotten it to work and/or could elaborate on the said process above. I know the MG-35 works via the Network because I can get it to access a shared volume with XP S2 -- but am having no luck with OS X. Of course, the provided documentation is completely mum on the issue.

geoffreyhan

06-28-06, 09:12 AM

NEW FIRMWARE 1.4.5 IS AVAILABLE.

Just checked the Korean website, 1.4.5 was released on 14/06. Don't know what improvement has been made in the new firmware as don't undertand Korean.

http://www.mediagate.co.kr/atboard_view.php?class1=cs&class2=swfw&uid=371

Look forward to the English version.

Leyton01

06-28-06, 09:30 AM

from Google translator:

They are MG-35 v1.4.5 Firmware.

v1.4.5 Firmware important improvement facts with afterwords are same.

** important improvement facts **

1) 1.4.4 [pe] [cyen] from it amended the problem where DTS cuts from DVD Manager.

2) it controlled the memory ocean which is allocated to a slide show remaking hour photograph file.

The substitution and background music [khwel] the case flesh pair where the [li] mote will be high is a possibility the condition which bounces appearing.

3) it amended the external internal bug.

Application model: MG-35

Jo @ Anyware

06-29-06, 02:25 AM

Hi all,

I work for Anyware Computer Accessories, the distributor of the AL Tech Mediagate MG35, MG25 and the new MG350HD in Australia and NZ. I can see that some of you are eagerly awaiting the arrival of the wireless Mediagate. I would like to confirm with you all that we are expecting stock of the new wireless Mediagate to arrive in Australia in early August. The product will be available for purchase from our resellers around Australia and NZ. If you're unsure about your local Anyware reseller you can always call us ( 1300 ANYWARE: 1300 269 927) or visit our website for further information.

As a special promo for you forum readers we'd like to offer you two special gifts if you purchase either the MG35 or the new MG350HD. All you need to do is send your proof of purchase along with your name, address and phone number to:

AVS Forum Mediagate Promo
P.O. Box 9241
Scoresby, VIC 3179

...and we'll send you a FREE AL Tech wireless optical mouse and a USB massage ball to say "thank you".

Regards, Jo @ Anyware Melbourne.

teddystacker

06-29-06, 10:28 AM

@Jo @ Anyware

Thanks for the offer,but I think that VERY few MG35 owners will upgrade to a MG350HD , mostly due to the VERY poor firmware support offered by AL Tech .As you,and many of us here know ,the MG35 has many issues that could be addressed,which would turn it into a truly great unit,but is seems that like many far East producers, AL Tech are not really interested in developing the firmware to any great degree - Thus pleasing the people that have supported them by buying the unit in the first place.

Please could you pass this onto them if you get a chance?

BTW , Do you have any release info on the English 1.4.5?? - I bet not?

gunrunnerjohn

06-29-06, 10:49 AM

I agree, I have the MG35, and if that's the level of support to be provided from this company, I'll never own or recommend any more of their stuff. There are lots of fish in the sea, and AI-Tech obviously never attended Marketing-101.

It takes years to build a reputation, and minutes to destroy one.

They've done serious damage to their reputation.

batman1056

06-29-06, 06:11 PM

Just bought my medai player, and foudn with verion 1.4.4 when I played my pictures the music only played for 10 seconds then cut off.

I downloaded the latest firmware and flahsd the device - now it says 1.4.3 - so I've gon backwards - fixed the pictures/music problem - but MAJOR out of sync on moveis - where can I get a newer firmware?

batman1056

06-29-06, 06:14 PM

NEW FIRMWARE 1.4.5 IS AVAILABLE.

can this be used on the English model - and if so will their be any problems?

Bytre

06-29-06, 06:43 PM

@Jo @ Anyware

Thanks for the offer,but I think that VERY few MG35 owners will upgrade to a MG350HD , mostly due to the VERY poor firmware support offered by AL Tech .

My reaction isn't quite as strong, but the sentiment is the same. I will look for other solutions before a Mediagate because of issues with support and maintenance releases.

gunrunnerjohn

06-29-06, 06:53 PM

I have a mirror for several releases. http://mediagate.will-enterprises.com/

gunrunnerjohn

06-29-06, 07:06 PM

can this be used on the English model - and if so will their be any problems?You mean besides the menus and text being in Korean? I think that's probably enough problem that I'll pass it by. :rolleyes:

Thomas J. Coyle

06-29-06, 08:00 PM

batman1056,

I never had an audio/video sync problem with 1.4.3 or with 1.4.4.

I believe that 1.4.4 is the latest English release.

Regards,
TCIII

Jo @ Anyware

06-29-06, 08:04 PM

@Jo @ Anyware
BTW , Do you have any release info on the English 1.4.5?? - I bet not?

The latest firmware upgrade on the AL Tech website for the MG35 is 1.4.4 with or without NDAS. I don't know where you've heard about 1.4.5 from as it doesn't exist. Make sure that when you visit the website that you're going to the english section and not the Korean section.

Jo @ Anyware

06-29-06, 08:06 PM

You mean besides the menus and text being in Korean? I think that's probably enough problem that I'll pass it by. :rolleyes:

The menus and text will only be in Korean if you're using the Korean updates. Make sure you visit the english section of the AL Tech website. :rolleyes:

Jo @ Anyware

06-29-06, 08:07 PM

batman1056,

I never had an audio/video sync problem with 1.4.3 or with 1.4.4.

I believe that 1.4.4 is the latest English release.

Regards,
TCIII

Good to hear mate! Sounds like you know what you're doing! ;)

gunrunnerjohn

06-29-06, 08:12 PM

The menus and text will only be in Korean if you're using the Korean updates. Make sure you visit the english section of the AL Tech website. :rolleyes:No kidding brainiac, and the latest version there is 1.4.4. :rolleyes:

Jo @ Anyware

06-29-06, 08:33 PM

I'm really not getting your point. I've already stated that the latest firmware upgrade available is 1.4.4. I was merely responding to your comment regarding menus and text being in Korean. Clearly that would not be the case if you were visiting the english version of the AL Tech website. Please clarify.

gunrunnerjohn

06-29-06, 08:38 PM

What's to clarify? Someone asked about the downside of installing 1.4.5, and I responded. Then you came with a sarcastic comment, and I replied in kind. Is that clear enough? Did you disagree with my conclusion about 1.4.5, if so, how?

teddystacker

06-29-06, 09:26 PM

The latest firmware upgrade on the AL Tech website for the MG35 is 1.4.4 with or without NDAS. I don't know where you've heard about 1.4.5 from as it doesn't exist. Make sure that when you visit the website that you're going to the english section and not the Korean section.

@Jo @ Anyware

I heard about it on this VERY forum - I presumed (incorrectly it looks like) that being as you are a main Distro for the MG-35 , you would be "up to speed" on when firmware updates are coming (be it English or otherwise) - as I am sure you want to give the best support you can to the customers that have brought from you??
I presumed you were in regular touch with the maker of the MG35 - if you take a few mins to read these forums,you will see many,many users are looking for firmware issues to be addressed,any chance you could make AL Tech aware of this?? - I am sure it will help your long term sales and "repeat" business,something we all need badly?

The only way these issues are ever going to be addressed,is by people like yourselves putting pressure on AL Tech ,as they just don't want to listen yo us humble buyers,sadly...

batman1056

06-30-06, 06:23 AM

when they are creating new firmware would it be possible to have a default folder so when you choose Video for example - it opens the folder called video and not show all the folders on the HD.

This would be a nice little touch and am sure it would not be too hard to sort out.

As for the 1.4.4 firmware - has anybody noticed when playing back pics the music file which is loaded in (from music folder) stops after 12 secs - but on pervious firmware no problem.!

Also another nice thing would be to speed up the reponse on the remote!!.

last one - is it possible to choose the music track that is played when viewing pics?

chears :D

gunrunnerjohn

06-30-06, 07:33 AM

FWIW, I run 1.4.4, and the music doesn't stop when I playback pictures.

pbarrette

06-30-06, 06:26 PM

Hi All,

I've been browsing these forums for a long time now and it has always been very helpful. I have never registered or posted here before since I have never had anything that was particularly useful to add.

Until now..

I saw the Freecom Network Media Player in a local store and had been eyeing it for a while as a replacement for my Hauppage MediaMVP. The MVP was a serious disappointment even after the 3rd party firmware upgrades and server software.

After doing some research, I broke down and bought the MG-35 clone other day. Part of my decision to get the Freecom was due to the fact that they provide the NDAS key for free. While it is a vast improvement over the MVP, I immediately decided that the firmware could do with some serious improvement.

On that note, I've done some digging.

The Mediagate firmware seems to be divided into at least 3 parts:
1 - The Jasper bootloader (may contain more subsections)
2 - The linux kernel image.
3 - The linux filesystem.

Separating the firmware into these parts is fairly simple. You just need to locate the header signatures for each section and split the file at those boundaries.

The first boundary is the linux kernel image. The kernel is compressed with Gzip, so the signature is:
1F 8B 08

The second boundary is the CramFS filesystem. A CramFS filesystem begins with the following bytes:
45 3D CD 28 00

So grab your favorite hex editor and do a search for these byte blocks. Everything before the first signature is the bootloader. Everything including, and after the second signature is the CramFS filesystem. Everything in between is the gzipped linux kernel.

The linux kernel can be renamed to ".gz" and unzipped with your favorite unzip software. I use WinRAR, but to each their own.

The cramfs filesystem can be mounted in linux using:
>mount -t cramfs -o loop cramfs.img /mnt/wfb

If you lack a linux box to test on (like me), there are 2 options that I know of:
1 - WRT54G CramFS Editor - (aka FSExtractor at sourceforge)
2 - "cramfsck.exe" from cygwin

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

Once you have extracted the cramfs filesystem, there are a few interesting things to take a look at:
1 - ndemu.o and lpx.o

These kernel mode drivers were added with 1.4.3 and remain unchanged in 1.4.4.
ndemu.o is the NDAS disk access and encryption driver. It probably contains the code used to generate the device ID and write key. Since there is no NDAS chip in the MG-35, everything is emulated. This driver is the core NDAS component. lpx.o is the network protocol driver for NDAS. It apparently encapsulates the data and sends it over the network.

2 - /etc/sashrc

This file apparently starts the main menu interface "dvdplayer.bin". It may be possible to compile our own programs and run them from here.

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

Basically, I know nothing about programming for ARM compatible devices. Also, my knowledge of linux is limited since my day job deals almost exclusively with MS OS's.

I didn't see this information anywhere else in this thread, nor in searching the forums. Hopefully this will be useful to someone.

pb

teddystacker

06-30-06, 08:56 PM

@pbarrette

Welcome and thanks for a really great First post...

I myself, am not a programmer either - but at least the info you have provided in your post **MAY** be helpful to someone that is,and one day hopefully,we may see a "modded" firmware,that will address some of the many issues the MG35 has...

Thanks again....

batman1056

07-01-06, 04:12 AM

batman1056

07-01-06, 04:17 AM

my freecom has just died on me :( will not connect to PC or laptop vai USB. Only had it 3 days
I am now sending this back - does anybody know of a better product?

batman1056

07-01-06, 04:22 AM

last post for today - can somebody tell me what the NDAS is all about

pbarrette

07-02-06, 06:41 AM

Hi Batman1056,

1 - Did you unzip the firmware? It must have a ".update" extension. The Freecom and the AlTech are identical systems. The difference is that the Freecom has their logo on the images contained in the firmware.

2 - Does it still work otherwise? The USB-Drive functionality is not self powered. You know that you must have the power adaptor plugged into the device if you want to connect it to the computer via USB right?

3 - NDAS is "Network Device Attached Storage" while NAS is "Network Attached Storage". The difference is that a NAS device generally uses common network protocols such as Samba (SMB or Windows Networking) or NFS (Unix's Network File System) to act as a fileserver on the network.

NDAS is different. It has its own low level protocol called LPX (Light Packet eXchange?) which is used instead of TCP/IP+SMB/NFS. To use it, you must install a device driver on your PC which can communicate with the NDAS device. The difference is that when attached, the NDAS device appears to your PC as if it was connected physically as opposed to being a network share.

The problems with NDAS are as follows:
--------------------------------------------------------------
1 - NDAS requires the PC to know the "Device ID" of the device you want to use before the PC driver can find it. Normal NDAS devices have this number printed on the device itself. The MG-35 wasn't originally intended to be an NDAS device, so the Device ID is not printed on it.

2 - After attaching the NDAS device on the PC, you must have a "Write Key" registered in order to have write permission to the device. Again, the Write Key is normally printed on the device, but is not on the MG-35.

3 - Because the NDAS "Device ID" and "Write Key" aren't printed on the MG-35, you cannot register the device in the NDAS PC software. Without registering the device, you can't copy files from your PC to the MG-35 over the network. Ximeta refuses to provide these numbers directly, so you must go through the dealer or manufacturer to get them. AL-Tech will not give them out. They refer you to the dealer instead. The dealers all want you to pay for the ID and write key, even though the NDAS technology is already licensed from Ximeta.

Freecom is the exception. If you have a Freecom MG-35 clone, you can email their support with your serial number and MAC address and they will email you back with the DeviceID and Write Key at no charge. This is one of the main reasons I got the Freecom.

4 - Because NDAS uses its own Network Layer (Layer 2) protocol, it is not routable. An NDAS device can only talk to other systems via MAC address. This means that some home network configurations won't work with NDAS.

For instance, my home network looks like this:
[DSL Modem]--[WRT54G-1]--[My Computer]
: :
[MG-35]--[WRT54G-2] [Wife's Computer]

The WRT54G-2 was connected as a wireless client of the WRT54G-1 using the "Client Bridging Mode" of the DD-WRT firmware. This mode works fine for streaming content off my PC to the MG-35 using the Windows Filesharing features of the device. However, in Client Bridging Mode, the MAC address of the MG-35 is replaced with the MAC address of the WRT54G-2 when the packets leave my computer. So my computer thinks the MG-35's IP address belongs to the WRT54G-2 device, and it also thinks that it is serving the content to the WRT54G-2.

In reality, the packets that the WRT54G-2 recieves also contain the IP of the MG-35. So the client router (WRT54G-2) knows to send that data to the MG-35. The upshot is that the MG-35 thinks it's getting the file directly from the client router, and my PC thinks it's serving the content directly to the client router. The WRT54G-2 is actually performing a kind of MAC Address Translation to keep the subnet devices (the MG-35) in the same IP space.

NDAS bypasses the TCP/IP protocol entirely and relies on the MAC address + Device-ID to indentify and talk to the device. Because the WRT54G-2 is altering the MAC address, NDAS doesn't work across the wireless link.

To make it work across the wireless link, I needed to configure WDS (Wireless Distribution System) on both routers. This avoids the MAC translation and allows the PC to see the MG-35's MAC address, enabling NDAS to function correctly. Unfortunately, WDS also cuts the wireless transfer rate in half.

5 - Normally, NDAS is implemented in hardware via a chip manufactured by Ximeta. The hardware implementation allows very fast file transfers since the chip handles the network packets. The chip also talks directly to the disk, bypassing the OS and increasing read/write speeds to the disk.

On the MG-35, however, the NDAS functionality is emulated through software via a device driver licensed from Ximeta. The use of software emulation on the slow processor of the MG-35 means that NDAS network transfers are slow. The need to emulate the network functions via software also means that the direct disk access is lost, negating both of the performance gains of the NDAS chip and decreasing performance.

After some sloppy disassembly of the "ndemu.o" driver, it also appears that the LPX packets are encrypted over the network. This means that the NDAS driver on the MG-35 needs to decrypt all inbound packets and encrypt all outbound packets. Again, this is all being done with the relatively slow processor of the MG-35, so performance takes another hit.

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

So, while this wasn't the short reply that you were probably expecting, it should answer all your questions regarding NDAS.

pb

batman1056

07-02-06, 12:16 PM

Ermmm WOW! thanks

ecove

07-02-06, 01:47 PM

Maybe someone here can help? I'm having sound synchronization issues with some avi's on my MG-35 (played locally off the hard drive I put in). Others work fine. Sometimes, turning the MG-35 off and on fixes the problem. Other times the avi starts off in synch then goes out of synch over time. They all run fine on my PC. Could it be the hard drive I'm using? It's an older 80GB IBM, not sure of the speed. Thanks for any suggestions.

batman1056

07-02-06, 01:51 PM

I had the same problem, I read somewhere about using AutoGordianK to re-encode the problem avi's to a verions that is more compatable with the system.

I had the same problem, half way through a movie - its goes out of sinc -- can not test the above software as my HD in my freecom has died (might have something to do with being dropped!) - sending it back for replacement - once I have it I'll test the software

Leyton01

07-03-06, 09:34 AM

not really a permanent fix but someone mentioned that hitting 0 on the remote may re-sync some videos. Someone test and confirm?

This was mentioned in the undocumented features thread that also pointed out that 7 skips back a bit and 9 skips forward a bit :)

Frenik

07-03-06, 12:17 PM

And to follow up... I checked and 7 and 9 jumps back and forward by 10 secs ;)

pbarrette

07-04-06, 04:13 AM

Hi all,

I've been doing some more digging into the Mediagate..

I'll start off with a list of the major components:

1x Sigma Dev - EM8511-Rev.A - Digital media processor with MPEG-2/4 and DVD decoding.
2x Samsung - K8D1716UTC - 16mbit Flash memory module. (32mbit total = 4MB flash space).
2x Samsung - K4S641632H-TC60 - 8MB 166mHz SDRAM module. (16MB total).
1x Hynix - HY57V643220DT-6 - 8MB 166mHz SDRAM module.
1x Wolfson - WM8728S - 192kHz Stereo DAC.
1x Davicom - DM900E - 10/100 Ethernet Controller.
1x Altera - EPM3032A - CMOS based EEPROM with JTAG-ICD support.
1x Prolific - PL-2507 - USB2.0 to IDE bridge controller.

So.. We appear to have ~4MB of space in the flash memory to play with. That space needs to contain the bootloader, the gzipped linux kernel and the cramfs filesystem. The kernel and filesystem are probably being extracted to the 16MB of sdram each time the MG-35 boots up. Saves on flash space that way.

We've also got a 8MB hynix SDRAM chip in there. My guess is that it's being used by the EM8511 for audio-video buffering and the like. But who knows..

The excellent sound you hear from the analog audio connectors comes from the Wolfson DAC. I'm a bit suprised by this, since the Wolfson stuff is supposed to be pretty high quality.

Next up is the Davicom ethernet controller. Nothing astounding here. Apparently it's used quite a bit in embedded network devices and has stable uClinux drivers.

The Altera EEPROM sits real close to the DM9000, which is likely no mistake. The Davicom design guides state that "best practices" are to use an EEPROM for storing the MAC address, Wake on Lan, etc. So this chip is probably used for those purposes. The USB controller's design guides also state that a serial EEPROM should be used for VendorID, ProductID and firmware updates. So this chip may be serving a dual purpose.

Finally, we have the Prolific USB controller. Basic USB to IDE bridge like you'd find in any external USB drive enclosure. I haven't looked at this one enough to determine if it could be turned around into a USB host, but initially I'd have to say it's very unlikely.

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

Now, there are two interesting connectors on the board. The first is near the drive power connector and is marked "J9". It's a 10 pin header just waiting for the right cable to be plugged into it. The question is: Does it take a JTAG cable or a serial cable?

My guess is that it's a serial terminal. Some bits in the bootloader look like it starts up a serial terminal with a small menu system and can upload or dump firmware over the serial port via YMODEM. Unless someone else wants to take a look, I guess I'll have to pull out the multimeter at some point and find the right pinouts.

The next connector is another 10 pin beast at "J7". This one doesn't have a nice, presoldered pin header for us to plug into. However, this one is too close to the Altera EEPROM to mistake. It's extremely likely that J7 is a JTAG interface used to program the EEPROM at the factory. Did I mention that the Altera supports a standard JTAG interface and has in-circuit-debugging capabilities? This could be an interesting one to play with, if for no other reason than to fiddle with the MAC address and play with NDAS Device ID's.

Anyway.. Hopefully this info will be useful.

I've been srounging around in the bootloaders for the different firmware versions, and have a bit of useful info there that I'll make a post about tomorrow.

Thanks for listening.

pb

pbarrette

07-04-06, 08:35 PM

Hi again,

Ok, I don't really have time for an in-depth post right now, so I'll just show you what I've got..

Firmware versions 1.4.3 (Freecom), 1.4.4 (eng) and 1.4.5 (kor) all have bootloaders of identical size. This makes them perfect targets for finding the differences between them.

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

As it turns out, there are very few differences between these bootloaders, and many of the differences can be ruled out as significant.

0x00000008: 03 04 01 - From v1.4.3 firmware
0x00000008: 04 04 01 - From both v1.4.4 firmwares
0x00000008: 05 04 01 - From v1.4.5 firmware

So we can see that the bootloader header contains the firmware version number in little-endian order starting at 0x08.

A quick glance at the ASCII shows that 0x0000CC64 through 0x0000CC77 contain the bootloader build date and time.

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

Here's an interesting one
00010448: 09 68 2E (v1.4.3)

Change over to big-endian and we get 0x2E6809. Convert that to decimal and we get 3041289. The size of the gzipped linux image and the cramfs filesystem put together is 3041285 bytes.

The interesting thing is that the same locations across all three firmwares contain exactly the same kind of data. Namely, the exact size of the linux.gz and the cramfs put together, minus 4. Analysis of different firmware versions shows the same pattern.

So, if we create our own cramfs image with, say, ftpd built in.. We aren't restricted to the size of the cramfs image we're working from.

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

Many of the other differing locations can be considered irrelevent. Take this for example:
Loc 43 44 45 <-- FW ver
--------- -- -- --
00006444: 9C 9B 9B
00006599: 50 70 70

The differences here are probably irrelevent to our purposes. We can see that v1.4.3 may be different in some locations from v1.4.4, but most of the differing v1.4.4 data is the same in v1.4.5 and probably irrelevent. Especially since v1.4.3 and v1.4.4 have identical linux images while v1.4.5 has a different kernel.

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

When you ignore the segments like those above, and the segments that we figured out (like the FW version, date, etc), you are left with two sections of consecutive data, each 4 bytes long and at opposite ends of the file.

+---------+---+--+--+--+
|Address | 43|44|44|45|
|From File| en|en|kr|kr|
+---------+---+--+--+--+
|00000010:| 38|63|5E|91|
|00000011:| 50|6E|6A|85|
|00000012:| 38|75|45|81|
|00000013:| B1|B2|AD|AA|
+---------+---+--+--+--+
|00010440:| 60|C6|E3|26|
|00010441:| EC|BF|D3|03|
|00010442:| FE|C8|1E|D8|
|00010443:| 59|16|6C|00|
+---------+---+--+--+--+

These addresses seem to contain two separate 32bit checksums. So we have two likely possibilities here. The first possibility is that one of the blocks is the CRC of the entire firmware image and the other is a CRC of the linux+cramfs. The second theory is that the linux and cramfs have separate CRC's.

To anyone who knows ARM assembler well, I'd appreciate it if you could take a look at "/bin/upgrader" in the cramfs image since this is where the CRC's are being checked. If we can find the CRC check code, we can probably reverse it.

Basically, this CRC is probably the only thing standing between us and custom firmware images for the MG-35.

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

Of final interest, the MG-25 and the MG-350 all use the same firmware format of Bootloader+linux.gz+cramfs. So any hacking done for one will likely be extremely useful for all three.

pb

teddystacker

07-04-06, 08:49 PM

@pb

Thanks once again for your contunied efforts on this one,just the prospect of of a custom firmware is amazing and thanks to you,it might now be a stap closer..

Hope you manage to get others on board here , with this superb info...

gunrunnerjohn

07-05-06, 01:31 PM

WOW! A lot of work has gone on in a few days! I would imagine the CRC would be one of the standard algorithms, though it's impossible to be sure without actually checking the calculation and results.

FWIW, I suspect that the individual modules likely have their own CRC, at least that's the way I'd have designed it.

pbarrette

07-05-06, 07:23 PM

Hi Teddy, GRJohn,

Thanks for the words of encouragement. I've put in a lot of hours hunting through a hex editor searching for clues.

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

For the purposes of clarity, I need to define a few things:

1 - Most of my references come from the Freecom v1.4.3 firmware. I have 18 different firmware versions at the moment, so I really just needed to choose a reference, and this one is it. So, in the future, just assume I'm referencing this one if I don't explicitly state otherwise. :)

I chose this one because it's relatively recent, contains the same kernel and has the same size (but not identical) bootloader as ALTech's v1.4.4 and it has the same size (but again, not identical) bootloader as the ALTech v1.4.5-korean version.

2 - ALTech apparently has no idea how to standardize firmware image names, so I've done it for them. My standards are as follows:
MGXX(X)-123(x)-lan

Example 1: MG35-137b-kor = Mediagate-35 version 1.3.7 (beta) in Korean language.
Example 2: MG350-104-kor = Mediagate-350HD version 1.0.4 in Korean language.

You get the idea.. Like I said, I've got 18 different firmware images and the component linux kernels and cramfs filesystems have all been extracted into separate folders. So it's just easier to have a standardized naming convention to prevent confusion. If I reference MG35-143-eng, that's the Freecom version since ALTech doesn't have an English language v1.4.3 firmware available for download. If you have any questions about which version I'm referencing, just ask and I'll do my best to clear it up for you.

3 - Sub-part filenames.. Like I said before, the firmware is broken into at least 3 parts. The parts don't have any "real" assigned, internal names as far as I can tell. So to make things more simple, I've made up my own names for the sub-parts. I'll use these names from now on because they're easy to understand and it saves on typing.

Boot.rom - This is the section at the beginning of the file and contains the upgrade-image header, the firmware version, the CRC's and what looks like bootloader code. This part is the most important to us in figuring out how to implement custom firmware images.

Linux.gz - This is the second part of the file. It is a uClinux-2.4.17 kernel that has been compressed with gzip. It is not password protected and can be unzipped with any unzipping program that supports the gzip format (most all zip software). This section of the file runs all the way up to the last part of the file.

Cramfs.img - This is the last part of the file. It is a cramfs formatted file which contains the linux filesystem used by the MG-35. It can be extracted with "cramfsck.exe" from cygwin. Once the CRC problem is figured out, this is where we will start playing. It also contains the icons and background images, so converting the korean firmware images (with more features) into english/whatever, would start there.

4 - Virtually all of the hex code for the firmware is little-endian. For those who don't know what that means... It's basically backwards. When you are looking at the file in a hex editor, if you see something like this:
00010448: 09 68 2E

It means that the "00010448:" part is the hexadecimal offset in the file where "09 68 2E" begins. The "09" is at "0x010448", the "68" is found at "0x010449" and the byte "2E" is at location "0x01044A".

The "little-endian" format comes into play when trying to read these numbers. The CPU in the box is actually reading them backwards.. So "09 68 2E" is seen by the CPU as "2E 68 09". Incidentally, 0x2E6809 when converted to decimal is 3041289.. But I already explained this bit of code above.

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

Sorry for the long explanation about the conventions I use, but I just don't feel like figuring out a hundred different ways of saying "the gzipped linux kernel" when I could easily just say "linux.gz". Nor do I really want to explain "little-endian" all the time. :)

pb

pbarrette

07-05-06, 08:04 PM

Hello again,

Now that I've passed the 5 post mark, I should be able to add links.

I've put together a little toolkit (http://peterbarrette.com/MG35/MGFWExtract.zip) to help others dissect the Mediagate firmware images more easily.

The zip file contains the following:
cramfsck.exe - This is directly from the cygwin distribution.
gunzip.exe - Also from cygwin.
cygwin1.dll - Required for most cygwin apps
cygz.dll - Needed for gunzip.exe
MGSplit.exe - More on that below.
run.bat - Does it all for the lazy (like me).

MGSplit.exe - I got tired of splitting the firmware images by hunting for the section signatures with gsar and splitting out the files with dd, so I wrote my own utility to do it for me. This is a console application written in C# and, as such, requires the .NET v1.1 framework to run. Sorry, but I like C#.

It is a console app which will find the offsets to the linux.gz and cramfs.img, tell you what the offset is in hex format, then spit out 3 files called boot.rom, linux.gz and cramfs.img very quickly. It takes only 1 parameter: The name of the file to be searched and split. It works for me, but if you have problems, drop me a PM and I'll see what I can do to work them out.

If you want the source code, just let me know. It's ugly because I wrote it fast, but it works. I'll probably modify it in the future to take an additional parameter that will find and report the offsets, but not chop the file.

The "run.bat" file does the following:
1 - Creates a subdirectory for the firmware image file.
2 - Uses MGSplit to chop the file into 3 parts.
3 - Moves the parts into the project subdir.
4 - Unzips the linux kernel.
5 - Decompresses the cramfs.img into a subdir of the project subdir.

The batchfile leaves the original firmware unmodified. It also leaves the 3 component parts unmodified.

I encourage anyone interested in playing with the firmware to download the package and have a look around. Even if you don't have a clue what you are looking at, you can at least have a poke around. The more eyes we have looking, the more likely we will be to find something useful.

Also remember that while I put this package together for the purpose of exploring the MG-35 firmware, it also works against the MG-25 and MG-350 firmware images. So if you have the 25 or 350 and want to play with the firmware, all three devices have the same firmware format.

pb

ommm

07-05-06, 08:24 PM

OMG This is excellent thank you for all the work. I have NO idea about any of this or how to create the new firmware but its fantastic that someone that does know is having a look at it!

Much appreciated!

gunrunnerjohn

07-05-06, 08:53 PM

I think the most realistic project in my eyes would be to attempt a translation of the Korean software versions. I suspect that actually making significant modifications of the functionality without the source would be a tall order.

A stupid question. How do you initially extract the ROM image?

pbarrette

07-05-06, 10:17 PM

Hi gunrunnerjohn,

I agree. Translating the korean firmware is probably the first step.

I'm not sure what you mean exactly by "ROM image", so I'll just summarize the whole process.

1 - Open up the firmware image in a hex editor.
2 - Look for the bytes "1F 8B 08". All gzip files start with this set of bytes.
3 - Look for the bytes "45 3D CD 28 00". All CramFS images start with these bytes.

All data in the file before Step-2 is part of the file header and boot loader.
All data in the file starting at Step-2 up to Step-3 is the gzipped linux kernel.
All data starting at Step-3 to the end of the file is the CramFS image.

So.. The file looks like this:
XX ... XX 1F 8B 08 ... XX ... 45 3D CD 28 00 ... XX

The "XX" represents all the other hex bytes in the file.

While scanning through the firmware file, I saw the text "Compressed ROMFS". All CramFS files have this text near the beginning of the file, so I just hunted for the CramFS "magic word" (the byte sequence that signifies a CramFS file).

Other devices based on the EM85XX chipset use a RomFS filesystem with the gzipped linux kernel inside the romfs file. Since there wasn't a linux kernel in the cramfs file, I started hunting for the gzip signature.

Actually, I did a lot of hunting for other stuff before that.. But the process above is what ended up producing results.

pb

PS..

It occurred to me that you may have been asking how you could do it yourself as opposed to the process that led me to it.

The easiest way would be to download the tool kit I linked above and unzip it to its own directory. Then put a firmware image in that directory and go to the command line. At the command line just type:
run Firmware-Filename

teddystacker

07-06-06, 08:44 AM

Hi guys,

Why do we need to translate the KR Firmware? , does it have features that the English version does not?

If we are just taking about v 1.4.5 , I am sure that a "official" Englaish version wil be out soon...

Also,it might be a good idea as a start (once the crc thing is solved) to try and replace the GUI images with better ones.We already have someone at this forum that is papared todo the artwork for better ones.
Dont know how easy it will be for you top extract them from the Firmware , so he can have some idea of what size/colours etc he has to work with.But if that can be done I guess he can get to work on them - just a thought , as the poor gui seems to be one of the major gripes that people have about the MG35...

pbarrette

07-06-06, 10:25 AM

Hi Teddy,

The Korean firmware does seem to have features that the English version doesn't. Searching through the executables and the GUI images seems to indicate that, at the very least, it adds support for M3U playlists.

Extracting the GUI images is simple. Use the tool I linked above. Do a "run FirmImage" and have a look in the "FirmImage.DIR\CRAMFS\img" directory.

The background images are in JPG format while the GUI icons are in PNG. The PNGs are a little odd since they don't open at all in IrfanView but open fine in Photoshop. I haven't bothered trying to find the exact structure of the PNGs yet since the CRC problem is the most pressing.

Also, the Korean market seems to get the new features first. So if we do get v145-eng in the future, you can bet that the Korean market will be on v146-kor.

Personally, I think the best reason to mod the firmware would be to add FTP or SMB server capabilities. This way we could bypass the NDAS crap entirely and get our file transfers back to reasonable speeds.

pb

teddystacker

07-06-06, 10:57 AM

@PB,

Thanks for explaining it I did not realise that the KR firmware was so ahead - yes I can see your point then, esp with the M3u playlists..

Ok , ref the GUI , I have emailed Chris (Supertoast) who offered todo new artwork for icons , backgrounds etc - just in case he was not "up to speed on the latest developments , now you are working on the firmare..

Again , many thanks...

Teddy

kiddyl

07-06-06, 12:01 PM

I am new here, but I want to ask if someone can explain me how to make a firmware file again after I altered the logontsc.jpg for example. It would be nice to startup my player with my own custom design.

Just found out that its not possible now. Good luck with cracking the firmware and make this player better then it already is.

xlrate

07-06-06, 11:17 PM

Come on people lets all help pbarrette get our own modded firmware happening. The GUI really sux remember

I for one would to say thanks and it does look like were are getting closer. :D

I wish i was better with this kind of stuff too :(

pbarrette

07-07-06, 12:02 PM

Hi all,

So, not a whole lot to report today..

Looking at MG35-143-eng, I found the following:
00000018h: 20 04 01

I hadn't noticed this location before since it didn't show up in the firmware comparisons I'd been doing. If you look at the data: 0x010420, you might notice that it's very similar to the offset of the embedded Linux.gz file (0x010450).

In the firmwares MG35-143-eng, MG35-144-eng and MH35-145-kor the offset of Linux.gz is exactly the same, which is why it didn't turn up in my comparisons. However, a look at the other firmwares confirmed that this section has the same purpose in all versions of the firmware. It marks the start of the Linux.gz, which is how the firmware upgrader knows where to start looking for it in the file.

The thing is, 0x010420 != 0x010450. There's a 48 byte (0x30) difference there.

This tells me that the first 48 bytes of Boot.rom are not actually part of the device bootloader code. Instead, they seem to be a header designed for the "/bin/upgrader" program to read.

So the 0x30 byte difference means that the FW upgrade image header is always 0x30 bytes long, contains at least the FW version number and the address to the start of Linux.gz. The upgrader strips off the 0x30 byte header first, then the offset contained therein is correct.

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

So now we know how the FW upgrader knows where to find the start of the Linux.gz+Cramfs.img block of the file.

What we're missing is:
1 - How the upgrader knows the length of the Linux.gz block, or
2 - How it knows where to find the start of the Cramfs.img block.

Since those two blocks are not separated by any other data, knowing either #1 or #2 would be enough for the upgrader. Unfortunately, I haven't found any data in the Boot.rom section that would tell the upgrader either #1 or #2.

pb

pbarrette

07-07-06, 12:42 PM

Hello again,

In this post I want to talk about the CRC's..

First off, I'd like to say that I think they are CRC's, but I can't be entirely sure. At least one of the two code blocks is highly likely to be a CRC.

It doesn't appear to be one of the standard CRC's. I put together a little command line CRC calculator using the Classless.Hasher (http://www.classless.net/) library for .NET and I've been using it to check the files against 14 different 32bit, 5 different 16bit and 1 8bit CRC standards. None of the standard CRC checks produces anything that matches the 2 code blocks.

Gunrunnerjohn suggested that since there seem to be 2 CRC blocks in the Boot.rom, one is probably for the Linux.gz and one is probably for the Cramfs.img. I was thinking about that before he mentioned it and also believed that was the case.

But, taking another look, I realized that this can't be the case. In MG35-143-eng and MG35-144-eng, the Linux.gz section is exactly the same for both firmwares. Files that are exactly the same should produce exactly the same CRC unless they have been salted first. I doubt that ALTech is salting their CRC's since they don't appear to be using them for encryption, rather to verify that the firmware image was uploaded without errors.

It could be possible that one of the CRC's is for the unzipped kernel, but a gzipped file already contains an embedded CRC for each file in the gzip archive. Also, the CRC for the unzipped linux kernel doesn't match either of the values found in the Boot.rom section.

There's another thing that interests me. Earlier I mentioned a code block in Boot.rom which appears to contain the filesize of the Linux.gz+Cramfs.img pair. The interesting part is that the data in Boot.rom is always given as 4 bytes larger than the actual file size.

So that makes me wonder.. Is there a 4 byte "magic number" that is being added to the component sections before the CRC is computed? If so, are those magic bytes being added to the beginning of the Linux.gz+Cramfs.img, or in the middle or at the end.. Or is it 2 bytes added to Linux.gz and 2 bytes added to Cramfs.img?

Or are the 4 extra bytes just filler being put in because of the block size of the flash memory? The 4 "missing bytes" just being a way to align the firmware to the proper write size of the physical memory blocks.

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

So I'm pretty positive that at least one, if not both of the "unknown" values found in Boot.rom are a CRC.

The questions are:
1 - What exactly is being CRC'ed?
2 - Is it a standard CRC algorithm or a custom one?
3 - Is there a "magic byte block" being added before the CRC is computed, and if so, what are those bytes and where do they go?

If anyone is interested in my command line CRC checker and the source code to it, just let me know and I'll upload it. It's actually a very simple program done in C# and it's commented decently. The Classless.Hasher assembly makes it very easy to code.

Also, if anyone has any ideas on figuring this out.. Please, please let me know. I'm nearly out of ideas at this point.

pb

pbarrette

07-07-06, 06:18 PM

Hi again,

Three posts in a row.. Ok, so the first two were back to back and separated for clarity..

Well this new one is about my post #887 (two posts up). I've discovered how the MG35 knows the length of the Linux.gz block. The way they are doing it doesn't make a whole lot of sense to me, but maybe it's because I don't really know much about flashing to embedded devices at the low level.

Lets have a look at the following section from MG35-143-eng:
00010410h: 59FEEC60 - 00000400 - 09682E00 - 09280E00

The dashes are in there for clarity, and I've altered the spacing, otherwise it's exactly what you would see in your hex editor. There are actually 4 separate, 4 byte blocks there. The first block we'll ignore for the moment. Partly because it's one of our unknown CRC's, but mainly because it doesn't figure into this discussion. I only added it to show that it seems interesting that it's sitting so close.

Let's look at the 3rd block "09 68 2E 00" which really reads as "2E6809" to us humans (Little-endian, remember, backwards). We've already determined that this number represents the size of the Linux.gz file + the Cramfs.img file + 4 "mystery" bytes.

That is to say:
0x2E6809 = 3,041,289 = (Linux.gz + Cramfs.img + 4)

Now, the 2nd and 4th blocks: "00 00 04 00" and "09 28 0E 00" (40000 and E2809).

Well, if we subtract the 2nd dword from the 4th, we get "0xA2809" or 665,609.
So: (E2809 - 40000) = A2809 = 665,609.

As it turns out, the Linux.gz file is 665,605 bytes in size.

This means we've figured out 2 things. First, we now know how the firmware knows the size of the Linux.gz file. Second, we now have a pretty good idea that the 4 "mystery" bytes are supposed to be attached to the Linux.gz file somehow.

Finally, all of the filesize information is located right next to the 2nd CRC dword (A dword, by the way, is just another way of saying "chunk of 4 bytes"). So it makes me wonder if that dword is actually a CRC or not.

On the one hand, we're missing 4 magic bytes from the Linux.gz file. And immediately before the firmware tells us all about the size of Linux.gz, there's these odd 4 bytes.. Computers usually don't operate on coincidence, so the fact that it's so close has got to make you wonder.

On the other hand, files which contain a self-referential, embedded CRC usually stick that CRC at the very end of the file. Take a close look at a zip file and you'll see that every file inside has a CRC computed for it. That CRC is stored at the end of the zip file, followed immediately by the uncompressed size of the file stored inside.

So, following standard conventions.. Are those 4 bytes our missing "magic bytes" or are they an embedded CRC for the Boot.rom?

pb

ihateu3

07-07-06, 11:55 PM

pbarrette...thanx for the work....i have been waiting for a knowledgable person to purchase the MG-35, and in frustration, decide to reverse engineer it.

sorry i cannot help on this, and i fear that like me, most people on this forum do not know a thing about programming.

my question to you is....have you tried to contact al tec? They have been very cooperative with this forum before, and have given us early releases of english firmware in the past...

I am thinking that if you asked them, there may be a chance that they would give you the source...and they may even learn from you...since they do not seem to be very competent in their firmware designs or their gui's

try contacting them...its worth a shot, besides..they aren't very cultured towards our needs. they may have a hard time understanding that we want the little things, (ability to browse music while playing it!)

RaZeR2

07-10-06, 02:56 AM

my question to you is....have you tried to contact al tec? They have been very cooperative with this forum before, and have given us early releases of english firmware in the past...

Unfortunately he hasn't even scraped the "programming" part yet. What is happening here is he is trying to work out how the MG35 calculates that the firmware is "genuine". Once he achieves this, he'll be able to replace the images with his own, and create a new "geniune" marker so that the MG35 doesn't complain about a new image. I doubt Altech or others would condone this, but I hope pbarrette is successful.

I would love to get hold of the source code and fiddle with getting an SMB server working. I think I may have mentioned it before, but I would happily sacrifice some of the functionality I never use (such as mp3 playback) for ability to browse the device via SMB across the network, if it came down to a matter of space. However, I'm just an amateur C++ programmer, with only an average knowledge of Linux/Unix.

Please keep going pbarrette, I appreciate your efforts. Once this mystery is unlocked, we may be able to get real value for money out of these things!

pbarrette

07-10-06, 04:55 AM

Hi Razer,

Absolutely correct. In order to put modified firmware on the thing, we have to figure out how the upgrader knows it's a "good" firmware image.

Source code for basic linux stuff should be simple. It runs uClinux and cross compilers are available. An SMB server may be a challenge at first. The Sigma processor is an ARM4 based CPU with no MMU support. uClinux was designed for these types of CPU's but has some limitations. There is no fork() support in uClinux, only vfork(). That means there is no true daemon support as most daemon functionality requires a fork(). There are ports for telnetd and ftpd, but I haven't yet seen an smbd for uClinux. Then again, I haven't looked that close since I still don't know how to generate the proper CRC.

The KiSS line of DVD players also use a Sigma EM8XXX chipset and they have been thoroughly hacked. The source code for much of the Sigma stuff has already been reversed. So once we get the CRC worked out and add some basic services to the MG-35 like telnet and ftp, we have a base to start adding better functionality.

I am not a linux programmer and I do not know C++ so others will have to take over that portion. I am most interested in figuring out the CRC at this point. My main goal is to add telnetd and ftpd to the firmware. Adding an FTP server will make file uploads to the device much faster and we will be able to bypass the NDAS crap. With a telnet server as well, reverse engineering the device will be a lot more easy. Simple software can be written to dump the memory banks, determine the flash memory layout and perhaps even replace the bootloader. But in order for that to happen, we first need a way to run that software and view the output.

If anyone is interested in helping, I am currently interested in looking at the "/bin/upgrader" program in the Cramfs image. That program is used to upgrade the firmware in the MG-35. It looks like it will output the computed and actual CRC of a given firmware image. So I would like to find some way to either decompile that program or be able to run it.

I would like to find a disassembler that can handle the bFLT file format. Failing that, I would like to find an ARM emulator which can run bFLT executables in some kind of debugger. I have already tried Armulator and QEMU, but haven't been able to get either working properly.

So if anyone can find me a bFLT disassembler, or knows how to get a decent ARM emulator working with the MG-35's bFLT executables, please let me know.

pb

Cornell87

07-10-06, 03:57 PM

I decided to take my MG-35 along on a recent road trip from Washington DC to Cape Cod MA (8+ hours of driving) so the kids could watch videos off the unit's internal HD rather than packing a lot of DVDs. While in the truck, I had it rigged up to the kid's portable DVD player (which happens to have an AV-in jack). The setup was:

AC Power (via DC/AC inverter) -> MG-35 -> AV signal to portable DVD player (via component video out and analog audio out)

The DVD player has it's own cig lighter DC adaptor for power, and the audio was then piped through the car's stereo system via a cassette adaptor. (Incidentally, this was in a Chevy Suburban with 3 DC power ports.)

It's worked pretty well, except that every so often the output from the MG-35 would go dead -- the unit would stay powered on, but the portable DVD player would display a "no AV in" message. I checked AV-in cable, and those connections (on both ends) seemed very sound, so it's unlikely that's the source of the problem.

I strongly suspect that it was cell phone interference that was causing the MG-35's dropped signal. There are several reasons why I suspect cell phone interference is the cause: (1) the signal drops were almost always accompanied by a staccato buzz (almost sounds like morris code) on the truck's stereo system that I've always assumed was caused by cell phone interference; (2) the drops were much more frequent in heavy traffic (i.e., when we were more likely to be near a cell phone user); (3) one of the drops occurred when my wife was making a call on her cell phone -- the MG-35's signal dropped as soon as she hit the "send" button.

I couldn't reproduced the signal drops at home (same setup except regular AC current, not DC/AC inverter), but I only tried a couple of calls.

It may not be cell phone interference, but so far that's still my best guess. Other possibilities:

- Hard drive shut down due to excessive heat and/or jarring: I don't think these was the cause, since the unit played fine over some very bumpy roads and was at least as well ventilated (probably better) than it is when at use at home.

- DC/AC inverter noise: Maybe, but it's not clear what the trigger would be.

Any thoughts on what might be the cause and what I could do to prevent it? I plan to use this same setup when we drive to NC's Outer Banks later this summer.

Incidentally, the MG-35 works great at home (never any signal drops), whether playing off the internal HD or a network drive.

twr6444

07-10-06, 09:31 PM

Is this any help?

00010ad4:50 61 72 73 65 46 69 6c 65 6e 61 6d 65 00 00 00 ParseFilename...
00010ae4:25 73 20 5b 25 64 5d 20 25 73 3a 20 63 68 65 63 %s [%d] %s: chec
00010af4:6b 73 75 6d 20 3a 20 25 6c 78 0a 0a 00 00 00 00 ksum : %lx......
00010b04:43 68 65 63 6b 73 75 6d 00 00 00 00 45 46 49 4c Checksum....EFIL
00010b14:45 0a 00 00 43 68 65 63 6b 20 66 69 72 6d 77 61 E...Check firmwa
00010b24:72 65 0a 00 25 73 20 5b 25 64 5d 20 25 73 3a 20 re..%s [%d] %s:
00010b34:55 50 47 49 3a 20 25 6c 78 0a 0a 00 55 70 67 72 UPGI: %lx...Upgr
00010b44:61 64 65 46 69 72 6d 77 61 72 65 00 25 73 20 5b adeFirmware.%s [
00010b54:25 64 5d 20 25 73 3a 20 43 4f 4e 44 3a 20 25 6c %d] %s: COND: %l
00010b64:78 0a 0a 00 25 73 20 5b 25 64 5d 20 25 73 3a 20 x...%s [%d] %s:
00010b74:42 4f 4f 54 3a 20 25 6c 78 0a 0a 00 25 73 20 5b BOOT: %lx...%s [
00010b84:25 64 5d 20 25 73 3a 20 62 6f 6f 74 20 73 69 7a %d] %s: boot siz
00010b94:65 20 25 64 20 69 73 20 62 69 67 67 65 72 20 74 e %d is bigger t
00010ba4:68 61 6e 20 25 64 0a 0a 00 00 00 00 25 73 20 5b han %d......%s [
00010bb4:25 64 5d 20 25 73 3a 20 52 4f 46 53 3a 20 25 6c %d] %s: ROFS: %l
00010bc4:78 0a 0a 00 25 73 20 5b 25 64 5d 20 25 73 3a 20 x...%s [%d] %s:
00010bd4:72 6f 6d 66 73 20 73 69 7a 65 20 25 64 20 69 73 romfs size %d is
00010be4:20 62 69 67 67 65 72 20 74 68 61 6e 20 25 64 0a bigger than %d.
00010bf4:0a 00 00 00 25 73 20 5b 25 64 5d 20 25 73 3a 20 ....%s [%d] %s:
00010c04:6c 65 6e 3a 20 25 64 0a 0a 00 00 00 25 73 20 5b len: %d.....%s [
00010c14:25 64 5d 20 25 73 3a 20 4f 66 66 73 65 74 3a 20 %d] %s: Offset:
00010c24:25 64 0a 0a 00 00 00 00 25 73 20 5b 25 64 5d 20 %d......%s [%d]
00010c34:25 73 3a 20 63 6f 6e 66 3a 20 25 6c 78 2e 20 25 %s: conf: %lx. %
00010c44:6c 78 0a 0a 00 00 00 00 25 73 20 5b 25 64 5d 20 lx......%s [%d]
00010c54:25 73 3a 20 62 6f 6f 74 3a 20 25 6c 78 2e 20 25 %s: boot: %lx. %
00010c64:6c 78 0a 0a 00 00 00 00 25 73 20 5b 25 64 5d 20 lx......%s [%d]
00010c74:25 73 3a 20 72 6f 6d 66 73 3a 20 25 6c 78 2e 20 %s: romfs: %lx.
00010c84:25 6c 78 0a 0a 00 00 00 4f 00 00 00 58 00 00 00 %lx.....O...X...
00010c94:25 73 20 5b 25 64 5d 20 25 73 3a 20 55 50 47 49 %s [%d] %s: UPGI
00010ca4:5b 25 73 5d 2c 20 43 4f 4e 44 5b 25 73 5d 2c 20 [%s], COND[%s],
00010cb4:42 4f 4f 54 5b 25 73 5d 2c 20 52 4f 46 53 5b 25 BOOT[%s], ROFS[%
00010cc4:73 5d 20 43 52 43 5b 25 73 5d 0a 0a 00 00 00 00 s] CRC[%s]......
00010cd4:45 55 50 47 49 0a 00 00 45 56 45 52 0a 00 00 00 EUPGI...EVER....
00010ce4:45 43 52 43 0a 00 00 00 45 49 4d 47 0a 00 00 00 ECRC....EIMG....
00010cf4:66 69 72 6d 77 61 72 65 20 25 firmware %

lastdon00

07-10-06, 09:44 PM

when the mediagate is conected via USB does the blue light remain on constantly?

even when i shut off the PC, that light in the front of the system where the enter button is, keeps on flashing away..

i assume the only way to shut it off is by unplugging it? is that the only way?

RaZeR2

07-10-06, 09:51 PM

I strongly suspect that it was cell phone interference that was causing the MG-35's dropped signal.

I have already observed something similar, except tt causes my MG-35 to reboot. With my phone (and my friends) within a few metres of the MG35, it resets about 50% of the time when one of our phones receive or send SMS's, or change networks.

I've had to ban people from having their phones near while watching movies!

Crazy, why is it so sensitive to interference? I can understand why they tell you to turn your phone off in airplanes now!

mgcurious

07-10-06, 11:00 PM

pbarrette,

Have you tried using SkyEye? This ARM emulator lets me run the binaries from the MG35 firmware under uClinux. I took the /bin directory from the original MG35 cramfs image and added it to the boot.rom file that comes with skyeye and am able to execute the programs, such as bin/upgrade. I only became interested today in this device as it would make a fun/cheap embeded toybox. Thanks for all of your contributions so far.

ihateu3

07-11-06, 04:24 AM

Cornell87

07-11-06, 01:16 PM

I have already observed something similar, except tt causes my MG-35 to reboot. With my phone (and my friends) within a few metres of the MG35, it resets about 50% of the time when one of our phones receive or send SMS's, or change networks.

I've had to ban people from having their phones near while watching movies!

Crazy, why is it so sensitive to interference? I can understand why they tell you to turn your phone off in airplanes now!
Just a guess, but I wonder if it's the IDE cable that picks up the interference. My only evidence for this is that at least one of the times the MG-35 pooped out, instead of a total signal drop the MG displayed the message "unable to connect to hard drive" (or something similar).

I'm going to try shielding on the next trip, but I haven't figured out what I'll use. Would aluminium foil be sufficient?

qz3fwd

07-11-06, 02:07 PM

I received this response from Mediaget about getting the source code for the MG-35:
1. Firmware Upgrade
We will release 1.4.5 firmware soon.
We just complete MG-350HD development and first debugging and will do firmware upgrade.
We used to make MG-100 firmware for a long time even in the first model released in 2004

2. Source open.
We open our source to Sigma Design related to GPL.
Our MG-35 use EM8511 Sigma chipset and you can see that in your website.
Actually, some specific codes are not related to GPL and this is our own or related to other company's copyright.
GUI, icons are not related to GPL.

In most case, we open source related to GPL, especially to OEM buyer, but we cannot in Korean website yet.
We are reviewing how to open the source but didn't settle down how to open.

Here is my original e-mail:
I have the MG-35 which seems to have been orphaned as a product since the MG350 is being released and
there have been no firmware updates in some time. There are several features which users would like to have
including FTP&NFS support, revised art work(icons), OSD with audio/video bit rate, etc... I am requesting a copy of
or access to the source code for the MG35-other owners/programmers are also interested in obtaining the sources.
I am sure you are fully aware of the GPL License you agreed to associated with the source code your product relies on.
In case you are not, I have included a link to the license and also attached a copy of the license for your review.

link to GPL license @ FSF

Note the following requirement:
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.

Thank You,

pbarrette

07-12-06, 01:53 PM

Hi mgcurious,

Thanks for the tip with skyeye. I was able to run the MG35 binaries on Skyeye v0.9.5 after repacking the ROMFS file that came with the Win32 package.

I was hoping that "upgrader" would take some basic command line options since they appear to be present in the program. However, if the command line options are there, I haven't been able to get any working.

The MG35 "upgrader" program appears to do an initial, low level probe of the flash memory before proceeding. Since the emulator doesn't provide the proper response, "upgrader" fails out.

It seems that I'm going to have to find some other way to deal with this. Perhaps I can build gdb for use on an ARM device and run upgrader in it. Then possibly NOP the calls to the flash probe, or at least get some assembler code out and try to decipher the CRC checking routines.

Either way, it doesn't appear to be an easy path ahead.

pb

W4tch3r ‹•¿•›

07-12-06, 09:20 PM

Hi pbarrette,
You've done some amazingly good work here. I have not joined the conversation earlier because I am a bit busy at work at the moment to give any real input. I did have a quick stab at disassembling upgrader though using idapro 4.9. I used your kit on a 1.44_English image to extract the cramfs file system. After reading about how to interpret cramfs file headers I found the Code Segment entry point to be at offset 0x50 (and the Data Segment starts at 0x109C0). After telling ida to start disassembling at offset 0x50, it did seem to give quite a sain dissassembly of the file (which I judge crudely by looking at how many entries it puts in the "Problems Window". Switch the analysis it to "big endian" and reanalyse, for example, gives you about 100 times the errors). Biggest problem is that although it can handle little endiam arm executables, and it finds all the strings in the data segment, the cross referencing is not working in the usual manner so its hard to find the references to the strings in the code. For example, you see this in the disassembly:

Text:0000069C LDR R1, =0xE80A0100
Text:000006A0 LDR R2, =0xC4090100
Text:000006A4 MOV R3, #0xCB ; '-'

and normally ida would tell you that 0xE80A0100 is a reference to a string. Now if you go and look at offset 0x00010AE8, you see it contains the string "[%d] %s: checksum : %lx". So basically the little endian format is confusing ida somewhat. The consequence of this is that it takes a bit of time to find references in the code to the strings in the data section (you have to manually do a slow "ASCII search" for the address bytes in reverse order).

So basically all I have to add at moment is that as far as your search for tools goes, I think idapro almost gets you there. I will try a bit more when I find some more time.

I did also try to use a multi polynomial crc utility on the boot.rom image without any luck (I tried multi polys and tried trimming bytes off the end too). I thought it may be worth searching for the table entries of common crc algorithms (in case they used a table based crc implementation). If there is a hit there then you can be sure of which poly was used, then it would be a matter of finding the data its used for. Another possibility is to search within the code for the number code size - 4 (or (size-4)/2 or (size-4)/4). That could be the number of iterations of the crc calc loop.

As far as 2 crc's goes, maybe 1 CRC for the bootloader itself and 1 for the linux+cramfs section?

W4tch3r ‹•¿•›

fanchoor

07-14-06, 07:33 AM

Hi guys,

Is there a way to play WMV video files on Media Gate-35? Most of my video file are WMV files and its pain to covert them all to other supported formats.

Can some one help please?

I have seen that MG-35N supports WMV so I think its possible to play WMV on MG-35 as well.

Thank you

gunrunnerjohn

07-14-06, 07:45 AM

I don't know of any way to play unsupported formats on the MG-35. That would obviously take firmware changes, something that's being discussed in this thread.

Masoud

07-15-06, 10:11 AM

Dear all
how can upgrade medaigate firmware with 10pin connector on mediagate PCB.

fx57

07-15-06, 08:58 PM

Great work pbarrette and W4tch3r!

I too would like to see ftpd running on my mg35 as an alternative to slow NDAS transfers.

I poked around a bit and maybe I can offer some useful info.

I tried disassembling upgrader with IDA and ran into the same address order problems. It appears the code is little endian but header values and addresses are big endian. Luckily the file contains a fixup table which points to all the addresses so you just need to reverse the byte order of these and then everything appears as it should in IDA. Also, the code address space seems to start at byte 0x40 of the file.

I still haven't found anything which looks like a CRC computation yet, but I'll keep looking. Its strange they have a full blown lex parser contained within upgrader, I have no idea why.

Here's the C program I used which fixes up the upgrader binary so you can load it properly in IDA. It reverses all the addresses and strips off the 0x40 byte header and the fixup table.

#include <stdio.h>

unsigned char buf[1000000];

unsigned int getval( unsigned char *p)
{
return ((((((unsigned int)p[0] << 8) | (unsigned int)p[1]) << 8) | (unsigned int)p[2]) << 8) | (unsigned int)p[3];
}

int main ()
{
FILE * pFile;
int c;
int n = 0;
unsigned int table, relocs, offset, addr;
int end;

pFile = fopen("input.bin","rb");
if (pFile==NULL) printf ("Error opening input.bin for reading");
else
{
for (;;)
{
c = getc(pFile);
if (c == EOF) break;
buf[n++] = c;
}
fclose(pFile);
}

end = table = getval(buf+0x1C);
relocs = getval(buf+0x20);
while( relocs--)
{
offset = getval(buf+table) + 0x40;
addr = getval(buf + offset);
printf("fixup entry %08x: offset %08x, addr %08x\n", table, offset, addr);
memcpy( buf + offset, &addr, 4);
table += 4;
}

pFile = fopen("output.bin","wb");
if (pFile==NULL) printf ("Error opening output.bin for writing");
else
{
char *p;
for (p=buf+0x40; p < buf+end && p < buf+n; p++)
{
putc(*p, pFile);
}
fclose(pFile);
}

}

pbarrette

07-15-06, 09:17 PM

Hi fx57,

Excellent work!

I wish someone would implement a proper bFLT FLIRT signature for Ida. That would really help out.

You may want to have a look at dvdplayer.bin as well. Since it's the main interface, it should also contain the initial stages of the upgrade process. I mean, something has to call upgrader and tell it what to do, right? I did notice some strings in there referencing upgrader.

I saw the lex references as well, but didn't know what to make of them. The header already contains the addresses to the firmware parts, so it doesn't need the parser to find them.

Perhaps if we can NOP out the calls to the flashmem probes we can get upgrader to calculate our CRC's for us.

In the mean time, I've been trying to figure out how to get Skyeye to boot the MG35's kernel. There's no ELF header on it, so I'm not quite sure how to deal with that.

I've also been having a preliminary look at the 10-pin header at J9. My multimeter says 3.3v on pins 1,2 and 6. Pin 4 looks like ground and pin3 is 1mohm (IIRC) from pin4. I'm still guessing it's a serial port, but I don't have a level shifter on hand and I don't want to fry the board.

pb

gunrunnerjohn

07-15-06, 09:31 PM

By all means, DON'T connect a serial port directly to that! :eek: There are a host of serial port level shifters that can be plugged together on a prototype board if you want to see if you can get a response out of the port. I've used the Sipex SP232A on a number of projects.

fx57

07-16-06, 03:05 AM

OK, here's what I came up with reversing the firmware upgrade file format. There are no CRC's, they are just checksums where you read the data as DWORDs and sum them up. All dword values are 4-byte little endian format.

000000: "UPGI" ascii
000004: "XM02" ascii
000008: 0x00010404 dword = version 1.44

00000C: "BOOT" ascii
000010: 0xB2756E63 dword = checksum of bootloader (sum of dwords)
000014: 0x00000000 dword =
000018: 0x00010420 dword = size of bootloader
00001C: bootloader data

01043C: "ROFS" ascii
010440: 0x16C8BFC6 dword = checksum of rom filesystem (sum of dwords)
010444: 0x00040000 dword = maybe the location it is stored at in flash memory?
010448: 0x002D8809 dword = size of rom filesystem
01044C: rom filesystem data (dword + linux kernel + cramfs)

2E8C55: EOF

The format of the rom filesystem data is:
01044C: 0x000E2809 dword = location in flash of cramfs
010450: start of linux.gz
0B2C55: start of cramfs.img

I still don't know for sure what causes the mg35 to decide a file is a firmware file. My guess is the "UPGI" text at the start of the file does it but I'm not ready yet to risk turning my mg35 into a brick trying to find out.

fx57

07-16-06, 03:11 AM

And the "C" program used to verify the checksums:

#include <stdio.h>

unsigned char buf[4000000];

int main ()
{
FILE * pFile;
int c;
int n = 0;
unsigned int table, relocs, offset, addr;
int end;
int i;
unsigned int x=0;

pFile = fopen("input.bin","rb");
if (pFile==NULL) printf ("Error opening input.bin for reading");
else
{
for (;;)
{
c = getc(pFile);
if (c == EOF) break;
buf[n++] = c;
}
fclose(pFile);
}

printf("read %d bytes\n", n);

for (i=0;i<n;)
{
unsigned int *d = (unsigned int *)(buf+i);

if (buf[i] == 'U' &&
buf[i+1] == 'P' &&
buf[i+2] == 'G' &&
buf[i+3] == 'I')
{
printf("UPGI at offset %x\n", i);
i += 12;
continue;
}
else
{
int c = d[3];
int x = 0;
for (c=0; c < d[3]; c++)
{
x += buf[i+16+c] << (8*(c&3));
}
printf("%c%c%c%c at offset %x, crc %x=%x, addr %x, size %x\n", buf[i],buf[i+1],buf[i+2],buf[i+3],i,d[1],x,

d[2], d[3]);
i += 16+d[3];
}
}

}

davei1

07-16-06, 06:13 AM

For anyone interested...
I bought one of the XIMETA empty NetDisk Enclosures that sell for under $100 that also use NDAS...I believe these have the NDAS processor that the MG-35 lacks...I'm planning on buying either a 500 or 750MB drive when the prices come down more...In the interim I took the drive out of the MG-35 with all my music and video and backups, etc. and put it in the NetDisk enclosure...Registered the NetDisk as a NDAS device with the ID and Write Key and did some testing with file transfers...The NetDisk enclosure using NDAS for file transfers is approximately 3 to 4 times faster than the MG-35 transfers using NDAS...I also tested watching .VOB files from the Netdisk (shared out) through the MG-35 and all played without any glitches (100baseT network)...I'm going to leave it in this configuration until I get a big drive...Only thing I'll want to change is add a fan to the NetDisk enclosure (Like I did my MG-35)...

pbarrette

07-16-06, 09:16 AM

Hi fx57,

I took the plunge.

Your checksum code works great!

This is what I did:
1 - Compiled your code with cygwin.
2 - Split out the MG35-144-eng firmware to the 3 component parts.
3 - Used FSExtractor to add files to the cramfs.img
4 - Merged the components back together (copy /b).
5 - Changed "0x010448:" to reflect (Linux.gz+Cramfs.img+4).
6 - Ran your code against the new firmware image.
7 - Changed the checksum at "010440:" to the one calculated with your code.
8 - Upgraded the firmware on my MG35.

I stole some bits from the KiSS firmware project to add to the cramfs filesystem. Specifically, I took "/bin/ftpd", "/bin/busybox" (renamed to busyb) and "/etc/passwd". I also modified /etc/sashrc to start "/bin/ftpd &" and "/bin/busyb telnetd &".

The only bad news is that ftpd and telnetd don't seem to have started up. I should probably also add "/etc/services" in there as well. Actually, I should probably cross compile a new busybox and ftpd and use that.

But.. The very good news is that your code works great and we can now start modding the firmware for these things!

Thanks for your excellent work.

pb

teddystacker

07-16-06, 09:48 AM

Guys,

This is really really great news,a huge thank you to you both for your superb work..

At this point I have not managed to find anyone who can do us some graphics for a better GUI.so I may post a request in the main forum and a couple of similar forums pointing to this thread to try and attarct someone that can help..

@PB,Would you be papared to host any new "beta" firmwares yourself? or do you think it might be a better idea to create a Yahoo group to host files etc,this may avoid and bandwidth or legal issues?. If so, I am papred to create and mange this for us - at least then i can contribute something...

Let me know your thoughts...

pbarrette

07-16-06, 12:59 PM

Hi Teddy,

Honestly, I'm not concerned in the least about "legal issues" coming from a company that is blatantly stealing GPL'ed work and reselling it without offering source code.

Bandwidth, however, may be an issue. I have a lot to spare at the moment, but I don't know what the expected load would be for custom firmware images. So it's probably best to start a yahoo group.

I think we need to redo the firmware tools so others can create their own firmware images more easily and with a minimum of risk.

I plan on making a checksum creator / injector in C# soon. I also have a few other utilities I've written while trying to figure out the "CRC" problem that would probably be useful for other purposes. For instance, I used the classless.hasher (http://hasher.classless.net) library to create a multi-crc generator with custom CRC polynomial support.

In the short term, I'm thinking of a simple program that will accept a Mediagate firmware image. It should then extract the cramfs image and allow you to edit it to suit your needs. Then the program would replace the original cramfs with the new one. Finally, it would update the size in the bootloader and change the checksums to build the new firmware. Additionally, it could change the firmware version number as well.

pb

pjelar

07-16-06, 05:34 PM

I'd be interested in creating images for this box. I've also got a friend who could create the graphics for the interface, I've been annoyed for a long time with the fact that it doesn't really do what I want it to do. Anyone gonna create a mailing list?

teddystacker

07-16-06, 06:02 PM

@pjelar

Great news that you can help with NEW graphics to improve the interface..

I am going to create a Yahoo group that will also act a a mailing list and a files distro..

Can you extract the graphics that need to be altered yourself ?(details on how todo this was posted by PB a week or two back) , or would you like me to email them to you?

I guess they would all need to be the same size and colour depth that the originals were , but maybe you could check that with PB..

Will be at the beach tomorrow , so will be a couple of days until its up and running..

alangsk

07-16-06, 10:41 PM

If this could be done to the MG-35, could it possibly be done to the MG-350HD? I know the MG-35 needs to happen first, but I am just curious.

W4tch3r ‹•¿•›

07-17-06, 04:31 AM

Spectacular work guys (esp pb, fx57). Very impressive, congratulations. Flirt sig as pb suggests would be great. FX57, is it possible to run your byte reversal code as an IDA script (IDC file)? I would like to know also pb how far you can push Skyeye. It would be nice to develop a test environment so any risk to the MG35 can be left as late as possible in the process,
W4tch3r ‹•¿•›

ru*

07-17-06, 09:10 AM

Hi teddystacker,
I'm Pjlars friend, could you post the require files here or email me the files so i can edit the files as necessary.

Also does any one know if its possible to change the way the system displays files and also its ability to play files in a working manner?

Ru.

gadgetmind

07-17-06, 11:47 AM

I'll join the yahoo group as soon as it's created.

Maybe we can handle distributing firmware via **********? This would handle the 1st rush as everyone grabs it, and then older stuff can be archived elsewhere.

My main gripes with the MG-35 are -
1) Pretty bad handling of divx/xvid - it's great with some files but has bad lip sync and/or jerky performance with others. I tend to use autogk to re-encode some files (virtua dub won't handle a fair few) I doubt we can fix this.
2) It takes ages to drill down to my content. I have to tell it I want network content (no HD i my unit), then wait for a list of servers, then go to the right server, then the right share - it must take a good minute before we get to where we need to be.

Dunno how (2) could be addressed as I guess the current applications are all closed source. But maybe my samba share could be mounted somewhere where the MG-35 would see it immediately? I'm not sure how samba (or even the HD mounting) is currently done.

Ian

fx57

07-17-06, 01:10 PM

Maybe getting a simple shell running on the MG35 is a good first step?

http://www.gooddvdstuff.com/kissdvd/viewtopic.php?t=1527

jayeazy

07-17-06, 03:19 PM

Hello Guys,

Been away for a while, and it seems a lot has been done.
Looks good, what is done, and can be done.
Can't wait for the possibility to customize the MG35.

It looks like the SASHRC script in the /etc folder is the startup script of the system.
Can't wait to be able to login to the mediagate, and try to mod to unit.

Keep on going guys ;-)

Jelte

teddystacker

07-17-06, 07:30 PM

Ok,

Have been having a think about files distro for Beta firmware - ********** good idea.. also is Rapishare,I have a Rapishare premium account,so as well as posting any Beta firmware to the Yahoo group that I plan to create , I can also post a Rapidshare link both here and at the Yahoo Group,so people can download directly without any hosting problems.Yahoo groups only have 20 gig storage,so wont be able to archive that much there,thus Rapid and ********** will be useful.Rapidshare link NEVER expire,so wil provide a good archive..

For Those of you wishing to do some artwork for a new GUI for the MG 35 , here is a Rapidshare link for the unpacked Mg-35 Firmware.The one here is the latest Korean 1.4.5 f/w that PB suggest we use..
As you will see I have left the complate file structure intact,as the graphic files are located inside many different folders.Most appear to be in jpg and png format.I presume (might be a good idea to check with PB) that any replacement files you create will have to be the exact same file size and colour Depth.

http://rapidshare.de/files/26124381/MG35KOR.DIR.rar.html

I will make time to create the Yahoo MG-35 Fimware mod Group tomorow , and will post details here as soon as I have done it..

pbarrette

07-17-06, 08:49 PM

Hi Teddy,

At this point, it's probably a good idea to keep the images at the same color depth. I'd have to take a closer look at the images and compare them to what I see on screen, but I think there may be a transparent color involved for some of the images. So that's something to check for as well.

As I said before, the PNG format seems to be a little odd. IrfanView does not recognize them, but Photoshop has no problems. The MG35 is using libpng to display the PNG images. This should mean that we have a lot of flexibility as far as color depth and compression.

The modified images can be any size, but due to limited flash memory, smaller is better.

In the meantime, I've made a program which can verify the checksums of MG35 firmware images and create a patched output file. The utility can be found here (http://peterbarrette.com/MG35/MgCheck.zip). It only supports MG35 images at the moment, but I plan on supporting MG25 and MG350 firmware images in the near future. Right now, it will detect MG25 and MG350 images and give a "Not supported" message. Again, this program uses the .NET framework.

To create your own custom firmware images using Windows, download the following tools:
1 - MGFWExtract (http://peterbarrette.com/MG35/MGFWExtract.zip)
2 - FSExtractor (http://sourceforge.net/project/showfiles.php?group_id=99199&package_id=108962&release_id=263019)
3 - MgCheck (http://peterbarrette.com/MG35/MgCheck.zip)

You then need to perform the following steps:
1 - Use the MGFWExtract package to split out the firmware image.
2 - Use FSExtractor to edit the Cramfs image.
3 - Join the parts back together: copy /b boot.rom+linux.gz+cramfs.img NewFirmware
4 - Run "MgCheck -p" against the new firmware image to patch it.

The resulting "NewFirmware.fix" file can then be renamed to ".upgrade" and flashed to the MG35.

Of course, the standard disclaimer follows...

You can kill your MG35 if you don't know what you are doing. Don't delete any files in the Cramfs.img file if you don't know what they do. Don't edit any of the files if you don't know what they do.

I have successfully flashed a modded firmware image using this process, but I could have killed my box just as easily.

pb

EmuMannen

07-18-06, 04:12 AM

I'm attempting to use 10.4 as my file server and was wondering if anyone else has gotten it to work and/or could elaborate on the said process above. I know the MG-35 works via the Network because I can get it to access a shared volume with XP S2 -- but am having no luck with OS X. Of course, the provided documentation is completely mum on the issue.
I had some problems getting my MG-35 to work with SMB under Linux preserving the opportunity to have security = user. This is how I solved the problem (the example is for one share holding your private files, requiring username and password and the other one is a public share granting all users read and write access). You will also need to create a samba user called “guest” (command: smbpasswd -a username), use any password if your not allowed to create a new user with an empty password and reset the password to null (command: smbpasswd -n username):

File: /etc/samba/smb.conf

[global]
workgroup = YOUR_WORKGROUP_NAME
netbios name = YOUR_SERVER_NAME
passdb backend = tdbsam
security = user
encrypt passwords = true
guest account = guest
null passwords = yes
socket options = TCP_NODELAY

[Private]
comment = Private files on server
path = /path/to/privte/files
read only = no
valid users = your_user_account

[Public]
comment = Public files on server
path = /path/to/public/files
invalid users = root
guest ok = yes
public = yes
writeable = yes

EmuMannen

07-18-06, 04:37 AM

what is the difference between Al tec and freecom? my box says freecom medaiplayer 35,
On their site last firmware is 1.4.3 so I haev tried to use the Al Tec firmware and the device can not see the file!
I got a Freecom Network Media Player-35 myself. I haven’t upgraded the firmware (yet, it came with the latest Freecom version 1.4.3). The Freecom unit should be equal to the Media Gate MG-35 based on readings on other Scandinavian HT-boards. There are examples of successfully using the Media Gate firmware on Freecom units. This is only based on what I have read on other boards and I haven’t tried it my self yet.

Ps. I have got the impression that the Freecom unit is the same as the Media Gate MG-35, just sold in Europe by Freecom under another name, but I could be wrong…

EmuMannen

07-18-06, 04:48 AM

Hi Batman1056,
Freecom is the exception. If you have a Freecom MG-35 clone, you can email their support with your serial number and MAC address and they will email you back with the DeviceID and Write Key at no charge. This is one of the main reasons I got the Freecom.
I got the MAC, DeviceID and Write Key on a sticker on the bottom of my Freecom Network Media Player-35. They are labeled: MAC, ID, KEY (the sticker is also mentioned in the user’s manual). So check the bottom of your unit for a separate sticker with NDAS information...

EmuMannen

07-18-06, 05:09 AM

I just returned to AVS and as usual looking for something interesting. The latest development in this thread really got me going! pbarrette, just want you to know that I am reading all your posts with great interest and enthusiasm. Thanks a lot for all your hard work and I am really looking forward to some serious hacking of this unit (I got a Freecom myself). I am not an ARM hacker my self but I do code for a living and I got some really nice resources at work. Please let me know if you need any help. I don’t got much time at hand (running a family with small kids) but I guess that I could contribute in the GUI/gfx area. I just love working with HMI and Photoshop. Just let me know if you need any custom gfx for this unit…

dodonov1

07-18-06, 09:28 AM

...There are ports for telnetd and ftpd, but I haven't yet seen an smbd for uClinux.
pb

Hi pbarrette and all

Many thanks for your great work on cracking open this firmware. I'm reading this mailing list with great interest. I just came across this product last weeked, and the only reason I haven't purchased it yet is the lack of a samba server running on it. If you get this working, you'll have sold another MG-35 for Freecom :-).

I'm an embedded s/w developer but alas don't yet have enough experience to contribute any help at this stage. However, I noticed your comment about getting smbd running on uClinux. It occurred to me that, as far as I know, the Linksys NSLU-2 has an ARM (XScale)-based CPU running uClinux and features a samba server. That might be another useful source of code and utilities.

Thanks, and good luck with the next steps.
-Dan

pbarrette

07-18-06, 10:08 AM

Hi Dan,

The real breakthrough came from fx57 by finding the checksumming logic.

I think that the XScale CPU's have an MMU and thus can use fork(). We would have to find a port for smbd that uses vfork() instead. There is probably a patch out there somewhere, but I'm taking it one step at a time.

pb

pbarrette

07-18-06, 10:31 AM

Hi again everyone,

I have managed to get telnetd running on the MG35.

I used the telnetd from "Big" on gooddvdstuff.com which was part of a KiSS firmware mod.
Specifically, I used this firmware iso (http://www.gooddvdstuff.com/filecorner/depo/4/FW-2.9.3-150x-BiG-ISO1-MVFree-TS-BLOff.zip) and extracted the romfs.bin file. You then need to decompress it since it's stored in bFLT gzip compressed format.

If you have a linux system with the arm-elf cross compiling tools, you can use flthdr to decompress it. Otherwise, head over to Sigma-Player.org.ru (http://www.sigma-player.org.ru/) and get a copy of bombur's SigmaEdit (http://www.sigma-player.org.ru/SigmaEdit?v=9tm). You can open compressed bFLT files and save them as uncompressed with this tool. While you're there, take a look at his arm2html bFLT disassembler (http://www.sigma-player.org.ru/Bombur/Download).

Anyway.. Once you have an uncompressed bFLT telnetd executable, inject it into your Cramfs.img. Then extract /etc/sashrc and edit it to include the following line at the end of the file:
/bin/telnetd -l /bin/sh

Delete the old sashrc and inject your new one. Rejoin the sections, patch the new firmware image and upgrade your MG35 with the newly patched image.

You will then get a nice terminal console into the MG35:

Sash command shell (version 1.1.1)
/> mount

/dev/root on / type cramfs (ro)
none on /dev type devfs (rw)
proc on /proc type proc (rw,nosuid)
ramfs on /hosts type ramfs (rw,nosuid,nodev)
ramfs on /net type ramfs (rw,nosuid,nodev)
ramfs on /usb type ramfs (rw,nosuid,nodev)
/dev/discs/disc0/part1 on /cdrom type ntfs (ro,noatime,nodiratime,uid=0,gid=0,fm
ask=0177,dmask=077,nls=default,errors=continue,mft_zone_mult iplier=1)
/> /> busybox lsmod

Module Size Used by
ndemu 28928 (initializing)
lpx 32000 2
dm9000x_32 8408 2
fipmodule 5488 1
khwl 278624 2
/> />

Then have a look around..

If someone is willing to host, I can send you the telnet enabled firmware image.

pb

teddystacker

07-18-06, 10:49 AM

Ok Everyone,

Yahoo group created to aid with file hosting ,new firmware distrobution etc..

It's a bit "rough and ready" at the moment - later, I will add PB's Firmware tools and a small FAQ on how to use them.I am more than willing to take on any suggestions anyone may have,as its nice to have this as a group effort.. I don't conside this "My" group,I just want to help things along..

http://groups.yahoo.com/group/mg-35_firmware_mods/

teddystacker

07-18-06, 10:53 AM

Hi again everyone,

If someone is willing to host, I can send you the telnet enabled firmware image.

pb

Space in the files section at the Yahoo group all ready and waiting :) - let me know once its up and I will also upload to Rapidshare to aid things along a little..

gadgetmind

07-18-06, 11:17 AM

You will then get a nice terminal console into the MG35:

Absolutely top notch stuff!

I guess that now you've got a terminal, and as the MG-35 can clearly smb mount remote shares, that a fair amount of further development can be done without needing to reflash firmware each time.

You should be able to kill the existing dvdplayer and run a different version from a share. You should also be able to smb mount a new img directory over the top of the current one.

Ian

teddystacker

07-18-06, 11:39 AM

Rapid Share Mirror link for PB's MG-35 1.4.4 Firmware with telnet enabled.

http://rapidshare.de/files/26184627/Shell-144-eng.rar.html

gadgetmind

07-18-06, 11:50 AM

I notice in the Kiss discussion that someone referenced that from a
terminal on this device you can do -

-----------------------
./fileplayer.bin SHT 80 64.236.34.143
./fileplayer.bin PC1 AUDIO\song.mp3 192.168.0.2
./mpegplayer.bin MPS VIDEO\movie.mpg 192.168.0.2
./filepayer.bin PC2 VIDEO\****.avi 192.168.0.2
-----------------------

Anyone know the exact arguments to the various programs do? I'd love
to have my MG-35 power up and default to play video mode viewing a
given remote share.

sashrc starts dvdplayer.bin with -
/dvdplayer.bin &

Does dvdplayer than call fileplayer, mpegplayer, mp4play, and mp3play
as appropriate?

Ian

pbarrette

07-18-06, 11:56 AM

Hi teddy,

The shell enabled firmware is up.

I also added a version of ftpd ["/bin/ftpd"] as well as a busybox with a few more features than stock ["/bin/busyb"]. The telnetd binary is actually a small busybox binary renamed to telnetd. So this image actually has 3 different busybox binaries on it. That makes it unneccessarily large, but we can work on reducing the size later. Right now, it's just important to not go over 4MB (size of flash mem). I'd actually recommend not going over the size of the Korean 1.4.5 firmware until we have a clearer picture of how much of the flash we can actually use.

I just stole ftpd from one of the KiSS firmware images, so I don't know exactly how it works yet. It is running in the modded firmware, but doesn't like my login attempts at the moment.

The HD is mounted at "/cdrom", which is probably a leftover from the sigma based dvd players. Unfortunately, the system uses a read-only NTFS kernel driver. So unless we find a decent read-write NTFS driver, ftpd and smbd will be almost useless.

pb

J. L.

07-18-06, 12:16 PM

Hi teddy,

The shell enabled firmware is up.
Great news... congrats... ordered my MG35 yesterday from mwave.com, hope to join in the fun soon.
Right now, it's just important to not go over 4MB (size of flash mem). I'd actually recommend not going over the size of the Korean 1.4.5 firmware until we have a clearer picture of how much of the flash we can actually use.
Just how much free space is there?
Unfortunately, the system uses a read-only NTFS kernel driver. So unless we find a decent read-write NTFS driver, ftpd and smbd will be almost useless.
alas, true. Might the internal disk be formatted as a type where read/write is supported? It might not work as a USB drive formatted other than NTFS unless tied to a linux box. But with ftp (you'll soon figure it out), who cares.

Lots of potential now that you have telnet working.

Joe L.

J. L.

07-18-06, 12:22 PM

I just noticed in the prior post it has /proc.

You might type cat /proc/filesystems and see what is supported by their kernel.

Joe L.

teddystacker

07-18-06, 12:36 PM

[QUOTE=J. L
Just how much free space is there?

Joe L.[/QUOTE]

Only have 20 MB files space at the Yahoo group , so wont be able to hold many different firmwares there..

But..

I intend to mirror Every single firmware that is uploaded to Rapidshare.Rapidshare seems to have a new "folders" feature that I am loking into now,that allows you to Browse folders of uploded content..

Will post more details as soon as I have looked into it more..

gadgetmind

07-18-06, 12:42 PM

The telnetd binary is actually a small busybox binary renamed to telnetd. So this image actually has 3 different busybox binaries on it. That makes it unneccessarily large, but we can work on reducing the size later.

For those who don't know, busybox is a multi-launch binary. It contains the code for lots of functions and determines which to "be" by looking at the name it was called with,

So, you can use renamed versions, but it's far more common to have symlinks in the name of telnetd, ping, or whatever that point to busybox.

However, symlinks probably won't survive an unpack/repack on Windows of the cramfs.

Ian

J. L.

07-18-06, 12:53 PM

Only have 20 gig files space at the Yahoo group , so wont be able to hold many different firmwares there..
My question was not clear... I was not asking how much space you have at Yahoo.

I was asking how much of the 4 meg flash ram in the MG-35 does the current modified flash image occupy. (How much room is left for extra goodies?)

Also... if you have 20Gig of file space on Yahoo and the flash image is less than 4Meg I would guess you have room for a few (5000?) images before you run out of space.. :)

Joe L.

pbarrette

07-18-06, 01:07 PM

Hi Joe,

The MG35 has 4MB of flash memory. I don't yet know how much of that is reserved and shouldn't be touched. So we actually have slightly less than 4MB to play around with.

Unfortunately, the kernel in the 1.4.4 firmware image doesn't have much in the way of filesystem support:

nodev rootfs
nodev bdev
nodev proc
nodev sockfs
nodev pipefs
cramfs
nodev ramfs
vfat
iso9660
nodev devfs
nodev smbfs
ntfs
romfs

There's no ext2/3 support, so for writeable filesystems we're basically stuck with VFAT. But then you hit the 4GB filesize limit and the ~130GB partition limit. I've got a 250G drive in mine and I'd hate to have to chop it into two separate partitions just to get R/W capability. I'd also have to remove some of my ISO's that are larger than 4GB.

pb

gadgetmind

07-18-06, 01:16 PM

There's no ext2/3 support, so for writeable filesystems we're basically stuck with VFAT.

A kernel rebuild is easy enough, but I guess the chances of turning an MG-35 into a brick are rather high.

As a day job, I'm involved in embedded Linux development (on our own totally new processor architecture) and we also develop JTAG debug pods, but we don't support ARM. But I'll start looking around for options regards recovering from a totally dead flash image.

Ian

pbarrette

07-18-06, 01:29 PM

Hi Ian,

If you have an MG35 yourself, take a look inside it near the HDD power connector. There's a 10 pin header labeled J9 which has 3.3v levels on a few of the pins. Personally, I think it's a serial port, but it may be JTAG. It could even have pins for both.

I don't have a level shifter to check it out and I'll be moving back to the states in a month, so I don't plan on making a digikey purchase until I get back and get settled.

We probably could add ext2 support to the kernel, but then we'd lose the ability to connect it via USB to Win32 boxes. Well.. There are a few Win32 ext2 drivers out there, but the last time I used one I lost a lot of system stability.

pb

gadgetmind

07-18-06, 02:25 PM

If you have an MG35 yourself, take a look inside it near the HDD power connector.
There's a 10 pin header labeled J9 which has 3.3v levels on a few of the pins. Personally, I think it's a serial port, but it may be JTAG. It could even have pins for both.

Yup, I have the Freecom version. I'll take a squint at it. Any information about regards the Jester boot rom? It might have a fall-back serial boot.

We probably could add ext2 support to the kernel, but then we'd lose the ability to connect it via USB to Win32 boxes. Well.. There are a few Win32 ext2 drivers out there, but the last time I used one I lost a lot of system stability.

I'm using the IFS drives stuff to access my Ubuntu ext3 partition from Windows. They say it's rock solid even with a Windows page file on an ext3 partition! My system has certainly not had any issues with the stuff installed. My desktop search even went off and indexed my Linux partitions!

Ian

DaBolter

07-18-06, 09:01 PM

Hi,

I noticed PBarrette mentioned that there was only NTFS read support. I think my unit is set up as NTFS, but with NDAS. So in that case how does it write to the hard disk?

At any rate I have been lurking on this forum for a while, and am amazed at how fast this is all progressing.

Another question.

I have a set top box linked to my telly. The box is connected to a local TV provider. The television channels are sent to the box as UDP streams, over the same connection that handles my internet link. As a result I can run VLC on my PC and receive the video streams.

Is it possible to do something like this on the MG35 ?

alangsk

07-18-06, 09:32 PM

After things get worked out with being able to mod the firmware, couldn't the flash memory be upgraded to allow even better graphics? Just a thought.

J. L.

07-18-06, 11:25 PM

Hi,

I noticed PBarrette mentioned that there was only NTFS read support. I think my unit is set up as NTFS, but with NDAS. So in that case how does it write to the hard disk?
Good point... if you truly have an NTFS filesystem on your disk...

I can only think of two possibilities...
1. The NDAS driver knows how to read and write NTFS file systems, and somehow bypasses the linux device interface and writes to the raw disk hardware.
or
2. When you connect via NDAS the NTFS filesystem is re-mounted r/w (read-write) instead of ro (readonly)

If we are very lucky, it will be "2"

Joe L.

icabrindus

07-18-06, 11:29 PM

As a day job, I'm involved in embedded Linux development (on our own totally new processor architecture) and we also develop JTAG debug pods, but we don't support ARM. But I'll start looking around for options regards recovering from a totally dead flash image.

Ian

Speaking about the bricks :) I noticed some PCB pads that could be for the JTAG header. It's an area on the edge of the board, between the Davicom DM9000 and EPM3032 chips. On my board it is hidden by a paper label, so you cannot see it unless you get the board out :) It's a 2x5 header, on a quick look seems that there are at least 4 pins connected on one of its sides, so it can be what we are looking for.

icabrindus

07-18-06, 11:37 PM

The MG35 has 4MB of flash memory. I don't yet know how much of that is reserved and shouldn't be touched. So we actually have slightly less than 4MB to play around with.

pb

Great job, pb! I'm amazed what you managed to do in such a short time.

About the limited flash space, don't forget we have a huge hard drive at hand! Plenty of room to keep executables/configuration/gfx/etc.

My suggestion is to have a (hidden?) mg35 folder on the harddrive (or a small ext3 partition, if we manage to get support for that), in which to keep all the stuff we need. The main thing here should be a script, e.g. userscript.sh. Then, execute this userscript in /etc/sashrc. This way, we can do whatever we want on this user-space, updating anything over USB/NDAS, without re-flashing the device. I have to confess, I'm not very confident one of us will not end up with a brick, if we keep flashing all the time for enhancements...

The only problem I can see here is the mapping of executable file attribute for Linux, if the partition is VFAT.

To avoid the permission issue, we can even keep a cramfs image on the harddrive, and change the boot loader to use it if it can be found (if not, it should use the default one, from flash). We can do the same trick for the kernel, probably. To recover from the "brick state" one would need just to extract the hard drive, put it in another computer, and delete the kernel/cramfs files. So I think the boot loader is the real key to our problem. But all this is probably a long shot...

icabrindus

07-19-06, 12:07 AM

Good point... if you truly have an NTFS filesystem on your disk...

I can only think of two possibilities...
1. The NDAS driver knows how to read and write NTFS file systems, and somehow bypasses the linux device interface and writes to the raw disk hardware.
or
2. When you connect via NDAS the NTFS filesystem is re-mounted r/w (read-write) instead of ro (readonly)

If we are very lucky, it will be "2"

Joe L.

I think the kernel NTFS driver supports only the read and rewrite functions (file creation is just beta).

Maybe MG35 it is treating the disk as a plain block device, and "reflects" everything to the NDAS/USB interface, without knowing anything about the disc structure? Leaving the VFAT/NTFS structure processing to the Windows host?

gadgetmind

07-19-06, 01:44 AM

About the limited flash space, don't forget we have a huge hard drive at hand! Plenty of room to keep executables/configuration/gfx/etc.

I fitted a hard drive to my Freecom just to see if it worked, but removed it pretty quickly as, 1) It's a bit noisy, 2) All my content is on my 2TB server in my underground bunker. (yes, really! )

However, if everything heads in this direction, I do have a IDE->CF adaptor and a few small CF flash cards lying around.

Regards NTFS support, I've missed which kernel version is being used. The NTFS drivers did slowly improve, and ISTR that it was only file extension that ended up being really dodgy. But ext2 would be better.

Here is the windows ext2 driver that I use - http://www.fs-driver.org/

Ian

pbarrette

07-19-06, 03:58 AM

Hi all,

Here are some lines out of /proc/kmsg:
Linux version 2.4.17-uc0
Processor: ARM pt110 revision 0
Architecture: JASPER
Linux NET4.0 for Linux 2.4
devfs: v1.7 (20011216) Richard Gooch (rgooch@atnf.csiro.au)
NTFS driver 2.1.6a [Flags: R/O]
Uniform Multi-Platform E-IDE driver Revision: 6.31

Based on information found while scouring the net.. The kernel version reports 2.4.17-uc0 but probably contains various patches from later versions. Sigma released the kernel sources, but apparently those aren't complete and don't include config files.

NTFS writing via NDAS is handled by the NDAS driver. The driver takes control of the HD and treats it like a simple block device. It then streams the blocks over the wire as the host computer requests them. The hosts computer thinks it's looking at a really slow SCSI drive. The NDAS driver gives the host system the HD's basic block info. So essentially, the host's NFTS drivers are handling the filesystem edits.

Next problem.. Executables on the HD:
/> mount -t ntfs /dev/discs/disc0/part1 /usb/TMP -o ro,uid=0,gid=0,fmask=0077,
dmask=077,errors=continue,mft_zone_multiplier=1,noatime,nodi ratime,nodev
/> mount
/dev/root on / type cramfs (ro)
none on /dev type devfs (rw)
proc on /proc type proc (rw,nosuid)
ramfs on /hosts type ramfs (rw,nosuid,nodev)
ramfs on /usb type ramfs (rw,nosuid,nodev)
ramfs on /net type ramfs (rw,nosuid,nodev)
/dev/discs/disc0/part1 on /cdrom type ntfs (ro,noatime,nodiratime,nosuid,nodev,u
id=0,gid=0,fmask=0177,dmask=077,nls=default,errors=continue, mft_zone_multiplier=
1)
/dev/discs/disc0/part1 on /usb/TMP type ntfs (ro,noatime,nodiratime,nodev,uid=0,
gid=0,fmask=0177,dmask=077,nls=default,errors=continue,mft_z one_multiplier=1)

Note that I changed the "fmask" to "0077" in my mount request. Unfortunately, the mount was still done with "0177" instead. Since we have no execute bit, we can't run software from the disk. So the question becomes: Is the fmask built into the kernel driver or can we change it?

pb

pbarrette

07-19-06, 04:01 AM

icabrindus

07-19-06, 07:46 AM

However, if everything heads in this direction, I do have a IDE->CF adaptor and a few small CF flash cards lying around.

Ian

You can try, but I don't think it will work. For some obscure reason, the firmware supports only harddrives larger then 6 GB (see the printed manual, page 4, "Specifications", paragraph 8). I tried a 4 GB hdd and it wasn't recognized by the device.

icabrindus

07-19-06, 10:12 AM

Hi all,

Note that I changed the "fmask" to "0077" in my mount request. Unfortunately, the mount was still done with "0177" instead. Since we have no execute bit, we can't run software from the disk. So the question becomes: Is the fmask built into the kernel driver or can we change it?

pb

Can you mount a cramfs filesystem hosted inside of a disk file? This way, the permissions are inside the image, not in the host filesystem.

icabrindus

07-19-06, 04:04 PM

Hi again,

I forgot to mention..

There is no problem running executables from SMB mounts. I've tried it, and it works. But my mount was done by browsing to the folder with the MG35's TV interface. I can't for the life of me figure out how their smbmount command works. I'm using what should be the right command line arguments, but every attempt fails.

pb

How did you mount and execute something from a SMB share, using the remote? Can we execute busybox or telnetd over SMB without reflashing? It would be great :)

icabrindus

07-19-06, 05:39 PM

I can't for the life of me figure out how their smbmount command works. I'm using what should be the right command line arguments, but every attempt fails.

pb
This is from /bin/smbmount, probably you have seen it:

smbmnt -s -r %d -u -g 0%o -f -d
Usage: mount.smbfs service mountpoint [-o options,...]

Version 2.0.7
Options:
username=<arg> SMB username
password=<arg> SMB password
netbiosname=<arg> source NetBIOS name
uid=<arg> mount uid or username
gid=<arg> mount gid or groupname
port=<arg> remote SMB port number
fmask=<arg> file umask
dmask=<arg> directory umask
debug=<arg> debug level
ip=<arg> destination host or IP address
workgroup=<arg> workgroup on destination
sockopt=<arg> TCP socket options
scope=<arg> NetBIOS scope
guest don't prompt for a password
ro mount read-only
rw mount read-write

This command is designed to be run from within /bin/mount by giving
the option '-t smbfs'. For example:
mount -t smbfs -o username=tridge,password=foobar //fjall/test /data/test

I think it's safer to use mount instead of smbmount. I remember having some issues in the past with passwords, using mount -t smbfs -o username=...... I don't remember exactly how to specify a blank password: as empty string with quotes (password=""), as void (password=) or just leaving the parameter out?

If you have a Samba server at hand, you can enable debugging and then try to connect MG35 to a share. The log should tell you exactly what's wrong.

pbarrette

07-19-06, 07:31 PM

Hi icabrindus,

I haven't yet tried to mount a cramfs image hosted on an SMB share.

I got the SMB share mounted by using the basic TV interface via "Network -> Movie -> Machine -> Share". Then I telnetted into the MG35 and was able to view the share mounted at: "/net/MACHINE/Share"

So, yes, you do need to flash the firmware to enable telnetd before you can execute programs from an SMB mount.

I also ran a constant "ps" loop while drilling into the shares and found some interesting stuff:
nbtscan -q -b /net -e 192.168.1.5/24

This command generates the netbiosname->IP "/hosts/hosts" file (My MG35 has a static IP set to 192.168.1.5, BTW, so it's scanning the /24 network of .5). This is how it discovers netbios hosts and later resolves the names. The MG35 runs this command every time you drill down to the machines from the main HDD/NET selection screen. That's why it takes so damned long to enumerate the machines every time you start from main.

If you select the HDD instead of NET, it doesn't run the command and has no hostname mapping. However, if you telnet in and run the command yourself (or from sashrc, say) then it will generate the hosts file for you. Another byproduct of this command is that it also creates the /net/HOST mount point directories.

I also found the SMB mount method.. Sort of..
smbmount //MACHINE/share /mountpoint -o password [passwd] username [username] options

So apparently smbmount takes space delimited parameters and values even though the "help" states differently. It's hit or miss for me whether I get a valid mount or not. I'm apparently having some issues with shares and permissions on my computer though. One share mounts every single time via telnet, but the mountpoint is totally empty. Another share refuses to mount at all, even though everything is exactly the same.

Another odd issue is that when I use the TV interface to mount shares on my system, the MG35 reboots itself. I'm not having any problems viewing AVI's on my wife's system though, so it must be an issue with my machine. That makes it all rather difficult to track down. Oddly, however, mounting to my wife's system with smbmount via telnet doesn't work at all.

There's another command that shows up while running a looping "ps" during the mounts:
smbmount -b /net/PB -L PB -U guest -N -s /hosts/smb.conf C

(PB is my machine name, BTW). When I try to run any variant of this via telnet, smbmount gives me the "help" screen. I'm assuming that this is being invoked via a "mount" command, but I never see a mount command in the ps loops. I'm also assuming that the commands are getting cut off at PS's display limit, so I'm not actually getting the full command for either smbmount format.

Although smbmount's built-in help doesn't show it, there's actually a second "help" buried in the executable:
Usage: service <password> [options]
Version 2.0.7
-s smb.conf pathname to smb.conf file
-O socket_options socket options to use
-R name resolve order use these name resolution services only
-M host send a winpopup message to the host
-i scope use this NetBIOS scope
-N don't ask for a password
-n netbios name. Use this name as my netbios name
-d debuglevel set the debuglevel
-P connect to service as a printer
-p port connect to the specified port
-l log basename. Basename for log/debug files
-h Print this help message.
-I dest IP use this IP to connect to
-E write messages to stderr instead of stdout
-U username set the network username
-L host get a list of shares available on a host
-t terminal code terminal i/o code {sjis|euc|jis7|jis8|junet|hex}
-m max protocol set the max protocol level
-W workgroup set the workgroup name
-T<c|x>IXFqgbNan command line tar
-D directory start from directory
-c command string execute semicolon separated commands
-b xmit/send buffer changes the transmit/send buffer (default: 65520)

This is probably what "mount" is using, although it's possible that smbmount is being invoked differently by dvdplayer.bin directly.

EDIT:

I forgot to mention.. I've tried every variant of "mount -t smbfs" I could think of, with no success.

pb

icabrindus

07-19-06, 10:39 PM

I haven't yet tried to mount a cramfs image hosted on an SMB share.

..........

I'm apparently having some issues with shares and permissions on my computer though. One share mounts every single time via telnet, but the mountpoint is totally empty. Another share refuses to mount at all, even though everything is exactly the same.

pb

Hi!

You don't need to mount a cramfs on a SMB share, I think it's a lot easier to mount it from the local HDD.

Regarding the permissions issue, you can try to share a directory on a FAT partition (if you have one), just to avoid the NTFS level permissions. Or you can give everyone full permissions to the directory you are sharing.

gadgetmind

07-20-06, 06:18 AM

That's why it takes so damned long to enumerate the machines every time you start from main.

However, if you telnet in and run the command yourself (or from sashrc, say) then it will generate the hosts file for you.

And does this then make it quicker to "drill down" to the right share when using the TV interface?

Regards

Ian

pbarrette

07-20-06, 06:53 AM

Hi again,

I don't know what I did, but smbmount is working properly now. I'm using this format:
smbmount //machine/share /mntpoint password bar username foo rw

Unfortunately, running nbtscan does not make drilling down faster. That's because the MG35 is running the command itself every time you start from the main menu. It's built into the logic of "dvdplayer.bin" which is the main GUI interface. We could probably bypass that function, but a couple of things would be different.

First, you would need to have your smb mounts done in sashrc. Second, if your server was unreachable or down when the mount attempt was made, you would have to reboot the MG35 or telnet in and make the mount manually.

If we had access to the source code for dvdplayer.bin then we could add static smb mount points with user specified username and password fields. AL-Tech could easily add this in if they chose to do so.

If at all possible, I'd like to avoid the need for an additional disk image (cramfs or otherwise) on the HDD or from an SMB share. We have the ability to modify the original cramfs image as needed, and we can run test software from SMB, so there's little need. Mounting, say, a cramfs over the top of the /img directory during testing is one thing, but for "final" it only makes sense to keep things as simple as possible.

I'm guessing that the built-in NTFS driver is hard coded to always give an fmask of 0177, which is why I can't seem to mount it any other way. To bypass that restriction we would have to rebuild the kernel from source, or use a different NTFS driver.

The good news is that the linux-ntfs driver has been radically altered to provide full read/write capability with better performance than ext3 in the last few days. Check out linux-ntfs.org for details on ntfs-3g.

The downside is that the new ntfs driver requires the FUSE kernel module and would have to be built for uClinux. I expect that others will do this in the near future for their own needs and we can benefit from that. If we can get ntfs-3g running on the MG35, we can then add FTPd or SMBd and do away with NDAS emulation entirely.

pb

gadgetmind

07-20-06, 07:45 AM

Unfortunately, running nbtscan does not make drilling down faster. That's because the MG35 is running the command itself every time you start from the main menu.

Well, it's running something called nbtscan, but this doesn't have to be the program that dvdplayer thinks it is. :-)

The real nbtscan (renamed) could be run fram sashrc and told to just scan your actual servers, and the version of nbtscan that dvdplayer calls can just be a null function. (Something that just returns success - echo?)

It's probably worth making sure there is a fall-back .upgrade file on the HD before starting to play with any of this!

Ian

gadgetmind

07-20-06, 07:58 AM

The downside is that the new ntfs driver requires the FUSE kernel module and would have to be built for uClinux.

It's certainly been done. I'm on the OWFS (One Wire Filing System) list and people use the WRT54G router (uclinux on MIPS) with fuse/owfs. (I have all the hardware ready to build, but no time!)

So, building a fuse module for this version of ucLinux shouldn't be any massive hardship.

This guy has both patches and patched sources for download - http://home.mag.cx/uclinux/

Ian

gadgetmind

07-20-06, 10:40 AM

I think these are what I need to download

A version of uClinux with the right kernel version - I got this version number from a KISS list and the age looks about right.
http://www.uclinux.org/pub/uClinux/dist/uClinux-dist-20030909.tar.gz

And here are the ARM ELF tools, version 2.95.3
http://www.uclinux.org/pub/uClinux/arm-elf-tools/arm-elf-tools-20030314.sh

I'm getting a modified Fuse 1.4 from the URL i gave recently.

It's all downloading *really* slowly. :-(

If I get time this weekend (never guaranteed!) I'll try putting your firmware on my MG-35, building the fuse module with 2.95.3 and against the relevant kernel headers, also build the example, and see if it will run on the MG-35.

But it's worth mentioning, that cross compiling kernel modules is always tricky, and it's essential that compiler versions and kernel versions match, so the wheels could fall off rather quickly.

But if it works, I guess some brave soul needs to try building ntfs-3g!!! The biggest problem will be if it uses fork, but I can't really see why it should.

Ian

icabrindus

07-20-06, 11:04 AM

When I try to run any variant of this via telnet, smbmount gives me the "help" screen. I'm assuming that this is being invoked via a "mount" command, but I never see a mount command in the ps loops. I'm also assuming that the commands are getting cut off at PS's display limit, so I'm not actually getting the full command for either smbmount format.

pb
I don't know if this helps, since you already got it running :) but sash has its built-in -mount command. Maybe they are using that one. The confusing thing is that there is also a /bin/mount, which seems to be busybox.

batman1056

07-20-06, 04:55 PM

I've decided to go another route - bought a Divx player from Aldi (£30) with useb port - bopught an externa hd 250gig for £70 - job done ;)

EmuMannen

07-20-06, 07:10 PM

I started to take a look at the graphics. This will not be an easy task to customize. First of all, what needs to be customized and what are your expectations? There are 246 images totally in the latest Korean firmware. Quite some work to translate and customize. We are also dealing with originals of low resolution and color depth. Nice graphics requires high resolution and high color depth (or at least a reasonable color depth).

The backdrops are 720x480 pixels, 8 bit RGB in JPEG format. The rest is PNG images using an 8 bit indexed palette. These pictures do not contain any colors (more or less) when you look at them in an image editor. Outlines or highlights that are aqua marine or green on the screen are just shades of gray in the pictures. I guess that’s because MG-35 assigns a palette to these pictures before they are rendered on screen. We need to gain control of this palette before we can expect any custom colors of these PNG images if that is so.

I have no idea if it would be possible to exchange the PNG files with JPEG files (PNG is capable of alpha channels but it looks like they might use an indexed color for transparency in the overlay images, maybe both). It looks like the MG-35 uses the individual palette of the JPEG files but it could also be mapped towards a common system palette (programmatically defined in runtime).

I have compiled all graphics from the 144-ENG and 145-KOR firmwares and also made web based galleries for reference (since it’s not that easy to browse the originals for a preview). These files are uploaded to the new file area “MG-35 Graphics” at Yahoo Groups. (http://groups.yahoo.com/group/mg-35_firmware_mods/files/MG-35%20Graphics/)

pbarrette

07-20-06, 07:12 PM

Hi everyone,

I have added a new firmware image to the yahoo group.

This firmware is smaller than the last, but adds more features. This is because I replaced the stock busybox entirely and used a new busybox with telnetd built in. I also replaced the ftp server with a smaller, better featured pure-ftpd. Both the new busybox and the pure-ftpd binaries come from the KiSS firmware project.

The new busybox doesn't have "route" built in, so that is completely gone. Initial testing shows that the MG35 doesn't seem to miss it. I am still able to connect to SMB shares and use NDAS. If we need it later, I'll add it back in, but right now it's not being missed.

The telnet server is essentially the same as the last mod.

I removed all the old /bin and /sbin hardlinks and replaced them with symlinks to the new busybox. So while the shell is the same old sash, some things are slightly different. For instance, ls now displays in ANSI colors.

The new busybox contains the lash shell. I like lash better while in a telnet session because it handles pipes and redirects, supports tab completion, command history, correct handling of backspace in wrapped lines, etc. I hadn't looked that closely at it before building the image, so the next image will probably use lash as the telnet shell.

The FTP server allows full anonymous access to the root filesystem. Right now, there isn't much of a problem with that since there's likely little to damage. Most of the filesystem is read-only and it can be restored to it's original state with a simple reboot.

For downloading files from the MG35, the FTP server has a speed advantage over NDAS. I did a test copy of a ~750MB file via both NDAS and FTP. The NDAS copy took ~9.5 minutes and transferred at ~1.3MB/s while FTP took ~7mins at ~1.7MB/s. Keep in mind that my MG35 is connected to a WRT54G, which in turn is connected via WDS to another WRT54G before it hits my PC.

On the other hand, the NDAS implementation had roughly half the CPU usage (24%) of the FTP transfer (55%). So the additional speed comes at a cost in processing power. This basically means that you probably shouldn't do anything to tax the CPU while transferring large files via FTP.

I also added a /mnt directory for user mounts and created /hdd as a symlink to /cdrom because it makes sense. Who looks in /cdrom for the HDD? It's probably left over code from DVD player implementations that AL-Tech was too lazy to change.

pb

teddystacker

07-20-06, 08:25 PM

@EmuMannen and PB..

Great work again guys..

As you can Imagine, the 20mb (Yes I am the Dongo,I admit it,I thought it was 20 gig durrrr) file space at the Yahoo group is filling up really fast.But I have solved the problem, so we can still maintain a archive of this stuff without any hosting problems..

A new feature of Rapidshare allows you to Browse folders - So I have created a MG35 section where all firmwares Produced will be mirrored as soon as they are uploaded to the Yahoo group.
I will only keep the latest TWO Firmware on the Yahoo group,older ones will be mirrored at Rapidshare and deleted from the Yahoo group in prder to maintain some free upload space..
Of cource the Rapidshare mirror link will be in the files section and also links section of the Yahoo group..

Here is the link for the Rapidshare mirror - These files are permanate and will NOT expire..

http://rapidshare.de/users/PMS73Q

@PB , I have made you a mod at the Yahoo group,should you need to delete any older firmware to make space for newer..

@EmuMannen

Thanks for taking a early look at this , For me the current GUI is so poor that ANY Improvement will be better,even if there are just better colours than that "Battleship
Gray" background..

I will be away till Monday Camping in SE PA , at the speed this project is progressing,I guess there will be alot to catch up with when I return , take care all and have a great weekend...

pbarrette

07-20-06, 08:38 PM

Hi EmuMannen,

Don't worry about the images too much..

I was hoping that we would be able to (at a minimum) change the Korean text in the images into English and inject them into the v145 firmware, thus gaining an English v145 with the additional features added for the Korean market.

Since most of the images are interchangeable between the v144 and v145 (same name, dimensions, etc. w/ different language text), I grabbed only the "new" images in the v145 firmware and attempted a conversion to English. Then I packaged it all up into a new firmware file and loaded my MG35.

I then found out that my colors and transparency were totally off. But, more importantly, I couldn't find the "language" option in the setup to get the text into English. That's when I started digging into the v145 dvdplayer.bin and discovered that there are no other languages supported in v145. The GUI executable simply doesn't contain the English menu strings. There are large zero'ed blocks in the file as well. So it looks like there are placeholders for the additional languages, but they weren't compiled in.

So.. Changing the v145 GUI into English is not really possible.

My next plan is to start experimenting with GUI's built for other EM85xx devices. I plan to do this by killing the dvdplayer.bin and launching the others via the telnet interface.

As a side effect of loading the Korean firmware, I ended up loading the Freecom v143 firmware to get back to English. While on that firmware, I noticed that the remote was a lot more responsive than it is with the AL-Tech v144 firmware. The Freecom v143 and the AL-Tech v144 aren't really that different, so I think I'll have a look at the fip interface as well.

I'd be a lot happier about all these mod/flash cycles if someone figures out the serial/jtag interface on these things.

pb

teddystacker

07-20-06, 10:28 PM

@PB

Something I noticed in the graphics , there was a USBoff, USBon and USBdisable icon? , any idea where this is used? , or do you think its a feature we do not know about?

pbarrette

07-20-06, 10:42 PM

Hi teddy,

I think that most of the EM8xxx based players share a lot of the exact same codebase, even down to the images. Sigma probably put out a base development kit and the USB images were part of the default build.

I don't think the MG35 is capable of hosting USB devices because it simply doesn't have the right hardware. The USB controller on the board is a simple USB/IDE bidge, so there's no way for it to respond with the correct data to another USB/IDE bridge.

It does mean that the Sigma chipset is capable of using a USB-Host IC, but AL-Tech decided not to use one. It probably saved them a few pennies per IC as well as some time in development.

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

@EmuMannen ,

I have added a zip file to the yahoo group in the graphics section. There were a few scattered PNG images in the different firmwares which contained palette information. Across all the images with palette info, I only found 2 different palettes which are only barely different.

I saved the 2 different palettes in Paint Shop Pro (.pal) and Photoshop (.act) formats.

My guess is that the default palette is stored in the dvdplayer.bin file. I'll have to look into the file and see if I can extract it and potentially replace it.

pb

EmuMannen

07-21-06, 02:53 AM

@EmuMannen ,

I have added a zip file to the yahoo group in the graphics section. There were a few scattered PNG images in the different firmwares which contained palette information. Across all the images with palette info, I only found 2 different palettes which are only barely different.

I saved the 2 different palettes in Paint Shop Pro (.pal) and Photoshop (.act) formats.

My guess is that the default palette is stored in the dvdplayer.bin file. I'll have to look into the file and see if I can extract it and potentially replace it.

pbI will take a look at the palettes (quite funny that you have to fall back on PSP to be able to efficiently handle palettes, I have newer figured out how to do it properly in PS, even though I have used PS for more than 15 ears…).

One way to quickly explore the boundaries of the color capabilities (I guess we are stuck with a maximum resolution of 720x480 pixels) could be to make up a couple of test images and try them out on screen. JPEG backdrops could be made in both 8 bit and higher color depth just to test if it is possible to use higher color depth (or if the device will choke, dither or whatever).

A couple of the bigger PNG images could also be made as a 256 colors checker board. It would then be easy to study how they turn out on screen (what colors change, if any colors are used as transparence, if all colors are affected by the system palette or not, if the system palette changes or if it is static, if the PNG palette is used in any way or if it is totally overridden by the system palette etc.).

gadgetmind

07-21-06, 04:24 AM

I'd be a lot happier about all these mod/flash cycles if someone figures out the serial/jtag interface on these things.

On that subject, do we have read access to the flash? I guess CramFS is going through MTD, or is the compressed f/w image loaded into ram by the boot loader?

I'm starting to ask around regards cheap/free ARM JTAG hardware and flashing tools. I'm also lurking on eBay to try and buy a second MG-35 for experiments.

But if the worst comes to the worst, I can always program and fit new flash chips, but ideally would like a binary of the whole firmware (as it is in the flash chips) first.

Ian

zand

07-21-06, 04:50 AM

My next plan is to start experimenting with GUI's built for other EM85xx devices. I plan to do this by killing the dvdplayer.bin and launching the others via the telnet interface.

pb

If it could help, if you search google (sorry, i can't post urls yet) for "hv0102 mediabox" you'll find at the second result a site that contains a lot of firmware and grapihcs menu for devices similar to the freecom (sigma em8511 etc.).

EmuMannen

07-21-06, 05:13 AM

I spent some time following up on the palette information provided by pbarrette. Looks like both could be valid system palettes but there are some anomalies. Applying the palette information and saving the images in PS makes it possible to browse them with Explorer etc. (therefore no need for additional web gallery etc.). I uploaded the Korean images with applied palette information to Yahoo Groups. Please read the attached readme.txt (quoted below):

PNG images extracted from the Korean 145 firmware and flatten to one single directory (.\Images).

The palettes MG35a.act and MG35b.act were tested with similar result. The palette applied to the images in the .\Images directory is MG35b.act. It looks ok for most of the pictures but not all (se list at end of file). The question is if these files are used or not by the device and what palette is used if the files are used. Worth noting is that these files are missing in the 144 English firmware (are they new or “leftovers” from a dev kit?).

Other things worth noting:

1. It is possible to browse the pictures with Explorer etc. when the pictures have been saved with the palette assigned to them. Wonder why the images are not saved with this palette information in the first place (is the palette information truncated to save space? Is that the reason why the originals are hard to browse in the first place? I haven’t had time to investigate further yet…).

2. The image “gadawin2.png” is a bit special, it is a PNG but it’s not in 8 bit indexed format, it is in 8 bit RGB format. It also looks as it might contain an alpha channel (might be a semitransparent overlay). Maybe it’s possible to use images in RGB format with alpha channels for the rest of the graphics too (maybe even with a greater color depth than 8 bit). That would be cool but will increase the size of the images dramatically (probably breaking the boundary of available memory, not counting HDD or remote shares).

List of images that look “wrong” with the applied palette:

audoff.png
audon.png
audselect.png
diskdisable.png
diskoff.png
diskon.png
foldericon.png
list_local.png
list_network.png
netdiskdisable.png
netdiskoff.png
netdiskon.png
photooff.png
photoon.png
photoselect.png
playalloff.png
playallon.png
playlistoff.png
playliston.png
playlistselect.png
remalloff.png
remallon.png
return.png
returnoff.png
returnon.png
shuffleplayoff.png
shuffleplayon.png
usbdisable.png
usboff.png
usbon.png
vidon.png
vidselect.png
viewplayoff.png
viewplayon.png

Ps. I guess it is pretty safe to assume that palette index number 254 (magenta, #FF00FF) is used as transparency for the overlays (assuming a zero index for the first color in the palette).

EmuMannen

07-21-06, 06:23 AM

More information on PNG files... I now know why the original ones are hard to browse. The IHDR chunk identify it as color type 3 = paletted but most PNG images lack the PLTE chunk before the IDAT chunk. As a matter of fact, the PLTE chunk is totally missing in these images (it might have been removed to save space). Some images (e.g. arrow_w.png) do contain palette information in a valid PLTE chunk. I wonder if the system palette is read from any of the images or if it is hard coded?

Ps. The image “gadawin2.png” is identified as color type 6 = RGB + alpha (in the IHDR chunk). It also contains pHYs (72x72 dpi), iCCP (Photoshop ICC profile), gAMA (gamma value is 0.45470) and cHRM (white point x=0.31269, y=0.32899; red x=0.63999, y=0.33000; green x=0.21000, y=0.71000; blue x=0.14999, y=0.05999) chunks...

Pps. The images that look "wrong" with the applied palette (audon.png etc.) is identified as color type 3 = paletted and do contain pHYs, gAMA and cHRM chunks but no PLTE chunk...

Ppps. No use of the tRNS chunk for indexed transparency or bKGD chunk for default background color... Is size really that important?

EmuMannen

07-21-06, 07:36 AM

Thanks for taking a early look at this , For me the current GUI is so poor that ANY Improvement will be better,even if there are just better colours than that "Battleship Gray" background..
Revamping the current GUI should be much easier than a total overhaul. The major hurdles right now is size constraints and control over the palette. It would be really nice if we could gain control over the palette (since it today mainly consist of shades of gray, cyan and some green and yellow…). Any preferable color scheme (e.g. Ubuntu Human brown and orange etc.)?

teddystacker

07-21-06, 08:20 AM

Revamping the current GUI should be much easier than a total overhaul. The major hurdles right now is size constraints and control over the palette. It would be really nice if we could gain control over the palette (since it today mainly consist of shades of gray, cyan and some green and yellow…). Any preferable color scheme (e.g. Ubuntu Human brown and orange etc.)?

Yes I would just be happy with a "overhaul" for now..
I always liked the look of the Tvisto Colour Scheme as shown here:

http://lib.store.yahoo.net/lib/supermediastore/051215pic.gif

Ie The Gold , Blue.Black and white - Just looks so much more pleasing,and is much easier to read then the MG-35 one even though ot may not be using many more colours.

@PB

Ref the USB , I was thinking more along the lines that there might be a hidden "USB switch" ie a better method of Turning the MG-35 from USB mode into TV mode.I have mine connected to my network via a 15ft USB repeater cable,and at the moment,the only way of switching the MG35 from one mode to another is my yanking the USB connector out of either the PC end or the MG-35 end - just wondered if there might be another soloution providen by these icons?

Slightly off topic , but interesting - While looking for The above Tvisto screen shot , I found the read_me update files for the Tvisto firmware updates , interesting to see that they update their Xvid/Divx codecs regular and also some cool features like Auto play..

http://www.macpower.com.tw/files/firmware/firmware_history.txt

Ok I am off now , the Yahoo group is now 61% full , so you guys , dont work too hard :-)

regards to all...

gadgetmind

07-21-06, 09:16 AM

My initial attempts at building fuse for this kernel have failed.

. I downloaded the kernel and config from the Kiss firmware project (2.4.17-uc0)
. I downloaded the arm 2.95.3 binary tools from the uClinux site
. I downloaded fuse 1.4 from the other URL I gave, applied the patches that were needed for the WRT54G and then configured as follows -

configure CC=arm-elf-gcc LD=arm-elf-gcc --host=arm-uclinux --with-kernel=/home/xxxxx/MG-35/Kiss/uClinux-2.4

The make seemed to work for fuse.o but failed later in some utils. I think we only need fuse.o, so I moved it to a share and tried to insmod it.

insmod: unresolved symbol main
insmod: unresolved symbol page_cache_release
insmod: unresolved symbol BUG_ON
insmod: unresolved symbol filemap_fdatasync
insmod: unresolved symbol filemap_fdatawait

Dunno what I did wrong. I'm no great expert on module building, have never really meet uClinux before, and have never really used ARM much!

I must admit I'm not even sure the build of fuse.o was correct for uClinux - what does all the flt stuff happen?

Ian

EmuMannen

07-21-06, 09:31 AM

Dunno what I did wrong. I'm no great expert on module building...This might be helpful... Kernel Compilation & Avoiding ‘Unresolved Symbol’ (http://www.freeos.com/articles/4794/)

gadgetmind

07-21-06, 10:07 AM

This might be helpful... Kernel Compilation & Avoiding ‘Unresolved Symbol’ (http://www.freeos.com/articles/4794/)

I *think* I've done a fair bit of this, but of course I'm cross compiling.

The chap who got it going for the WRT54G didn't manage to get it working with configure and wrote his own make file. I may try interbreeding his make file with my autoconf generated one and seeing what happens. :-)

Ian

pbarrette

07-21-06, 04:45 PM

Hi EmuMannen,

I think I've found the system palette in "dvdplayer.bin". It's an exact match to the "MG35a" variant that I found in the images.

It looks like there are a couple of other palette options for lower bit depths as well. That is, I think I may have found a palette for 2, 4 and 16 color images in addition to the 256.

I remember looking at a number of your "non conforming" images earlier and I don't remember seeing them in the GUI, so they may not be used. That said, a number of them are listed in "dvdplayer.bin". So either there are hidden features, or (more likely) the listing is part of a default table and the entries were never removed.

I'm going to bet on the latter since dvdplayer.bin also tries "/sbin/insmod /kernel/drivers/usb/hc_isp116x.o", but that kernel module doesn't exist and the MG35 doesn't have a Phillips isp116x USB host controller IC.

Either way, I feel pretty confident that I can replace the system palette in the GUI. So if you want to try a different palette, just let me know.

pb

outthere

07-22-06, 02:55 AM

Hi guys,
This is my first post here. I have had my MG-35 for a few months now and really like it. I am sooo exicted to see all the hard work you all are doing to expand what this device can do. Kudos to you all.
I was wondering if at some point maybe you could make it to where you can stream internet radio from it. I have a modded xbox and that was one of the things I liked about it. Just a thought.
Keep up the great work!

EmuMannen

07-22-06, 03:33 AM

Either way, I feel pretty confident that I can replace the system palette in the GUI. So if you want to try a different palette, just let me know.
This is really good news because new graphics opportunities would have been seriously crippled without control over the palette. We now got enough information to actually make a simple revamp of the existing graphics (a new palette maybe in conjunction with some new graphics). The only thing needed is hard work, time, patience and some talent.

There are still questions worth answering though. We don’t know if the device is honoring built in palettes in the PNG files since the majority lack palette information and the few that got the information go more or less the same palette. Is that because they wanted to maintain one common systems palette or is it because they wanted to save space? We don’t know yet what would happen if we inserted an image with a different palette. Will it be rendered with the “systems palette” or with its built in palette? That is a pretty interesting question.

Another interesting question is if the rendering routines honors features not used in the original images. What if an image would be defined with PNG transparency? Will drawing routines honor binary transparency for 8 bit images? Is it even possible to use 24 bit images and alpha transparency? I guess that the rendering routines use some standard lib for PNG and JPEG images. Just because the developers didn’t make use of some of the features of the PNG spec doesn’t mean that the rendering routines don’t support them.

We might be stuck with an 8 bit systems palette and binary transparency indexed to palette entry number 254 but we don’t know that yet. I will se if I can get some time to put together a couple of test images that could be used to verify the boundaries of our options. Is anyone willing to try them out for me (I can’t try them out on my own MG-35 right now since my kids would kill me if I toasted it)?

gadgetmind

07-22-06, 06:14 AM

I've been having a close look and a meter of J9.

Pin 1 is the one with the silk screen arrow on the top, it's nearest the corner of the PCB, and it has a square pan on the bottom side. The other pins are then numbered alternatively, so pin 9 and 10 are the two on the far end of the connector.

1 - Signal
2 - Signal
3 - VCC (don't know level but meters ar 0 ohms to the large pad of the U7 reg on the far side of the board)
4 - NC
5 - Signal
6 - Signal
7 - Gnd
8 - NC
9 - NC
10 - NC

The four pins I have labelled "signal" are tracked on the top surface of the board to a set of vias, then go to the bottom side, and all seem to head towards the EM8511. Sorry if this seems vague, but the tracks go under a load of silk screen and are hard to follow.

However, it's very much looking like these are serial with handshake. So, I guess I need to get a 3.3V serial level shifter and see what I can do. I should be able to sort out the inputs and outputs by using a weak pull up/down and seeing how much it can move the voltage on the pin. An output shouldn't move much but an input should be able to be pulled rail to rail.

That then gives only four possible arrangements of the relevant data and handshake lines. Oh, and a whole load of options for data rate, stop bits, etc.!

I'm going to reassemble my Mg-35 now but will fit a "serial" extender cable next time I'm in there.

Ian

gadgetmind

07-22-06, 06:18 AM

insmod: unresolved symbol main
insmod: unresolved symbol page_cache_release
insmod: unresolved symbol BUG_ON
insmod: unresolved symbol filemap_fdatasync
insmod: unresolved symbol filemap_fdatawait

Ian

I suspect that main and BUG_ON may be due to me building it wrong, but page_cache_release is definitely used by fuse and definitely not in /proc/ksyms.

But I may try building a simpler "hello world" loadable module just to get a better feel for where I might be going wrong.

It's a crying shame that Alltech haven't released their exact kernel sources and exact .config - this would make building a new kernel dead easy.

Ian

EmuMannen

07-22-06, 11:46 AM

Continued work on the original graphics (not got time to make any new ones yet). I wanted to give the palette another go and also try to find a way to handle file size issues.

I think we can use the submitted “MG35a.act” as the default “systems palette” so I batch processed all PNG files so that they all got this palette in a valid PLTE chunk. I did this with Photoshop and it also attached a bunch of ancillary chunks (pHYs, iCCP, gAMA, cHRM). The result was total file size of 1.06 MB for the 144 eng firmware graphics. That is a 100% increase compared to the original total sum of 534 kB!

The PNG files can easily be recompressed and optimized lossless to even less than the total original size but to the price of truncated palette information (PLTE chunks will only contain the colors used in the picture). This might interfere with how MG-35 is handling transparency since the original data doesn’t contain any tRNS chunks! My guess is that palette index 254 is used instead and that makes it hard to optimize palettes in individual PNG files (but I ma be wrong on this one).

What I did next was to maintain the full “system palette” but I removed all ancillary chunks and recompressed data using more efficient compression strategies. That brought me back to a total file size of 616 kB!

I have compiled new graphics pack with these post processed images and uploaded them to Yahoo Groups (invalidating the old packs that I have removed). I also included palette files in Photoshop and Pain Shop Pro format in the zip files. I thin these packs are a pretty good foundation for anyone that would like to develop custom graphics for the MG-35. It is always easier to work with 8 bit files that contain valid palette information.

I think that the JPEG images also could be post processed to minimize file size. That would bring us down to a smaller size than the original graphics but with every file conforming to the PNG and JPEG standards (making them easier to process).

Ps. I would appreciate if some one could try to use the post processed graphics uploaded to Yahoo Groups in a custom made firmware to verify that the processed images do work with the firmware.

pbarrette

07-22-06, 05:19 PM

Hi EmuMannen,

The images worked fine for me.

Granted, I didn't actually create a new firmware image. Instead, I used smbmount to overlay the /img directory. That said, the transparency seems to be correct in the images and everything looks identical to stock in my limited testing.

I think a better test would be to try a totally different color scheme for a few key images, yet keep the pink transparency color at the same index. Then we would be able to tell if it's actually reading the palette in the PNG or replacing it with the system palette.

The GUI uses libpng version 1.0.12 to display the images, so assuming the system palette can be overridden, you should have whatever options are available in that lib. The JPEG handler is from libJPEG v6b, BTW.

The png filenames are hardcoded into dvdplayer.bin. I suppose I could try changing one to jpg to see what happens, but I don't expect good things from that. I'm guessing there's a hard jump that runs something like: "Load image.png -> call png decoder". Changing the file and filename to jpg may still run the same "call png decoder" bit, which would end up with unknown results.

Then again, it may say "load image.ext -> what ext is that? -> decode ext". Transparency would probably get applied from the system palette though, so we'd be boned there.

pb

EmuMannen

07-22-06, 06:28 PM

pbarrette, I have made some simple test images that I have uploaded to Yahoo Groups. The zip-file contains the readme-file quoted below:

Some simple test images for the MG-35 project:

Test 1: “mediabackground.jpg” (goes in /img/) used as backdrop in mode selection menu. Check the rainbow colored gradient. Does it show seamless and smooth using the whole JPEG RGB palette or is it dithered etc.

Test 2: 8-bit “pc1.png” and “pc2.png” (goes in /img/lib/) used as selected and not selected PC-Network glyph in mode selection menu. Switch between selected and none selected to be able to observe how different PNG files are handled. “pc1.png” uses the stock “systems palette” and should turn up with a green gradient on top with a transparent square in the darkest part. “pc2.png” uses a custom palette and a tRNS chunk to define transparency. Does it show up with a red gradient on top or a green one (remapped to “systems palette”)? Is the square still transparent (does rendering routines honor the tRNS chunk)?

Test 3: 24-bit “pc1.png” and “pc2.png” (goes in /img/lib/) used as selected and not selected PC-Network glyph in mode selection menu. “pc1.png” and “pc2.png” is both 24-bit PNG files with alpha channel defining transparency. Is it possible to use 24-bit images instead of 8-bit? Do they show up, do the colors look good, is transparency working?

pbarrette

07-22-06, 07:05 PM

Hi EmuMannen,

Test #1: The rainbow gradient is as smooth as it's going to get on my 50" Pioneer plasma screen.

Test #2: Both boxes were green (overlayed with sytems palette). One center square was transparent, the other was dark green (ignored tRNS chunk).

Test #3: Images didn't display correctly, but they weren't totally unrecognizable..

Test-3 Not selected:
http://peterbarrette.com/MG35/24bit-PNG-test-sm.jpg (http://peterbarrette.com/MG35/24bit-PNG-test.jpg)

Test-3 Selected:
http://peterbarrette.com/MG35/24bit-PNG-test2-sm.jpg (http://peterbarrette.com/MG35/24bit-PNG-test2.jpg)

pb

EmuMannen

07-23-06, 02:50 AM

Thanks pbarrette, worst case scenario as I see it. Using a fixed palette index for transparency (that’s soo old school) at the end of the palette makes it impossible to optimize palette chunks in order to reduce file size (why did they have to do it that way?)!

Looks like we are stuck with 8-bit PNG graphics with a fixed systems palette overlaid on top of true color JPEG backdrops. It’s not hopeless to work with but it sure makes it harder to make nice graphics...

There is just one more thing I would like to know and that is the palette indexes used when rendering text in the GUI. It looks to me as if it is mostly black and white. Maybe they only use index 0 (white) and index 255 (black). I guess it’s a question of try-and-error to find out...

DevilsOwn

07-23-06, 06:17 AM

Let me just start be saying I am overwhelmed with what you PB and all you others have come up with so far for the mg-35 I am hoping I can help you out with some web space, I have 950mb of web space and I get 25gigs of bandwidth per month, I have done up a site for the MG, feel free to have a look and tell me if it would help all you guys out?? the url is in the title, sorry the only way i could put the url in as of the 5 post rule:(

EmuMannen

07-23-06, 08:46 AM

I just uploaded some test graphics to Yahoo Groups. They are intended for testing of how new graphics made out of high color graphics but down converted to a common 8-bit palette might turn out on screen (and is also a test of my work flow for how to develop several 8-bit PNG images with a common palette correlated to a high color JPEG backdrop). Quoted below is the readme.txt:

This is graphics for a new "Mode Select Menu" using new images with a new common palette. System palette has to be changed to "new-palette.act" (and will screw up the colors of the rest of the GUI but this is just for testing how well or bad high color graphics show up on screen when down converted to a common 8-bit palette).

Ps. This is just a quick mockup of some new images for the GUI. This is not what I had in mind for the final color scheme etc.

J. L.

07-23-06, 08:53 AM

Just an FYI for all who are upgrading their MG-35's with new firmware...

I found an interesting item while I was reading through the older posts on the MG-35 having just purchased two of the units. I am excited by all the work being done here and thank all of you.

According to this post : http://www.avsforum.com/avs-vb/showthread.php?t=648630&highlight=mediagate
you do NOT want to lose power in the middle of an upgrade. As many have suspected, it is possible to turn the MG-35 into a brick if the upgrade process is interrupted by a loss of power.

I'm not sure if the person who started that thread ever got their unit going again, but I suspect not.

I would (strongly) suggest the MG-35 be powered from a UPS when doing the upgrade of its firmware. If reading the .upgrade file from a network share it would probably be a really good idea to have the PC with the .upgrade file and the router/switch on the UPS too. I personally plan on moving the .upgrade file to the internal disk and doing the upgrade from there, to eliminate any network issue from getting in the way of a successful upgrade.

I know the odds of a power outage at the time you are doing a firmware upgrade is slim, but unless you use a UPS, apparently, not zero.

Joe L.

gadgetmind

07-23-06, 09:11 AM

I suspect that a unit that's scrambled such that there is no firmware at all is a lost cause without JTAG and some software directly downloaded to program the flash.

But if the loader is intact, recovery via serial should be possible.

I have just ordered an RS232 level converter from eBay (£11 incl delivery from Canada to UK) I'm then going to work out which pin is which on the serial connector (assuming it is serial!) and see if a Linux console will talk to me. If it does, then I can see how far I can get with talking to the boot loader.

BTW, does anyone know the syntax of the smbmount command for if I want to write to an SMB share. It's currently a bit hard to get information back off the box - I've been reverting to pipeing commands into telnet with echo and then redirecting the output!

Ian

icabrindus

07-23-06, 09:25 AM

I've been having a close look and a meter of J9.

Pin 1 is the one with the silk screen arrow on the top, it's nearest the corner of the PCB, and it has a square pan on the bottom side. The other pins are then numbered alternatively, so pin 9 and 10 are the two on the far end of the connector.

1 - Signal
2 - Signal
3 - VCC (don't know level but meters ar 0 ohms to the large pad of the U7 reg on the far side of the board)
4 - NC
5 - Signal
6 - Signal
7 - Gnd
8 - NC
9 - NC
10 - NC

The four pins I have labelled "signal" are tracked on the top surface of the board to a set of vias, then go to the bottom side, and all seem to head towards the EM8511. Sorry if this seems vague, but the tracks go under a load of silk screen and are hard to follow.

Ian

Here are the voltages, for J9 and J7, using the same numbering:

J9
1 - 3.27V Signal
2 - 3.27V Signal
3 - 3.27V VCC
4 - NC
5 - 0.00 Signal
6 - 0.00 Signal
7 - Gnd
8 - NC
9 - NC
10 - NC
The NC pins seem to be really NC, they are going to 50mV with my finger pull-up :-) The signal pins don't care about it, so they seem to have some internal pull-up/down (passive or active). So it seems the signals are consistent with a serial i/f.

J7
1 - 3.05V Signal
2 - Gnd
3 - 0.04V Signal
4 - 3.27V Vcc
5 - 3.03V Signal
6 - NC ?
7 - NC ?
8 - NC ?
9 - 3.03V Signal
10 - Gnd

Pins 1, 3, 5 and 9 have traces that go under the EPM3032A chip.
Pin 3 is strange, when I touch it with my finger it goes to 1.3V, but if I put the bare foot on the ground, it even goes to 1.7V. Maybe it's some high frequency there? Someone with a scope around?