The guy who wrote the bootloader seems to be called Ho Lee (aka Flyduck) and this is confirmed by it saying Flyduck towards the end of the boot rom.

Here resume is as per title
(From google cache as flyduck.com seems to be poorly)

There is a *lot* of stuff in the boot ROM.

There seem to be a fair few command shells, ethernet drivers, IDE drivers, bootp client, and tftp protocols.

Near the tftp stuff is en entry that reads - /home/tftp/bigmo/romfs.m35

Has anyone seem the MG-35 make any attempt to perform tftp when booting? I have bootp and tftp servers running but wouldn't like to risk letting the MG-35 download a file with that name for fear it would flash it!

Ian

About Mr. Ho Lee (quoted from Google cache):

Ho Lee

440 Dixon Landing Rd APT C106, Milpitas, CA 95035
E-MAIL : flyduck@linuxkernel.net
TEL : 408-586-9876
PROFESSIONAL OBJECTIVE
Linux kernel / Linux device drivers / Embedded system software

PROFILE
A software engineer with 10 years of extensive work experience in both of system programming and application programming. During former 4 years, mainly involved in designing and implementing large application software such as wordprocessor. For the recent 6 years, have developed embedded systems and device drivers, and hacked Linux kernel. Have an insight into operating systems especially into Linux and have excellent programming abilities in C, C++, and assembly language.

SKILLS

* Expert in developing embedded Linux, Linux device drivers and Linux kernel modules. Experience in Linux device drivers for MPEG, IDE, SCSI, frame buffer, and flash memory. Experience in various platforms including ARM, StrongARM, MIPS, Alpha and x86.
* Experience in modifying Linux kernel including memory manager, PCI subsystem and IDE subsystem.
* Experience in the development of boot loader for x86, ARM and StrongARM.
* Knowlege of hardware architecture and experience in hardware debugging. Knowledge of many hardware protocols and standards such as PCI, ATA/ATAPI, SCSI, USB, IEEE1394, and etc.
* Experience in Linux system programming and network programming.
* Knowledge of VxWorks system and experience in VxWorks device drivers.
* Experience in Windows 9x and Windows NT device drivers.
* Experience in Windows CE.
* Experience in Windows application development using Win32 SDK and MFC.
* Experience in source code management through CVS and other RCS tools.
* Expert in C, C++ and x86/ARM assembly language.
* Programming capabilities of PHP, Perl, Python, HTML, and shell scripts.

WORK EXPERIENCE

SkyStream Networks, Inc
Senior Software Engineer / Apr 2004 - Present

Sigma Designs, Inc
Software engineer / Aug 2002 - Apr 2004
o Responsible for boot loader for EM86xx MPEG processor with ARM7 core. Boot loader supports IDE disk, serial and parallel flash update, PCI bus scanning, and many debugging and board testing functionality.
o Responsible for uClinux kernel for EM86xx. Wrote all the architecture dependent codes, and implemented EM86xx specific PCI host controller, IDE, UART and MTD driver. Modified kernel for fast boot and better performance. Also modified memory manager for robust memory management with NUMA and LARGEMEM support. Tested many PCI based device drivers including ethernet, USB and wireless.
o Found and analyzed the many chip bugs, and helped hardware engineers fix the bugs.
o Ported Davicom ethernet device driver for EM85xx MPEG processor.
o Implemented UDP/IP networking with DHCP and TFTP protocol support inside boot loader.
o Developed host side device drivers for EM86xx PCI card.

LinuxOne, Ltd
Linux software engineer, consultant / Mar 2000 - Mar 2002
o Participated in the PVR (Personal Video Recorder) project. Ported boot loader and Linux 2.4 kernel to StrongARM SA1100 and ITE8152 based system, and developed device drivers for serial, and MPEG encoder/decoder chipset.
o Participated in the StrongARM based DVR (Digital Video Recorder) project. Ported Cyberpro 5000 frame buffer device driver and configured IEEE 1394 network.
o Ported uClinux 2.2 kernel to ARM7 based multi-line traffic switch router.
o Responsible for Linux device driver for PCI-66 memory disk card. This driver operates under both Intel and Alpha environment. Developed SCSI target mode driver for LSI Logic 1010 SCSI host controller, and made memory disk cards detected and operate as a SCSI target device like a SCSI disk.
o Set up Linux based embedded system for MediaGX based internet settop box.
o Developed software module controlling LED and customer display in part of ticketing management system project.
o Managed localization of Vistasource Anyware into Korean.

Digitra Systems / Digital & Digital
Software Engineer / Jan 1999 - Feb 2000
o Ported Linux and PCI drivers for Tivo-like PVR system based on MIPS RM5231.
o Built VxWorks for SA1100 based settop box, and ported MPEG decoder device driver to VxWorks. Developed MPEG stream player for the settop box running under VxWorks.
o Responsible for DVB (Digital Video Broadcasting) compatible digital satellite TV receiver PCI card project. Developed user mode device drivers and application software driving hardware. Ported Windows 98 device driver to Windows NT 4.0

Freelancer
Jul 1998 - Dec 1998
o Configured Windows CE for railroad ticketing console settop-box based on Intel Pentium processor, and developed applications using MFC for Windows CE.
o Designed and developed communication protocol between mobile phone and PC, and developed Windows applications which controls, synchronizes and downloads information over serial line.

Hanmesoft, Ltd
Software Engineer / Feb 1996 - Jun 1998
o Developed core wordprocessor engine including data structure management, alignment, text and paragraph formatting, frame positioning, file I/O, and etc. Managed large software codes about 1.5 million lines.
o Developed wordprocessor user interfaces including ruler, toolbars, and dialog boxes. All the codes were written in C++ based on MFC library.

Hangul and Computer, Ltd
Software Engineer / Apr 1994 - Feb 1996
o Developed messaging system (mail & BBS) server as a NLM (NetWare Loadable Module) for Novell NetWare NOS, also client for Windows 95/Win32s. Designed and developed messaging protocol based on IPX/SPX communication protocol.
o Developed graphic and window library under DOS environment, and various applications based on this window library.

EDUCATION
Bachelor of Material Science and Engineering, 1996,
Seoul National University, Seoul, Korea

ADDITIONAL REMARKS

* Have been leading Linux kernel community (http://linuxkernel.net/) in Korea since 1999.
* Translated "Understanding the Linux Kernel" 1st and 2nd edition written by Daniel P. Bovet & Marco Cesati into Korean with a person.
* Translated "The Linux Kernel" written by David Rusling into Korean and published it as GPL.
* Wrote a guide to Linux kernel programming for students at educational institutes.

REFERENCES
Available and will be furnished upon request

Check this week's posts, pbarette managed to find it!

<blush>

Yup, so he did.

OK, now for my next stupid question. :-)

Is there any checksumming on files like dvdplayer.bin? I'd like to stop it calling nbtscan and also removing the contents of /net/ and am not sure whether to do this by replacing nbtscan or editing dvdplayer.bin

I guess the safest way is to mount an SMB share over /bin while I experiment with writing user-land programs for uClinux. I can then write an nbtscan replacement that puts the right entry into /hosts/hosts and creates the right directory in /net

Ian

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:(Sounds and looking good if you ask me but I let pbarrette decide if we should move to a new location...

J9
Someone with a scope around?

Yes, but at work. And my MG-35 PSU is tangled with everything else in the cupboard under the stairs, hence why I haven't done any metering myself. I'll try and take the whole lot to work one day once my RS232 level converter has arrived.

P.S. Anyone know why I can't post URLs?

Ian

P.S. Anyone know why I can't post URLs?
Probably site policy, you can always post links at Yahoo Groups (there is even a separate section for that)...

Hi all,

Ok, there are a lot of posts to address here, so let's see if I can do this in order:

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

@DevilsOwn,

Webspace = good idea. This project is getting to the point where a single thread in avsforum isn't cutting it. We should really have a separate forum with separate topics, etc. It would really help with the organization.

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

@EmuMannen,

I'll test out the graphics very soon. Last night I wrote a small utility to replace the palette in dvdplayer.bin anticipating this exact need. I'm not posting it yet since it's not quite ready for the public. It requires that you know the offset of the palette information in the executable and requires a Photoshop ACT format palette to be inserted. So it's perfect that you uploaded the palette in exactly the format I need.

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

@JL,

Losing power in the middle of a firmware upgrade would be very bad. It would be worse depending on what point in the upgrade the power was lost.

The .upgrade images seem to replace the bootloader as well as the filesystem. It would make a lot more sense to just replace the filesystem, so I don't know why they are doing it this way. If the bootloader is lost, then upgrading via serial would be impossible. You would then be left only with JTAG. Of course, we don't yet know how either are connected, so at this point a bad firmware load is not something we want.

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

@Gadgetmind,

Good luck on the serial port. I'd really like to get that working. Right now I don't want to alter too much in the firmware for fear that I won't be able to flash back.

I thought I had the smbmount command figured out, but now I'm not so sure. It seems that no matter what options I give, it is still connecting as an anonymous user. I hadn't even noticed since I was giving it username and password options. I discovered the problem just last night as I was trying to connect to a new share. I kept getting "access denied" until I changed my WinXP security policy and added my new share name to "Network Access: Shares that can be accessed anonymously".

I've tried space delimited opt-value pairs, comma delimited, opt=value, -o:opt[=][ ][,]value, you name it. Nothing seems to pass the username correctly. I think I'm going to have to start up Ethereal and read the packet data for different options.

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

@icabrindus (& gadgetmind),

I tore apart an old serial cellphone cable for a Nokia that I no longer have. It is basically an RS232 level shifter that draws power from the serial port. I tried connecting to a number of relevent pins on J9 while running hyperterminal and got nothing.

The /dev directory contains ttyAM0 and ttyAM1, so I was hoping to find a compatible "setty" binary to at least find the right lines. I figure if we start with a setty on the serial ports in linux, we will then know the baudrate, data/stop bits and parity. That should make it easier to find the right pinouts for the serial port. Once we get the serial port working under linux, it should be easier to find the settings for the bootloader.

Something else of note: There's also the "IR-EXT" phono jack on the back, but no options for external IR control in the GUI. I haven't even seen an accessory for sale. Plug in a stereo phono plug and you get (GND / +4.9v / +4.9v) from base to tip. It's possible that this could also be the serial port, so that may be worth looking into.

Of course, that also brings up the question of whether all the new ports on the MG-350 will actually be supported in the firmware. Ports on the box mean jack if you can't use them.

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

@gadgetmind,

I haven't seen the MG35 attempt a tftp or bootp session, but I haven't been looking either.

I noticed the "Ho Lee" (aka Flyduck) stuff as well and found some posts he made in other forums. From what I've seen, he hasn't posted any info that would be directly relevent to our needs. I suppose that someone could scour the web for everything he's ever posted to try to get an idea of how he "might" implement a bootloader. But it would probably be easier to just reverse it.

There is no checksumming (per se) on dvdplayer.bin, however.. It would be a better idea to build an executable that does nothing, accepts and ignores any parameters given and always exits with a success code.

Dvdplayer.bin is in bFLT format, so it has static pointers to the memory addresses of its variables. Changing the file too much could mean that the pointers start pointing to the wrong memory segments causing the program to crash. If the program crashes, we don't yet have a way to reflash without using the GUI.

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

If I missed anything, let me know.

pb

It would be a better idea to build an executable that does nothing, accepts and ignores any parameters given and always exits with a success code.

I think we already have this in the form of "echo" :-)

But the problem is that dvdplayer.bin does an rmdir /net/* before running nbtstat - I need a replacement that is quicker and goes straight to my video/music server.

Or maybe I could create /hosts/hosts with just my server in it, create a dir with the name of my server in /net and then chmod this dir to stop dvdplayer.bin from deleting it.

[later]
Hmm, I tried it and my test dir goes even if I chmod it to 444! However, it doesn't go this until I go up a level, so it's probably OK. A script that keep sleeping for a while and then recreates the dir should cover for me knobbling nbtstat.

Ian

About Mr. Ho Lee (quoted from Google cache):

Did anybody notice this in the his CV?

Sigma Designs, Inc
Software engineer / Aug 2002 - Apr 2004
...
o Implemented UDP/IP networking with DHCP and TFTP protocol support inside boot loader.
...

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.


Did anyone see the jumpers they are talking about in that thread? Or maybe they thought J9 are jumpers?

OTOH, I saw a component that I didn't recognize. It's between the EM8511 and the AV connectors, and has 3 colored dots on it (red, green and blue). Thought they are some diagnostic LEDs, but didn't see them turning on.

I tore apart an old serial cellphone cable for a Nokia that I no longer have. It is basically an RS232 level shifter that draws power from the serial port. I tried connecting to a number of relevent pins on J9 while running hyperterminal and got nothing.

The /dev directory contains ttyAM0 and ttyAM1, so I was hoping to find a compatible "setty" binary to at least find the right lines. I figure if we start with a setty on the serial ports in linux, we will then know the baudrate, data/stop bits and parity. That should make it easier to find the right pinouts for the serial port. Once we get the serial port working under linux, it should be easier to find the settings for the bootloader.


Here is a message from the boot.rom, maybe it helps you:
"valid baud rate : 9600, 19200, 38400 (default), 57600, 115200"
Even if you set the parity wrong, at least some of the characters should be OK...

Looking into it, seems that the bootloader does a lot of things. It has its own tcp/ip stack, commands for debugging and testing (including the read/write of serial EEPROM, flash block erase, memory dump, network config, tftp and many more). So if we get access to that, we have a powerful tool on hand!

download [media] <target> : download image via various media
[media] : serial / net (network)
<target> : boot / romfs / kernel / [addr]

So we can selectively load only one component, and then flash it (e.g reflash only the cramfs image, without touching the bootloader or the kernel):
flash [command] <options> : flash commands
probe <addr> : probe flash
list : show flash chip information
erase [addr] <len> : erase one or more sectors of flash memory
eraseall : erase all flash memory
writeb [addr] [data] : write one byte of data into specified address
writew [addr] [data] : write one word of data into specified even address
write [to] [from] [len] : write block of data into specified address
boot : write boot loader image on RAM into FLASH
romfs : write ROMFS image on RAM into FLASH

pb, can you "more /proc/mtd" ? Or, even better, /proc/* (ok, maybe not *, because there are some binary files there :-) but at least share with us the result of "ls /proc").

Are we able to use this at all to get NTFS RW:

sourceforge _dot_ net _dot_ mailarchive slash message.php?msg_id=29946970

M

Hi all,

Thank you very much for those who did the hard work so that we can start our advanture of customizing the firmware.
It's also the main reason for me to make up my mind to buy one last Friday.

For the mediagate mg-35 I bought in Canada, it's made in 2006 March. From the bottom, it included a label with MAC, NDAS ID and key. But I think it's not that important if ftpd can be enabled and it have write permission to the HD. (it's not too far away!)

From the linux-ntfs website, I read somewhere that the ntfs driver is read only and not good on writing back.
I don't know whether it's the reason that they mount ntfs partition as read only.

Is that anyone try to format their HD with FAT32 and see whether the mount is read only or RW? If no one tried it before, I will give it a try next week when I have time.

Hope that FAT32 partition can provide write permission and we can have a temp solution with ftpd.

Are we able to use this at all to get NTFS RW:

sourceforge _dot_ net _dot_ mailarchive slash message.php?msg_id=29946970

M

Yup, getting that working would be great, but it requires fuse, and I failed to get that working. I think I need to play with my link flags, but I'm also pretty sure that the kernel is failing to export some symbols that we need.

The only real fix for this is to build a new kernel. This isn't heavy duty rocket science, but without the actual source and actual .config, there will be some trial and error. Currently, errors would irreversibly brick the MG-35. This is why I'm shifting my efforts to the serial debug interface.

Ian

I tore apart an old serial cellphone cable for a Nokia that I no longer have. It is basically an RS232 level shifter that draws power from the serial port. I tried connecting to a number of relevent pins on J9 while running hyperterminal and got nothing.

The /dev directory contains ttyAM0 and ttyAM1, so I was hoping to find a compatible "setty" binary to at least find the right lines. I figure if we start with a setty on the serial ports in linux, we will then know the baudrate, data/stop bits and parity. That should make it easier to find the right pinouts for the serial port. Once we get the serial port working under linux, it should be easier to find the settings for the bootloader.



Were you snooping the pins as you booted the MG-35? I'm guessing that the loader will print a prompt and then wait briefly for a certainly character/string before continuing with the boot.

Maybe one of us (and it should be just one!) needs to try emailing flyduck?

Ian

By the way, has anyone done any experiments to understand the restrictions of writing with the NTFS driver that we have? I haven't got a HD in my unit or I'd have a play!

I think the early NTFS driver was OK on file read/create but was no good at extending files. We might not need this for FTP.

The fmask=0177 restriction is easily solved (as someone else pointed out) by having a cramfs image file on the HD and mounting this with loop - we can then have executables in this file.

Ian

I worked out what I'd done wrong building fuse and tried again. The main issue has gone away but the kernel still doesn't have the symbols for page_cache_release and the filemap stuff.

I then tried building an ext2 module. Again, the lack of pack_cache_release stopped the insmod working and we were also short of get_empty_inode.

This just underlines that anything fancy will require a kernel rebuild. No way would I even dream of attempting this without a fall-back boot solution.

Ian

Is that anyone try to format their HD with FAT32 and see whether the mount is read only or RW? If no one tried it before, I will give it a try next week when I have time.

Hope that FAT32 partition can provide write permission and we can have a temp solution with ftpd.

Please try and let us know! But the main limitation with FAT32 is the 4GB maximum filesize. So you will not be able to store a DVD ISO image on it.

According to Microsoft, you can format up to 4TB with FAT32. Windows XP has a 32GB limit, however, I found a nice small EXE (fat32format.exe)

See : ridgecrop _ demon _ co _ uk _/_ fat32format _ htm

Used it to format a 60GB disk for my DI-624S router that only supports FAT32.

M

Used it to format a 60GB disk for my DI-624S router that only supports FAT32.It's all about the maximum size of a single file on a FAT32 partition, max 4GB won't cut it when it comes to video media...

This is looking very good. At this moment it would be nice to customize the pictures in the firmware.

First one will be the startup pic: logontsc.jpg

If I am correct I need to do the following steps:

1) Split the firmware
2) Use FSExtractor to add picture to the cramfs.img
3) Merge with copy /b
4) Change correct hexcode to reflect (Linux.gz+Cramfs.img+4)
5) Calculate checksum for new firmware
6) Edit checksum found in firmware
7) Update firmware

I did step 1-3 and step 4 is not a problem, but I don't know how to run the code posted earlier to calculate the checksum. I am not a programmer, but like test when possible. I will keep reading this thread with great interest.

hi PB and all, the site is all up and going, all i need from you PB is the users that need ftp access for uploading the files ect.

Were you snooping the pins as you booted the MG-35? I'm guessing that the loader will print a prompt and then wait briefly for a certainly character/string before continuing with the boot.

Maybe one of us (and it should be just one!) needs to try emailing flyduck?

Ian

From the experience of someone who hack the linksys router, it can easily find the tx signal from the serial port. :cool:
Just use a speaker. Connect it to ground and one other signal pin. If it is the tx line, it will give out noise, then silent and noise again when you switch the unit on because the boot loader will print out something, wait for tftp and then continue to load kernel and print out system message.

It's all about the maximum size of a single file on a FAT32 partition, max 4GB won't cut it when it comes to video media...
If fat32 partition work as a temp solution, you can split the file and do the ftp. After that, telnet into mg-35 and do the join. For DVD, it's max of 8G and hopfully you can just split it into max 3 files and it not a big trouble to join 3 files. :p

From the experience of someone who hack the linksys router, it can easily find the tx signal from the serial port. :cool:
Just use a speaker. Connect it to ground and one other signal pin. If it is the tx line, it will give out noise, then silent and noise again when you switch the unit on because the boot loader will print out something, wait for tftp and then continue to load kernel and print out system message.

Neat idea, but we have lots of scopes at work, which should also let me see the data rate. However, wife and daughter will not appreciate me swiping the player for a day, so maybe the speaker is best after all!

Ian

As my player is from Freecom, a UK company, I have just made a request to them that they provide me with the GPL source code. Let's see what happens.

I bought the player directly from their web site, so they can't argue that they haven't made a binary distribution!

Ian

If fat32 partition work as a temp solution, you can split the file and do the ftp. After that, telnet into mg-35 and do the join. For DVD, it's max of 8G and hopfully you can just split it into max 3 files and it not a big trouble to join 3 files. :pI think you're still missing a basic concept. With a FAT32 partition, you can NEVER have a file larger than 4 gigs. It doesn't matter where the file was created, it can't be larger than the maximum for a FAT32 partition. Perhaps some reading on the various filesystems available and their limitations will help: http://en.wikipedia.org/wiki/File_Allocation_Table

Hi all,

My MG35 is now fried.

I was attempting to flash to AL-Tech's v1.4.4 stock firmware image that was located on the internal HDD. The unit said "Checking current firmware" then the screen went black. The power and HDD lights went out, but the LAN light was still lit.

I gave it about 5 minutes with no change in status. A firmware update usually takes me ~2 minutes to completion, so I gave it double that time just in case. All panel buttons were unresponsive, so I had to pull the power to turn it off. After plugging it back in and hitting the power button no lights come on and my TV stays blank. The HDD spins up, but that's it.

The firmware on the device was already the stock, AL-Tech v1.4.4, so I can only think of two reasons for this to have occurred:
1) The unit doesn't like to be flashed with the exact same firmware that is already loaded.
2) It's freaking hot in Germany at the moment, so perhaps a memory write went bad due to overheating.

Normally, I feel that it would be unethical to exchange a device that broke while attempting to reverse engineer it. However, in this case, I was using stock firmware and flashing to stock firmware, so I don't believe that this was my fault. In any case, I have no hardware to test for at least the next few days.

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

@gadgetmind,

I was snooping the pins in various states. While off, while booting, while running, while running "cat /dev/ttyAMx". I saw nothing. However, it could be that my hacked apart cellphone cable just isn't cutting it.

That said, at least we have a few clues. The Sigma GPL'ed kernel source code specifies "38400, 8, n" as the default for the "serial_jasper" device.

Also, after my device died, I decided to try to trace the pins for both jumper blocks. The Vcc for J7, J9 and the front panel all come from the same source: The voltage regulator at U7 stabilized by the electrolytic cap at C22.

I couldn't find a direct connection between any of the headers to any of the test pads, nor to any of the IC pins. Something else to note is the fact that this looks like a 4 layer board, so following traces suddenly becomes a lot more difficult. If you hold the board up to the light, you can easily see that it's a multi-layer board.

Also, there is a voltage on the pins even while the power is off. As high as 1.5v on some pins at J7 and J9, while IR-EXT maintains ~5v even in standby.

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

@kiddyl,

Join the yahoo group and check the files section. I uploaded a program called "mgcheck" that will take your "copy /b" joined firmware (boot.rom+linux.gz+cramfs.img) and check the actual sizes vs what the firmware image "thinks" it should be. It will also calculate the proper checksum and compare it to the checksum in the firmware file.

If you run MgCheck.exe with the "-p" option, it will read your modified firmware file and output a patched version that is ready for loading on the MG-35.

The program would be run something like this:
D:\>copy /b Boot.rom+Linux.gz+CramFS.img ModifiedFirmware.upgrade
Boot.rom
Linux.gz
CramFS.img
1 file(s) copied.

D:\>mgcheck ModifiedFirmware.upgrade
Firmware image identified as Mediagate.
Image for MG-35
Firmware version is: 1.4.4

Bootloader starts at 0x1C
Size - Original: 0x10420 - New: 0x10420 - Matches.
Cksum - Original: 0xb2756e63 - New: 0xb2756e63 - Matches.

ROFS Filesystem found at 0x1044c
Size - Original: 0x2ff809 - New: 0x305809 -- LEN DOESN'T MATCH!
Cksum - Original: 0x6f414dc6 - New: 0xf3b6cba8 -- CKSUM DOESN'T MATCH!

D:\>mgcheck ModifiedFirmware.upgrade -p

Firmware image identified as Mediagate.
Image for MG-35
Firmware version is: 1.4.4

Bootloader starts at 0x1C
Size - Original: 0x10420 - New: 0x10420 - Matches.
Cksum - Original: 0xb2756e63 - New: 0xb2756e63 - Matches.

ROFS Filesystem found at 0x1044c
Size - Original: 0x2ff809 - New: 0x305809 -- LEN DOESN'T MATCH!
Cksum - Original: 0x6f414dc6 - New: 0xf3b6cba8 -- CKSUM DOESN'T MATCH!

Press Enter to begin Patching.
(The original file will not be modified.)

Outputting patched file: ModifiedFirmware.upgrade.fix
Patching done!

Run this program against the newly created file without the "-p" option.
This will verify that the patch was done correctly.
!!!THIS FIRMWARE FILE MAY KILL YOUR MEDIAGATE DEVICE!!!
So please, be sure you know what you are doing first.
Every effort has been made to ensure that this program works.
However, I take no responsibility for dead devices.

D:\>dir mod*
Volume in drive D is Schatz
Volume Serial Number is 1835-487C

Directory of D:\

07/24/2006 20:23 3,234,901 ModifiedFirmware.upgrade
07/24/2006 20:24 3,234,901 ModifiedFirmware.upgrade.fix
2 File(s) 6,469,802 bytes
0 Dir(s) 74,935,357,440 bytes free

D:\>

The ".fix" file is the patched firmware file. You can remove the ".fix" extension and load it on the MG35.

Please be careful. As the disclaimer in the program states, you could easily brick the device and there is currently no known method to de-brick it.

pb

As the disclaimer in the program states, you could easily brick the device and there is currently no known method to de-brick it.I guess you're livin' proof of that! :) Has there been any progress on the JTAG interface? It seems clear that some sort of disaster recovery is necessary for this box.

I was snooping the pins in various states. While off, while booting, while running, while running "cat /dev/ttyAMx". I saw nothing. However, it could be that my hacked apart cellphone cable just isn't cutting it.


Hmmm, I hope that it was your cable rather than the serial needing some "secret knowledge" to get it working.


That said, at least we have a few clues. The Sigma GPL'ed kernel source code specifies "38400, 8, n" as the default for the "serial_jasper" device.


Yup, those are pretty standard settings.


I couldn't find a direct connection between any of the headers to any of the test pads, nor to any of the IC pins.


Really? The J9 tracks did seem to head towards the processor. But I'd have to buzz-out the tracks to be sure, which will involve some resist scratching.


Something else to note is the fact that this looks like a 4 layer board


4-layer is easy. We make some 20 layer boards at work. :-)

I hope your swapout goes OK. Given that you were flashing on standard firmware, I think you're doing the right thing.

But I still want to get my hands on a bricked MG-35 to use as a crash test dummy. :-)

Ian

Has there been any progress on the JTAG interface? It seems clear that some sort of disaster recovery is necessary for this box.

It's not clear that the box has JTAG.

But JTAG can work with just
TDI (Test Data In)
TDO (Test Data Out)
TCK (Test ClocK)
TMS (Test Mode Select)
- so J9 could be a JTAG connector without TRST. If none of these pins wiggle during boot, then this is evidence that this is JTAG - the external device has to drive TCK and TMS to get anything going on JTAG.

If J9 is serial, then it should be easy to recover from a "semi-bricked" state where the boot loader is OK but the Linux install is hosed.
If J9 is JTAG then we can recover from total brickage, but will need to use a wiggler interface, and then get some code that can use this to reflash. Doing this on Hitachi/Renesas SH is bread-and-butter to use, but I'm pretty vague regards ARM.
If J9 is something else, then I'll formally admit defeat. :-)

Ian

Hi all,

My MG35 is now fried.

I was attempting to flash to AL-Tech's v1.4.4 stock firmware image that was located on the internal HDD. The unit said "Checking current firmware" then the screen went black. The power and HDD lights went out, but the LAN light was still lit.

Sorry to hear the bad nws...

If you have not yet gotten discouraged for today, you might break out eatherrel and look to see if a tftp attempt is being made. Who knows, you might have a chance of unbricking it and can't hurt it much at this point.

Joe L.

I think you're still missing a basic concept. With a FAT32 partition, you can NEVER have a file larger than 4 gigs. It doesn't matter where the file was created, it can't be larger than the maximum for a FAT32 partition. Perhaps some reading on the various filesystems available and their limitations will help:

yes you are right. There is still be a problem with dvd iso.
So, it must use vob files until we sort out how to do ntfs write if FAT32 write is possible.

Since they have to bootstrap these at the factory, one would presume they do have a loading method that doesn't involve soldering irons. :)

Since they have to bootstrap these at the factory, one would presume they do have a loading method that doesn't involve soldering irons. :)
Yes, JTAG :-)

Hi Guys,

Ok,The yahoo group has been up for less than a week , and we already have 71 members - so there is a great deal of interest here.With what has happened to PB today , I really think its about time we purchased a "Development Box" for either PB or one of the other guys to use.I can get one off Ebay for $125.00US , so there would be little outlay here.I have created a Poll at the Yahoo group located here:

http://groups.yahoo.com/group/mg-35_firmware_mods/surveys?id=12386031

Anyone intereted , please fill out the poll , so we can see the level of interest we have.Details are in the poll and at this stage this is just a idea , but a good one I think , for the amount of $ involved for each person..

Maybe anyone that contributes can have "first dibs" on any new firmware , or something like that - all just ideas at this stage...

Let me know what you think...

EDIT: Poll only been open a hour and already half way there,at this rate we wil be able to get 2 x MG-35 - one for each of the main developers - amazing...

Hi all,

First, let me say that if a development box is purchased, it should probably go to gadgetmind. Quite frankly, he has a lot more experience with embedded devices than I do and has more equipment at his disposal. Plus, I'm about a month away from packing up everything I own and making a transatlantic move, so I really don't have much time left and don't know exactly when I'll be back online.

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

@gadgetmind,

The pins of the EM8511 aren't exposed, so I couldn't check directly. There are a number of test points on the board, and I assume that some of them are directly connected to processor pins. However, there was no direct connection (0 ohm) from J9 pins to the test points.

I still think that J7 is a more probable location for the JTAG connection. It's close to the EEPROM and pins 3,6,9 and 10 have solder dimples in them. As though a connector had been removed, but the remaining solder not cleaned out. J7 also had a sticker covering it. Printed on the sticker was "015B009 C500624" (top bottom). The sticker also had 3 colored dots on it, probably from a QC check.

Another interesting thing is that there's a sticker on my board with a MAC address on it. The problem is, it's the wrong MAC address. So either someone got real stupid at the factory, or the EEPROM was flashed with a new MAC address before the unit shipped.

So my guess is that J7 was used to flash the baseline at the board shop, then J9 is used to update the latest firmware just before the unit gets boxed up for retail.

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

@JL,

My box died just as the flash process began. It probably erased the first few blocks of the bootloader before it bricked, so tftp or serial console wouldn't exist. I did bust out ethereal, just on the off chance, but got nothing.

pb

Guys,
I am new here , i tried doing a ftp from the DOS prompt to the ipaddress and it says connected but then after sometime it gets disconnected automatically. Did any one try exploring this, i am not really good at the OS level programming but this is just my idea where someone who has more knowledge could explore

What I could really do with is a pin-out of the EM8511. It's a BGA device, but there seem to be plenty of vias so we should be able to work out roughly where the tracks go.

Regards me figuring out the JTAG debrick route, well I have a team of guys who do exactly this, but we don't do ARM and we don't exactly have a lot of spare time.

A bricked/new unit to experiment on would be great, but some ARM JTAG hardware and someone experienced with ARM embedded development would make a much bigger difference.

Ian

FYI, re: ARM JTAG

http://www.olimex.com/dev/arm-jtag.html

Hi all,

I tried with a FAT32 formatted HD with pb's latest firmware "PBShell-v1.0-144-eng".

Initially, the HD is mounted as read-only.
You just need to telnet to the linux shell to un-mount and re-mount the HD again, it will become RW.

> umount /cdrom
> mount -t vfat /dev/discs/disc0/part0 /cdrom

The problem is that it's very slow. The transfer speed is around 7Mbps.
It may due to my old slow HD that I used to test. it's a Quantum fireball EL series drive. It may be ATA-66 or even ATA-33.

Hope that it's useful for you!

FYI, re: ARM JTAG

http://www.olimex.com/dev/arm-jtag.html

Yup, that's a "wiggler" cable. You can make your own. Software I'm considering is OPENOCD or the commercial stuff from Embest. Embest provide schematics for making your own cable.

Both of these solutions require a machine with a parallel port. These are getting rare!

Ian

The transfer speed is around 7Mbps.


Purely in the interests of clarity, 7 megabits per second, or 7 megabytes per second? The little b suggests bits, but it's always worth asking!

Ian

Since they have to bootstrap these at the factory, one would presume they do have a loading method that doesn't involve soldering irons. :)

Loading the initial firmware is done in a variety of ways -
1) Programming flash chips before fitting - becoming less common.
2) Directly programming flash chips via a test clip and/or fixture - still quite common.
3) Programming via JTAG, connected with header and/or fixture - on the rise but can be slow. Our gear is popular for SH as we run the JTAG *very* quickly.

A fixture is a frame that takes a board and has sprung pins to connect to various pads. They are used for programming/test/commissioning and are more common than headers as someone just has to fit the board, close the fixture lid, wait for a red/green light, and then move on to the next one.

You can see tell-tale "pin prick" marks on pads when a fixture has been used, but automated PCB test can leave the same marks (though these usually get covered during later processes)

I need to strip my MG-35 down and this time take some high resolution pictures. If we can find a JTAG connector, then the world is our eggcup. Or something.

Ian

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.

Three of the pins have internal pull-up, is this consistent with JTAG? Also, note that these are pulled to 3V, not 3.3V! Gadgetmind, is anywhere a specification for voltage levels for jtag i/f?

EPM3032A is "Programmable logic , 32 macrocells, 2 logic array blocks, 34 I/O pins". It has 4 pins primarily used for JTAG, so it seems to be what we are looking for. PDF at http://www.datasheets.org.uk/search.php?q=EPM3032A&sType=part&ExactDS=Starts Next time when I open it, I will try to trace the conections between the header and this chip, to have the confirmation.

Three of the pins have internal pull-up, is this consistent with JTAG?


TDI, TMS, TDO TRST usually have pull ups.
TDO usually has a pull down.
TRST is optional and usually has a pull up.

One standard pinout is -
1 TRST 2 GND
3 TDO 4 GND
5 TDI 6 GND
7 TMS 8 GND
9 TCK 10 GND

Atmel use many, but one such is -
1 TCK 2 GND
3 TDO 4 VCC
5 TMS 6 Sys reset
7 VCC 8 TRST
9 TDI 10 GND


Also, note that these are pulled to 3V, not 3.3V! Gadgetmind, is anywhere a specification for voltage levels for jtag i/f?


The trend is towards the JTAG connecor having a Vref on it - you drive the signals high with a fet switch to vref.


Next time when I open it, I will try to trace the conections between the header and this chip, to have the confirmation.


If this JTAG only goes to this chip, then it's of little interest. However, it is common to daisy chain JTAG. The TDI will go to one device, the TDO to another, TCLK and TMS to all, and the TDI and TDO chain completed through all the relevant devices.

See the wikipedia article on JTAG

Ian (this was typed in a hurry, so don't trust too much!)

Yup, that's a "wiggler" cable. You can make your own. Software I'm considering is OPENOCD or the commercial stuff from Embest. Embest provide schematics for making your own cable.

Both of these solutions require a machine with a parallel port. These are getting rare!

IanPerhaps not that rare. The newest high-end MB I purchased in 2006, the Asus A8R32-MVP Deluxe has a parallel port. I wonder also, if you could use a parallel port add-on PCI card?

I have a samba share, that all my Linux/windows machines will happily write to, but the MG-35 gets premission denied.

I do -
mkdir /net/test
smbmount //192.168.1.65/public /net/test rw

and I can see my content in /net/test but file creation or deletion fails.

What did I miss?

Ian

Perhaps not that rare. The newest high-end MB I purchased in 2006, the Asus A8R32-MVP Deluxe has a parallel port. I wonder also, if you could use a parallel port add-on PCI card?
What about USB to Parallel Converters? We tried to use som USB to Serial Converters (not impressive) at work but that was years ago. Maybe they are better (or even useful) these days?

I now have an RS232 level shifter and a "wiggler clone" on their way to me from Canada.

eBay items -
330009318042
160006186591

If there's serial or JTAG on this board, then I'm going to jolly well find it!

Ian

I have a samba share, that all my Linux/windows machines will happily write to, but the MG-35 gets premission denied.

I do -
mkdir /net/test
smbmount //192.168.1.65/public /net/test rw

and I can see my content in /net/test but file creation or deletion fails.

What did I miss?

Ian
Did you read my post #925 (http://www.avsforum.com/avs-vb/showthread.php?p=8026382&&#post8026382) on page 31?

Ps. I assume you intend to use the MG-35 default SMB user "guest" with a "null" password...

Sorry everyone , I went to edit a couple of typos in the poll at the Yahoo Group and itappears to have deleted all the entries..

Please can you all re-enter your amounts - VERY sorry about this and I
promise I will leave it alone from now on..

Regards

Teddy

Did you read my post #925 (http://www.avsforum.com/avs-vb/showthread.php?p=8026382&&#post8026382) on page 31?

Ps. I assume you intend to use the MG-35 default SMB user "guest" with a "null" password...

Here is the relevant bit from my smb.conf

[public]
comment = "Public"
path = /shares/public
public = yes
read only = no
force create mode = 0666
force directory mode = 0666

The share mounts but read only, which I really don't understand, even after rereading your #925

Ian

The airlinktek website states:

"The MG-35 can be configured in collaboration with web-based movie distributor as a set-top box or media gateway to access, play and/or download the legal movies from the website directly without home PC."

I would like to setup a website with divx encoded videos for which I have rights to and share them with subscribers that will own MG-35s. I need to know how to set up the MG-35 to download the videos from the remote site with out needing a computer. I can setup the site in any way needed to be compatible with the MG-35.

I would really appreciate assistance with this.

Purely in the interests of clarity, 7 megabits per second, or 7 megabytes per second? The little b suggests bits, but it's always worth asking!

Ian
Yes, it's megabits per second.
Someone email me that he did the same thing and the telnet session can saw the file but NDAS could not show it. After power cycle, the file disappered.

Because I tested it really late last night and just make sure telnet session saw the file.
I will test it more thoroughly tonight.

Here is the relevant bit from my smb.conf

[public]
comment = "Public"
path = /shares/public
public = yes
read only = no
force create mode = 0666
force directory mode = 0666

The share mounts but read only, which I really don't understand, even after rereading your #925

Ian
I don’t know if this will help but I hade problems too until I actually created a SMB user named “guest” with a null password on my server. That in conjunction with the following made it work (I don’t know why that works, Samba has always been kind of Voodoo to me):

[global]
...
guest account = guest
null passwords = yes
...

[public]
...
guest ok = yes
public = yes
writeable = yes
...

The airlinktek website states:

"The MG-35 can be configured in collaboration with web-based movie distributor as a set-top box or media gateway to access, play and/or download the legal movies from the website directly without home PC."



I suspect that al tek support that functionality in kind of the same way that they support Nelson Mandela. :-)

Unless rabbits are pulled out of hats rather quickly regards new firmware, I suspect you need to look at different hardware.

Ian

I suspect that al tek support that functionality in kind of the same way that they support Nelson Mandela. :-)

Unless rabbits are pulled out of hats rather quickly regards new firmware, I suspect you need to look at different hardware.

Ian


Thanks for the reply. Do you have any idea what kind of hardware would support playing my videos from the internet in a similar price range?

The airlinktek website states:

"The MG-35 can be configured in collaboration with web-based movie distributor as a set-top box or media gateway to access, play and/or download the legal movies from the website directly without home PC."



I would like that too. That's why I'm following this thread :)

Guys does any one have problems playing .dat files from a vcd, it says its loading all hte .dat files and then come back to the folder listing, tried playing all files option and tried playing single file. Any help appreciated.

Hi Guys, I't really exciting to follow this thread now.
Since many of you seem to be very well informed of the firmware available and how it works. Can anyone help me with this one small problem.
I have two mg-35 boxes. Both worked fine when I bought them.......then I upgraded the firmware in one of them, and since then it only plays the audio in my movie files in about 50% of the time..... that is, about half my videos can't play audio in the MediaGate.
I've upgrated and downgreated the firmware many times and nothing seem sto fix this.
Any suggestions are wellcome.
Best Regards,
Bjarki Kristjánsson
_____________________
Don't eat yellow snow.

Thanks for the reply. Do you have any idea what kind of hardware would support playing my videos from the internet in a similar price range?

I recommend that you take a look at the Philips Streamium range, maybe the SL300i I haven't turned mine on for ages, so I have no experience of the new firmware, but the UI is nasty and the codec coverage worse than the MG-35, but it is very internet aware.

You may also like to look at the page for the twonkyvision UPnP server software as they have a page showing all the clients that they support. This is a good round-up of the media players that are out there.

The MG-35 isn't on the list as it doesn't support UPnP. (But we could add it if we could rebuild a kernel that exports the right symbols for fuse)

Ian

Just to keep people in the picture, my current plan is -

1) Wait for my JTAG wiggler
2) Find JTAG pins on board and read current flash using openOCD
3) Wait for a sacrificial MG-35 (have PMd the guy in France who bricked his, but he may no longer be in this forum)
4) Try and get openOCD to program Samsung flash. My initial investigations suggest that openOCD cannot currently do this and some coding will be required.

openOCD can handle CFI flash, which the Samsung part is, but the Samsung part is using vendor command protocol 0002 (Atmel and Toshiba) rather than 0001 or 0003 (Intel) The coding changes should not be extensive, but this won't be right the 1st time (and maybe not the 2nd!) hence needed another MG-35/Freecom.

If anyone fancies doing some tracking of signals regards (2), then please let me know how you get on. openOCD can cope with multiple devices on a scan chain, so let's just hope that JTAG goes to the EM8511!

Ian

tiny url dot com/qcqh4

This forum hates t i n y u r l !!!! Take out the space and the "dot"

If we don't get anything with JTAG then fitting a couple of TSOP 48 sockets is another option. We have the gear here to do it (though these TSOPs are very fiddly!) and only the heavy duty kernel hackers would need a socket equipped unit. They could then have a supply of "virgin" flash chips to drop in when they scrabble a pair. :-)

Ian

@kiddyl,

Join the yahoo group and check the files section. I uploaded a program called "mgcheck" that will take your "copy /b" joined firmware (boot.rom+linux.gz+cramfs.img) and check the actual sizes vs what the firmware image "thinks" it should be. It will also calculate the proper checksum and compare it to the checksum in the firmware file.

If you run MgCheck.exe with the "-p" option, it will read your modified firmware file and output a patched version that is ready for loading on the MG-35.

Please be careful. As the disclaimer in the program states, you could easily brick the device and there is currently no known method to de-brick it.

pb

Thank you. DL it and will give it a try anytime soon. I am no firmware programmer, but like to adjust the menu's to my own personalized one. When I am succesfull I will try to write a small tutorial for anyone who wants to do it. Although the tutorial is already right there written by pbarrette :p

I just build BusyBox 1.20 and ran it on the MG-35 via a network share. I also managed to mount a samba share as rw and dd the 1st 4MB of /dev/mem to a file. (It was for dd that I built this new BusyBox)

I then did (on the PC)
dd if=mem.bin of=mem.bit skip=927753 bs=1
sudo mount -t cramfs mem.bit /mnt/test -o loop

And the cramfs mounted and I could explore it.

The 927753 is the decimal of 0xe2809, which comes from the kmsg output -
JASPER use arena[0] for cramfs [0x000e2809]

So,
1) I can build flat ARM uClinux executables. No big deal, but it's a first for me!.
2) I think I have the full 4MB of the flash. Worst case, I can burn the odd/even parts into some flash chips to debrick a box.

Ian

Guys does any one have problems playing .dat files from a vcd, it says its loading all hte .dat files and then come back to the folder listing, tried playing all files option and tried playing single file. Any help appreciated.

For me, I copy over those .dat files and then rename them as .mpg .
It's fine because the vcd's .dat is just a .mpg file with some extra header which most of the software will ignore those header.

Yes, it's megabits per second.
Someone email me that he did the same thing and the telnet session can saw the file but NDAS could not show it. After power cycle, the file disappered.

Because I tested it really late last night and just make sure telnet session saw the file.
I will test it more thoroughly tonight.

Yesterday night I don't have much time and just do a quick test.
I put back my fat32 hd and browse from tv to make sure the ftped files can be shown. The file still there. Since it's a broken file and I cannot play it to confirm whether the transfer is ok or not. I will do the ftp later maybe with a better hd to measure the speed and confirm the transfer is good by playing the file after ftp.

One more thing that I want to mention.
After I upgrade to pb's latest firmware with telnetd and ftpd, DVD iso file cannot be played. If I restore the original firmware, everything play again. Is that other people have the same problem.

Second, for those people who update their firmware, can we update the firmware from local hd (the hd in mg-35)? Because I update it from the network with no problem but pb experienced update failure from local hd, so I am not dare to try it. I want to keep several firmware files in local hd then I can switch between firmwares without setup my network or even turn on my computer to serve the firmware files.

One more thing that I want to mention.
After I upgrade to pb's latest firmware with telnetd and ftpd, DVD iso file cannot be played. If I restore the original firmware, everything play again. Is that other people have the same problem.
.

Have to admit , this is one feature I would not like to loose , as I use it a great deal , sure PB must know the reason why, and wil be able todo a fix...

This is what's at the start of the "boot ROM"
00000000 f0 a4 00 01 27 23 92 b0 d0 f3 9f e5 19 88 06 28 |....'#.........(|
00000010 3e 89 49 a2 3d e2 8a 18 78 00 00 ea e7 00 00 ea |>.I.=...x.......|
00000020 ed e6 2d 48 cd f8 d2 67 00 94 c3 26 5d 38 30 a3 |..-H...g...&]80.|
00000030 6c 37 52 26 fc ef 4f 53 a1 14 48 59 1a 98 69 01 |l7R&..OS..HY..i.|

I tried using arm-elf-objump -m arm --target=binary -EL -D mem.bin
but the output looks like nonsense code.

This suggests that there is remapping happening after boot. Or something!

Ian

It seems that post-reset remapping of ram down over the rom is rather common on ARM. I don't know how much ram the "Jester" has to remap but will use dd to find out the lower bound of ROM (dd in a byte from /dev/zero, see if it's there, if not then drop down to the next n^2 boundary)

Once I know this, I can find the values at the start of *mapped* rom, fine this in the image in the rom image that's flashed, and hopefully reconstruct a total image of the full 4MB of flash. We can then do some serious disassembly etc.

Ian

Took some time but I have finally finished a first attempt of revamping the graphics of the 144 eng firmware (how I hate working with that limited palette). It is uploaded to Yahoo Groups. Below is it’s readme.txt quoted (and a teaser):

MG-35 New Graphics Theme - "New Generation"
-------------------------------------------

A quick overhaul of the stock graphics in the MG-35 144 eng firmware.

Glyphs are taken from the KDE theme "Linspire Clear".

Overlayed OSD images were kept from the original firmware.

Systems palette must be set to attached "palette.act". I have no idea how this might affect the text colors. The original seems to use black, white and grey for (localized) text. White is the first entry in the palette, black the last but I have no idea if grey or the others do map to a specific palette entry or if text colors are hard coded. I still got several entries in the palette "reserved" for future needs. Just let me know...

Ps. Yes, it's blue and gold...

@EmuMannen

Great work , Cant wait to see them built into the stock 1.4.4 Firmware..

Using this as a peek
./busybox dd if=/dev/mem of=b8191.0 bs=1 skip=8191 count=2

and this as a poke
./busybox dd if=/dev/zero of=/dev/mem bs=1 seek=8191 count=2

I have found that byte 0x1FFF is not writeable but byte 0x2000 is. So, we have 8kB of RAM mapped in at zero.

The first bytes of the mapped ROM, which are at address 0x2000 are -
b0 10 a0 13 66 00 00 eb 05 00 a0 e1 00 10 a0 e3

I expected to find this beyond 0x2000 into the boot.rom file but it's at 0x1FE0 This means that boot.rom doesn't contain all of the first 8k bytes of what gets programmed into the flash, which makes disassembling the boot sequence "interesting".

I'd like to disassemble this (or someone else to do it!) to see if there is any secret knowledge needed to get the boot ROM to start listening on serial. It might require a password to be sent to it before it kicks into life. We make gear that requires exactly this.

I'm running out of things I can usefully do without JTAG going. But it might be worth trying to scan /dev/mem to find a complete "shadow" of the boot ROM. Checking for the above signature at 0x2000 offsets from various sensible boundaries might be fruitful. However, if we read a hardware region, expect the box to crash - I've done it once already.

Ian

Hi dummyx,

I can only think of a couple reasons that ISO files would fail with my last firmware:
1) The new busybox's "mount" command doesn't work the same as the old.
2) The mount point has changed in some way.

To play ISO files, the MG35 mounts the ISO to (I believe) the /iso folder. If "mount" isn't returning what dvdplayer.bin expects, then the GUI would assume a mount failure. The /iso mount point should not have changed, but it's possible that it did in some unknown way that causes the mount to fail.

I could have sworn that I tested AVI's, MPG's and ISO's after the firmware change, but since my device is dead, I cannot be sure.

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

@gadgetmind,

When you get a chance, you should take a look at the Altera USB-Blaster user's manual:
http://www.altera.com/literature/ug/ug_usb_blstr.pdf

The manual gives a JTAG pinout that looks very similar to the pinout for our J7. It also happens to be right next to the Altera EEPROM, so it's quite possible that ALTech used the Altera specs for the pinouts.

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

@EmuMannen & others,

Since my device is dead and pending exchange, I cannot test the graphics for you. However, if anyone is interested in doing so, send me a PM and I will give you my palette replacement utility with instructions on how to use it and where to find the system palette in v144's dvdplayer.bin.

pb

When you get a chance, you should take a look at the Altera USB-Blaster user's manual:
http://www.altera.com/literature/ug/ug_usb_blstr.pdf

The manual gives a JTAG pinout that looks very similar to the pinout for our J7. It also happens to be right next to the Altera EEPROM, so it's quite possible that ALTech used the Altera specs for the pinouts.



Yup, that's one I looked at. But I need to confirm that the EM8511 is also on the scan chain. Just chatting to the EEPROM would be a little dull. Though we could change MAC addresses so that the NDAS stuff would work. :-)

Ian

Hi Gadgetmind,

Actually, I was thinking that the flash memory units may be chained to the EEPROM as well.

If that's the case, we may be able to avoid the processor at the moment, since all we really need is a way to de-brick if we screw up a development image.

As for the NDAS keys, it would probably be more fruitful to look at lpx.o and ndemu.o and find the MAC hashing algorithm that creates them. If we found that mechanism, it should be fairly simple to create a utility that would generate the keys from the user's MAC.

pb

Actually, I was thinking that the flash memory units may be chained to the EEPROM as well.

If that's the case, we may be able to avoid the processor at the moment, since all we really need is a way to de-brick if we screw up a development image.


I've never met flash chips with JTAG. I have the datasheet for these Samsung chips and they certainly don't have it.

There are three main ways to in-circuit program flash via JTAG -
1) Wiggle the pins of a chip on the bus that connects to the flash (normally the processor) via boundary scan - this is slow but works on pretty much everything. The boundary scan can also be used for system test.
2) Use the JTAG to do bus memory accesses - faster but not all processors allow this.
3) Download code to the processor and get it to run the reflash - very fast but requires code with intimate knowledge of the system.
(remember at this point that I mentioned two ways to program flash without JTAG, let's call these, 4) Fit the flash already programmed, 5) Program with a clip on the flash chip. And, of course, embedded engineers are peverse beasts and have probably invented another half dozen screwy ways)


As for the NDAS keys, it would probably be more fruitful to look at lpx.o and ndemu.o and find the MAC hashing algorithm that creates them. If we found that mechanism, it should be fairly simple to create a utility that would generate the keys from the user's MAC.


Or we could just set everyone to the same MAC. Many network drivers allow you to override the MAC from the EEPROM. We can then all share one key. I won't be drawn into discussions regards the ethics of this. :-)

How does the Linux side handle NDAS? Does some driver (one of the ones you mentioned?) handle making the disk block device available via ethernet? I wonder if we could bodge in the Coraid ATAoE stuff?

Hmm, I wonder how they handle making sure the kernel NTFS driver remains sane while something boogies on its disk blocks?

So many questions ...

Ian

Hi Gadgetmind,

Ah.. See, since the Altera chip is actually a CPLD and not a plain (dumb) EEPROM, I was hoping that it might be able to serve as the middleman to the flash mem. I must admit that I don't have much knowledge in this area.

The MG35 talks "NDAS" via emulation. It consists of two parts: The ethernet protocol (LPX) and the block device translator (NDEMU).

The ndemu.o kernel module talks to the disk and acts like a block device. It hands over device data to lpx.o which transmits the packets over ethernet. The remote system also has an LPX protocol driver to receive the packets and hands those off to a virtual scsi driver.

NDAS's LPX protocol also seems to be encrypted (looks like 128bit). Encryption and decryption is also handled by the ndemu.o module.

That's got to be the main reason that NDAS emulation is so damned slow. Every packet transmitted or received needs to be en/decrypted on our slow processor. Real NDAS devices have a dedicated IC for encryption and (probably) the LPX protocol stack.

The question then becomes, does ndemu.o contain the MAC hashing routine, or is it part of the LPX protocol driver? My guess is ndemu since it also contains the other encryption functions.

Reprogramming the MAC address would work as well, but I don't like that idea from a philosophical standpoint. All MAC addresses should, technically, be different from each other. It would also require a flash to the EEPROM which shouldn't be neccessary. Finally, it wouldn't help the person who has 2 MG35's on their network.

As for the RO NTFS driver, it probably doesn't care too much. Since it's read only, there wouldn't be simultaneous write attempts, so that's not a problem. Unless a file is moved or deleted via NDAS, it occupies the same blocks as before, so the NTFS driver would still be looking in the right place.

I can really only see 2 potential problems:
1) If you are deleting/modifying a file via NDAS while playing it on the MG35.
2) If you run a defrag on the drive while it's playing on the MG35.

The other possibility for problems would be a rare case of the MFT being changed while a file is playing. But as I recall, NTFS's "MFT" is different from FAT in that it is distributed through the disk instead of a mass block at the head of the disk. So the MFT entry for a playing file shouldn't change unless that specific file is being altered via the NDAS connection.

pb

Hello all,

Unfortunately, without a box, it's becoming difficult to contribute much more at this point. This is especially true given my pending move.

That said, I will try to do what I can until my box gets replaced.

I have fixed MgCheck.exe to handle MG-25 and MG-350 firmware images as well, but it still needs some cleanup. The output just looks too messy at the moment, so I need to do some work on that before I replace it in the yahoo files area.

I have also decided to release my palette injector, MgPalette, even though it is totally untested at this point and requires some specific knowledge on the part of the user to function correctly.

It would be nice if someone would use this to test EmuMannen's new graphics.

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

Also, it looks like a number of people have downloaded my modded firmware images, so I would like to take a second to remind people about proper firmware flashing methods.

The safest procedure to flash the firmware is:
1) Copy the firmware image to the built-in HD.
2) Power off the MG-35.
3) Power on the MG-35.
4) Flash the new firmware.

Don't rely on network flashes if you don't absolutely have to.
Never turn the device off during a flash upgrade until told to.
Never connect via NDAS, FTP or telnet before or during a flash upgrade.
Do not flash the MG-35 with the same firmware that is already loaded.

If you follow this advice, you should have no problems flashing your device.

pb

Hey there all.

I have been watching this thread for a week now (since I bought my mg-35) and looking forward to the development that has been discussed. Cudos to pb, gadgetmind and teddystaker.

Having had the unit for a week now I've formed various opinions on its functionality.

As a video/movie player I think it is awesome. Its ability to play ISO/DVD images is impessive. I also like the 'time search' feature and I'm rapt in the the 'resume from stop' function.

As a photo viewer it does pretty well much any viewer would do .... no compalints I guess.

As a MP3 player, well this is where I am sorely disappointed. I also have a Zensonic z400 network media player and the manner in which that device handles MP3s is more than impressive. The ability for it to sort MP3s by genre, artis, album, year etc by using the MP3's ID3 tag is phenomenal. If a modded MG-35 was able to achieve this, you would make a grown man very happy.

The mg-35s interface doesnt bother me as far as colours and graphics go but what does bother me is that if I chose 'video' (when using the HDD) I am presented with all my folders on the HDD (in my case Video/photo/music). That sort of makes the main menu superfolous, in the fact that if I am navigating the HDD dirs backward (ie after watching a movie) and want to play music, I may as well just go to my music folder and play the music coz I'm going to be passing right by that folder to get to the main menu to chose 'music'. If that makes sense ? I gues you have to own one to follow that paragraph :)

Samba access to the HDD would be awesome as well.

All in all I think like most people here this unit has great potential and it is probably going to be up to us (the users) to develop this unit further. BTW thats a 'royal us' It is really a select few in this forum that have the knowledge and the ability to achieve this and sadly I am not one of them. I am so impressed what the people I mentioned above have achieved thus far (sorry if I have missed anyone).

I guess all I can offer is critique (friendly of course) on any improvements that you achieve.

Please continue the good work, and again well done to all contributors.

Mike

Ah.. See, since the Altera chip is actually a CPLD and not a plain (dumb) EEPROM, I was hoping that it might be able to serve as the middleman to the flash mem. I must admit that I don't have much knowledge in this area.


Oops, my bad. Too much talking and not enough looking at the board (and properly reading what people are telling me!)

I'll check the package of the CPLD, grab a datasheet, and then buzz between the connector and the CPLD to get the full JTAG pinout. Hopefully the uP is on the scan chain. The only other hope is that the CPLD is also connected to *all* relevant pins on the flash chips (2x16 bits data, all address, all controlincluding word/byte strobes) because we can then program the flash by wiggling CPLD pins using boundary scan. This is *really* slow.

*later*

I just checked the package - max 34 user IOs on the 3032. No way can we use its boundary scan to program the flash. Dunno what the 3032 actually does in the system - just some glue logic? Anyway, I can trace the JTAG.


The ndemu.o kernel module talks to the disk and acts like a block device. It hands over device data to lpx.o which transmits the packets over ethernet.


Well, I'd guess we can handle this block read/write from user land, either via ndemu or just by hitting the disk directly. We can then have a program in Windows that can talk to a remote disk. Kind of like ATAoE.

Maybe some of this stuff would be a useful starting point on the Windows end - http://www.acc.umu.se/~bosse/

Regards confusing the NTFS driver, I guess we could just umount when we start the remote update and mount afterwards.

Ian

OK, here's an idea for how people can play with customisation without having to keep reflashing.

1) A new sashrc is written that attempts to mount the HD (am I the only person without one fitted?) and then run a script from it. If this fails, or the script exits, the next line in sashrc will run the normal dvdplayer.bin
2) People can then write their own script on the HD that can copy stuff from flash to hd, mount hd directories over the flash ones, mount network shares, and generally do whatever we want.

This way, all the playing around with new dvdplayer.bin files, new graphics, whatever can be done with only the reflash that's required to replace the initial sashrc.

Thoughts?

Ian
P.S. I suspect the Profilic USB->IDE chip is wired directly onto the IDE bus and acts as sole master when USB is connected. It probably holds the EM8511 in reset at this time. I suspect that the 6G minimum HD limitation might be due to the Profilic chip - I may try a small CF as I can now update it via FTP/telnet

Hi all,

I have released two new utilities into the Yahoo groups files section:

MgCheck v1.1 has replaced the old version in the files section.

The changes for the new version are:
- Now checks and patches MG-25 and MG-350 firmwares as well as MG-35.
- If used with the "-p" (patch) option, verification messages are for the newly created file. No need to run the program against the new image after patching.
- Cleaner output messages.

As always, please use caution when flashing modified firmware to your device.

The MG-25 and MG-350 patching methods should work, but they are totally untested as I don't have either device.

Attempting to verify or patch MG-25 firmware v1.1.7 will fail. This firmware image is an odd beast that may have positive ramifications for us later on. As of now, however, patching and verification is broken for this image.

Specifically, MG25-117 firmware image lacks the bootloader section. This is good news since later versions include the bootloader. This means that we should be able to create firmware images that lack a bootloader, thus reducing the chances of destroying the existing bootloader during a flash.

Currently, MgCheck always looks for the bootloader section and fails miserably when it isn't present.

Mediagate has recently released an in-dash media player for cars called the CMP-100. It has a similar firmware format, so I plan to extend MgCheck to cover it as well.

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

MgPalSwap:

I have decided to release this utility, but please do not use it unless you REALLY know what you are doing.

This program can inject a Photoshop ACT format palette into dvdplayer.bin, thus replacing the default system palette with a custom one.

To use this program, you need:
- A copy of dvdplayer.bin
- The offset (in hex) of the system palette.

If you aren't careful, you can render the GUI completely useless. Since the GUI is currently the only way to re-flash the firmware, if you accidentally kill dvdplayer.bin, your MG35 will be useless as a media player.

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

All source code is in C# and available on request.

pb

Specifically, MG25-117 firmware image lacks the bootloader section. This is good news since later versions include the bootloader. This means that we should be able to create firmware images that lack a bootloader, thus reducing the chances of destroying the existing bootloader during a flash.


This does sound promising, but we need to be sure the upgrade.bin will notice this and not erase the full flash! I have checked the flash datasheet, and they have fitted the top boot version (despite the ARM's bottom boot!) but this still means that there is a 64kB block at zero, which is the size of the bootloader. So, the rest of the flash can be erased leaving the boot loader in place, but the code would have to be smart enough to do this.

Ian

I wonder if any of the front panel buttons could be held at boot time to activate the boot loader? I guess any combination of press/hold/release that got the unit to not boot normally would give us a starting point.
Ian

Here is the procedure for fitting TSOP sockets.

http://alphazee.webstrikesolutions.com/Leaper/tsoptutorial2.htm

These guys have suitable looking sockets for $7 ish each
http://www.meritec.com/products.asp?plist=1#SMT Sockets

980020-48-01 48 TSOP Socket without alignment pins, packaged in trays $7.09

Cheaper if we buy 10. :-)

But let's see how I get on with JTAG tracking this weekend.

Ian

I suspect that technique is WAY beyond most folks that don't do a lot of PCB modifications. I've done enough rework on boards to know that the fine pitch sockets illustrated are not easy to work with. I think the JTAG is clearly a better method if it's possible.

I suspect that technique is WAY beyond most folks that don't do a lot of PCB modifications. I've done enough rework on boards to know that the fine pitch sockets illustrated are not easy to work with. I think the JTAG is clearly a better method if it's possible.

Agreed 100% in every regard! You don't stand a chance unless you have the skills and the equipment, including some good magnification (unless you have 20 year old eyes!) And even with this gear, TSOPs are one of the harder packages, to work on. (Though a lot of our stuff now is BGA, including some with 1752 pins that cost $6000 each!)

I mention the socket option because we may fail with the JTAG. Making a small number of "kernel hacker" MG-35s would let us proceed. People working on other areas of the mods shouldn't even need to reflash (see my other posts)

Ian

I am scanning the net for information regarding dvdplayer.bin (out of curiosity)...

I don't know if it is relevant or not but take a look at the following link (http://sigma-players.nd.e-wro.pl/firmware.htm).

Ps. Could someone (that taken it a part) please make a short summery of the main circuits contained in the MG-35?

I am scanning the net for information regarding dvdplayer.bin (out of curiosity)...

I don't know if it is relevant or not but take a look at the following link (http://sigma-players.nd.e-wro.pl/firmware.htm).

Ps. Could someone (that taken it a part) please make a short summery of the main circuits contained in the MG-35?
Thanks EmuMannen!!

It's a very useful link. Maybe I can customize the firmware to handle Chinese filename.

Also led to the following links:

A copy of Sigma Designs ARM core system on chip uClinux product release source code (http://www.uclinux.org/pub/uClinux/ports/arm/EM8500/)

Information on the ETRAX port of uClinux (http://www.developer.axis.com/software/)

ETRAX port of uClinux binaries and source code (http://www.uclinux.org/pub/uClinux/ports/etrax/)

Do we really need dvdplayer.bin? Excuse my ignorance but to me it looks more or less like a front-end to mpegplayer.bin and fileplayer.bin. I could personally se it exchanged in favor for a more flexible front-end (if possible). Maybe there is enough room for something like a Python interpreter. That would make it fairly simple to build something flexible yet powerful (maybe supporting a simple theme engine etc.). I don’t know much about Python on ARM or under uCLinux but I do know how powerful Python can be (just started to port a lot of legacy functionality to Python at work, might still be a bit over enthusiastic)...

Link to Python for arm-linux (http://www.vanille.de/projects/python.spy)

ian,

i had the same thought with regards to flashing the device & running user programs. the code below loops (max 6) around waiting for some thing to appear on /hdd and then runs a program. if it exits with a non-zero value or can't be found it runs 'real' one. the only issue is that the drives have to be mounted with the 'exec' option. i dont know if it does that. a longer way would be to create a cramfs file on the HD, mount it and run the programs from there.

i'll check this out later to see how it mounts the HDs and if that code runs OK on busybox.

we have to keep their dvdplayer.bin around as it's the only way to flash it etc from what PB says.

i've BFLT'ed my programs so i'll PB flash it this w'end and see how they run.

i've found the KiSS kernels and configs but i'm new to world of kernel compiling. what do you do with the configs ?!

###########################################################
CNT=6
ls /hd?/* > /dev/null 2>&1

while [ $? -ne 0 -a $CNT -gt 0 ]
do
CNT=`expr $CNT - 1`
sleep 5
ls /hd?/* > /dev/null 2>&1
done

RUN=`ls /hd?/bin/mydvdplayer`
$RUN &

if [ $? -ne 0 ]
then
/dvdplayer.bin &
fi

the only issue is that the drives have to be mounted with the 'exec' option. i dont know if it does that. a longer way would be to create a cramfs file on the HD, mount it and run the programs from there.


Can't your script just umount the hd and remount it with the options we want?

You might be able to test your script by killing dvdplayer.bin (will need a BusyBox with kill) and then running the script.


i've found the KiSS kernels and configs but i'm new to world of kernel compiling. what do you do with the configs ?!


The config that's used is called ".config" I just copied the most likely looking config to .config, did "make menuconfig", played with various options and then did "make". If you set drivers to be built as modules (hit m) then you can build them all with "make modules". I then just grabbed the relevant module from inside the directory structure (e.g. drivers/fs/ext2.o) and copied them to my samba share to try them with insmod.

Ian

I now suspect that all the programmable devices on this board are programmed before they are fitted to the board. The CPLD and the flash chips have red paint dots on them, which will be to show that the devices have been programmed. Someone will remove them from a waffle tray by hand, program, mark with a dot, and then put back in the tray - the paint helps eliminate human error. The two flash chips also have different colours of paint and one has a second dot, which stops them being fitted the wrong way around.

I have also checked the connections from the CPLD to J7. Both TDI and TDO connect directly to this socket, so the processor is not on this scan chain.

However, there are seven pads to the RHS of the processor that are marked "D" What's the betting on "D" for Debug?

The only hint as to pinout is about 20mm away (up and right) where the silk screen is labelled -
TP57-------
-------TP48
TP52-------
-------TP51
TP47-------
-------TP53
TP45-------
This area of silkscreen is also labelled "D"

I've metered this connector (no power to board) and can't detect any pulls ups or downs. I'm pretty sure this is a JTAG connector for the EM8511 but have no idea which pin is which! So, getting TDI, TDO, TMS and TCLK right will require 840 different combinations of connections, assuming that the reset state is right.

All suggestions for how to glean pinout are very welcome.

Ian
P.S. I have taken some high resolution pictures and have put them on Yahoo.
P.P.S. Have just notices - my board is fitted with Spansion flash chips - S29AL016M90TA101 These are still CFI vendor code 2.

Great article here on reverse engineering a JTAG pinout.

http://hunz.org/jtag.pdf

No wiggler yet or I'd be getting stuck in already! I guess I need to hunt around the various bits of wiggler software and find something that lets me do bitbanging to the TCLK and TMS lines and I can then look for TDO with a scope.

Once I have those three, finding TDI should be pretty quick.

Ian

Some thought on custom firmware and graphics. I think it’s reasonable to assume that we won’t get rid of dvdplayer.bin and it’s built in GUI limitations anytime soon. I do like the idea of having a modified init script and a fallback to the default dvdplayer.bin. I guess that such an init script could mount a new /img directory providing new GUI graphics. The only problem is the systems palette built into dvdplayer.bin.

I really don’t like the idea of patching a new systems palette into dvdplayer.bin for every new set of custom graphics. That is what you would end up with if using the same workflow as I did with my new theme. What I did was making all new graphics in RGB-mode. I then exported every image with its own unique 256 color perceptual palette. Next step was to create a new global 236 colors palette based on the sum of all the individual palettes. Last step is to dither all images using this new global palette (the new systems palette).

This would render an optimal result especially if using a limited amount of colors in RGB mode. But I will propose another strategy to avoid the need for patching the systems palette if just changing the graphics in /img. What we should do is to patch dvdplayer.bin with a well known generic palette. I made some tests with Windows and Mac System palettes and the well known “web-safe color palette” and the result is as good or bad using either of these, especially if you use a lot of colors in your original graphics.

Mac and Windows palettes both use all 256 available colors. The web-safe palette only uses 216 (to accommodate the three root colors RGB without its cubed value exceeding 256 that number is 6 (6 * 6 * 6 = 216). If you need six points on a scale, you need five spaces. Since we started our scale on 0, not 1, we can divide 255 by 5 and get the result of 51. Therefore, our values are 0, 51, 102, 153, 204, and 255. Any combination of these in the R, G, or B positions results in a valid color for an 8-bit display). The strength of the web-safe palette is that it is well known and there is a lot of tools and knowledge how to convert and optimize towards this palette. It would also give us the opportunity to reserve the additional colors for other purposes (maybe for text colors depending on how MG-35 is assigning its text colors).

I know, the web-safe palette might not be the best palette for all graphics but it would be a much better “least common denominator” than the default built in systems palette (mainly containing shades of gray). I really don’t care if it’s the web-safe, Windows, Mac or any other generic palette. But I believe that we would benefit from a common generic and well defined palette and that we stick to that one when we develop new graphics.

Comments?

Ps. one of the first things we should do is to patch the palette to one containing 256 unique color values. Using a screen grab should make it possible to identify the colors used for text (I have only found back, white and grey using the stock firmware). I still don’t know if these colors are fetched from the systems palette or if they are hard coded.

I guess that such an init script could mount a new /img directory providing new GUI graphics. The only problem is the systems palette built into dvdplayer.bin.


I know it's at a bit of a tanget to the main thrust of what you're saying, but note that the new script can run an alternative dvdplayer.bin program from the HD or a samba share.

This still means that palettes need patching into dvdplayer.bin but there is no need to reflash to start using the new palette.

I was trying to play with a patched dvdplayer.bin just now, and rather than making a new flash, was using "kill 8" to dispatch the current version. The new one wouldn't run unless I did "/sbin/rmmod fipmodule" and "/sbin/rmmod khwl" as it gave errors when trying to insmod these. But I kept managed to crash the MG-35 so I guess we do need that new script that runs an alternative script from the HD (or wherever) and then runs as normal is said script can't be found.

Ian

Great article here on reverse engineering a JTAG pinout.

http://hunz.org/jtag.pdf



Hmmm, and the author and owner of the fancy "find which jtag pin is which" hardware is in sunny Germany ...

Ian

hi all

I owe a few users that registered on the above site an apology, I have just learnt that the phpnuke script that i was using was sending out spanish emails and popups, I am very sorry about this and the problem is being rectified, the site should be back up tomorrow, but all users will have to re-register on the site above once site is back up...

Once again I am very sorry about this..

And to continue my monologue. :-)

1)
I haven't found the reset generator or a reset line on this board (but haven't spent ages looking). Anyone have any ideas? We really need to stop everything before the ROM/RAM mapping is done. Dunno what reset features are available via JTAG.

2)
If we suggest to Al Tech that the following would satisfy the bulk of their gpl obligations -
cd Linux-2-4-17
make clean
cd ..
tar -czf Altech-MG-35-1-4-4-gpl.tar.gz Linux-2-4-17/

The source for the other GPL bits would be great, but even the kernel would help greatly (as long as we get configs)

Ian

The donation poll at the Yahoo group is now complate, and I have posted info at the group on how people can donate and what's going to happen to the money....

If we suggest to Al Tech that the following would satisfy the bulk of their gpl obligations


I just sent Saerom Kim a very reasonable, polite and helpful email explaining what I need and how they can provide it. I made it clear that nothing proprietary is required, nothing is in there that will help a competitor, and (politely) that it is an obligation under the GPL.

Fingers crossed!

Ian

You could have pointed out that there is a firm chance that a user developed firmware would boost sale of their product without costing them a penny for in-house development. That would be an offer I wouldn’t resist (if it would have been my product), it’s a real win-win situation for both the manufacturer and us customers! :)

You could have pointed out that there is a firm chance that a user developed firmware would boost sale of their product without costing them a penny for in-house development. That would be an offer I wouldn’t resist (if it would have been my product), it’s a real win-win situation for both the manufacturer and us customers! :)And also...
Any improvements we make would be required under the GPL be shared with them in return.

If they desire, they would be able to incorporate the best of our user-development-community software into their next generation of hardware, again with minimal in-house costs, since the human factors engineering, design, development and debugging had already occurred, without cost to them.

Everybody wins.

Joe L.

You could have pointed out that there is a firm chance that a user developed firmware would boost sale of their product without costing them a penny for in-house development.

I pondered that issue but it seemed a bit like asking them to buy into a dream.

I think it's maybe better to wait until we have a good release with new graphics/features and then send it to them. :-)

Do we have a wish-list yet?
A wiki "how to" might also make sense - there is a lot of good stuff in this thread, but the thread is rather daunting!

Ian

Good idea guys , but sadly these OEM makers dont seem to think this way at all.I run another yahoo support group for a VERY good and cheap 2.5" HDD player from a Firm in China Called Keelai.

http://groups.yahoo.com/group/hddplayers/

I have tried for months now to even get a firmwarre update out of them,you would think me offering a support group would be great for them,as then they dont have todo it themselves,but despite many,many pleas and contacts with them , they just dont want to "play ball" in any way.All they are interested in is "selling units" , giving any type of support or listening to their users seems totally alien to them.Its such a great shame,as with the MG-35 the Keelai unit could be totally superb with just a little more development..

But if we dont at least try , then we don't have any chance...




And also...
Any improvements we make would be required under the GPL be shared with them in return.

If they desire, they would be able to incorporate the best of our user-development-community software into their next generation of hardware, again with minimal in-house costs, since the human factors engineering, design, development and debugging had already occurred, without cost to them.

Everybody wins.

Joe L.

...but despite many,many pleas and contacts with them , they just dont want to "play ball"...Maybe it’s a cultural thing? Human resources, development and talent do cost in the “west”, maybe they don’t value that in the “east” the same way we do (yet)?

Maybe it’s a cultural thing? Human resources, development and talent do cost in the “west”, maybe they don’t value that in the “east” the same way we do (yet)?

Yes I am pretty sure you are correct,every time I try to lay it out to Keelai , the response is sort of "Well why would we want to give any support and please the users??,thats the sellers job and anyway we have a new super product in the pipline,you can order 500 units if you like"

many times I have wanted to write a semi angry reply,but just walked away shaking my head , I suspect the same with be true with Al Tech,but we can hope...

It also seems to be the case that the so call "customer Techs" that we have email contact with , know less than we do ,this leads me to suspect that the actual firmware writing is done semi out of house,so to speak and maybe just tailored to the unit they are making my someone in house...

Problem for manufacturers is that by providing the source under GPL the warranty claims will also be higher due to users who flash their units with faulty firmware images. This may be a small number, but to the manufacturer it means extra costs.

In this field of products the product cycle is quite short. There are many competitors who offer the same devices and fast changing models. That means that supporting the community will not boost sales that much as we anticipate here. But surely I hope that Al Tech gives some response on the request.

Problem for manufacturers is that by providing the source under GPL the warranty claims will also be higher due to users who flash their units with faulty firmware images.

My sympathies with them on this count are limited because -
1) The GPL says what they have to do if they want to distribute GPL code. Complying with the terms of the licence are not an option. We use a lot of GPL code, and have a port of Linux to our own CPU architecture, and spend a lot of time worrying about our GPL/proprietary split. Seeing people totally ignoring the copyrights of those who have contributed to GPL irks somewhat.
2) We supply consumer equipment that does in-field reflash and have ensured that the flashing code (via USB) is never touched. You can flash anything you like into the rest of the flash - if the DFU loader detects the USB master, then it's reflash time.

If you don't do the hard work to handle being flashed with something imperfect then you also risk returns due to failure of power etc, during a normal reflash.

Ian

Hi all

ok the above site is ready i have uploaded all files and setup the areas again :)

hope it will help you all out

I've been asking questions on the fuse mailing list regards the best way to solve our version "disconnect" issue.

Brief summary:
- I have built fuse version 1.4 as newer ones don't work with our ancient 2.4.17 kernel. We'd need at least kernel 2.4.21 to use a modern fuse.
- ntfs-3g and djmount both require fuse after version 2.1, perhaps later.
- Fuse is currently at version 2.5.3 and the API does change regularly.

The options are -
1) Try moving to a later kernel.
2) Try modifying ntfs-3g and djmount to use an older fuse.
3) Try modifying fuse 2.5 to work with our old kernel.

Advice is that option (3) is probably best.

While I was asking this a chap said -

------------------------------------------------------
Ian, it is interesting as it also djmount that I want to add to
another embedded linux project
(mvpmc.sourceforge.net), until I ran into the .17 hurdle. If you
decide on backporting let me know how much work you envision. I am
hoping Hauppauge will provide us with a newer monta vista kernel but
the work isn't horrendous, I might work with you in testing the
changes in my environment. At the same time, I am working on the
configuration of the cross-compilers for the djmount library
dependencies, and if you are in the same state and want to discuss,
send me an email.
------------------------------------------------------

I'll make contact and we can track each others efforts but take a look at their pages and faq - they have made great progress!

Ian

gadgetmind, check your reason for editing! It seems you still have "figner" trouble! :D :D

gadgetmind, check your reason for editing! It seems you still have "figner" trouble! :D :D

There's nothing there that I didn't type very slowly and very carefully. :)

Ian

Hi!
mg-35 seem to be perfect for my needs. I need a nas that can store and plays any kind of media files and iso dvd is a plus.

With the new beta PB firmware, I've read that ftp functionnality is added with everyone read-write access. Is the ftp access is faster than the ndas access? As I have a laptop, the goal is to store all media file into this baby and acces it directly. So if I rip a dvd in iso, will the transfer will take 1 hour or so?

And the ftp access is interesting as I use my laptop now to do the joib. I can access the ftp via the web. Will future beta firmware will allow some kind of management to the ftp? like having a admin acount for read-write and a anonymous acount for read only?

BTW, is Samba nas is a future project? If so, it'll be VERY promising!

I would like to thank you guy for all the good work you do. As I really love technology this kind of product is really catching my eyes and with guys like you that upgrade this baby to make a perfect machine, I just want to say Bravo! and keep the good work!

Hi!
mg-35 seem to be perfect for my needs. I need a nas that can store and plays any kind of media files and iso dvd is a plus.

With the new beta PB firmware, I've read that ftp functionnality is added with everyone read-write access. Is the ftp access is faster than the ndas access? As I have a laptop, the goal is to store all media file into this baby and acces it directly. So if I rip a dvd in iso, will the transfer will take 1 hour or so?

And the ftp access is interesting as I use my laptop now to do the joib. I can access the ftp via the web. Will future beta firmware will allow some kind of management to the ftp? like having a admin acount for read-write and a anonymous acount for read only?

BTW, is Samba nas is a future project? If so, it'll be VERY promising!

I would like to thank you guy for all the good work you do. As I really love technology this kind of product is really catching my eyes and with guys like you that upgrade this baby to make a perfect machine, I just want to say Bravo! and keep the good work!Currently, ftp can write to the internal MG-35 disk ONLY if it is formatted as FAT32. It cannot if the disk if formatted as NTFS, as the NTFS driver in the MG-35 is read-only. An NTFS file system cannot currently be written to by anything except the NDAS driver and only if you have the serial number and key to enable it. Those facts limit any single file transferred via "ftp" to less than 2Gig. (The largest size file you can create on a FAT32 filesystem)

The same file size limit will prevent you from transferring any ".iso" for just about any movie since they average 4 to 5 Gig, even if you only get the main feature and 6-8 Gig for the entire movie.

Eventually, if this MG35 enhancement project is successful, the read-only NTFS driver will be replaced with a read-write version, and then "ftp" should work as you would like, and transfer of ".iso" images via ftp will be possible.

I don't know if anybody has any idea how fast the currently "unwritten" and "unimplemented" NTFS file system driver will be. So will it take an hour for a transfer of an iso...? well let's say nobody can answer that question.... at this time.

Like you, I am very happy to be following this effort from the sidelines, and will contribute at some point if I can (It is far too early in the effort for me to assist)

Joe L.

Hi!
thanks for the quick reply.

So for now, the best way to use it as a nas-alike and media server is to use it with the default bios installed.

Like I told you before, I will use it to store all media like a nas but as the ability to play media content directly. I forgot that fat32 as limitation of 2 Gb thats so sad!

BUT here is a possible workaround: to use ftp functionnality for web ftp transfer and ndas with ntfs, can I format a small partition (2Gb) in fat32 for FTP and a big ntfs partition for ndas access?

FTP will not be used for DVD iso but only for small files to be accessed via internet.
NDAS will be used to transfer all data and stores all media files currently on my laptop HD. FTP access was only a way other than the apparently slow ndas transfer to transfer data to. Maybe ftp acces is faster then ndas?

I know it seems a bit weird but I don't want acces data stored on a computer with this. I want to acces files on it's hd instead! so usig it as a media server not a media extender/client.

Does somebody can explain how slow is the ndas access? can I use this access as a mp3, movie etc hd so I can delete those file on my HD?

BTW many people are reporting a slow transfer rate via usa as it's only a usb 1.1 device? is that true? it should take long time to transfer 10 gig over usb!

thanks again!

All MediaGate users please put all questions, concerns, opinions in our official MediaGate forum.

MediaGateUSA (http://mediagateusa.s10.forumsplace.com/index.php)

Also the MG-350HD Cnet review

Cnet Review for MG-350HD (http://www.cnet.com.au/hometheatre/mediacentres/0,39035725,40091080,00.htm)

All MediaGate users please put all questions, concerns, opinions in our official MediaGate forum. Is this a request or a demand? :rolleyes: Is this an "official" MediaGate forum? Will there actually be manufacturer's representatives that will answer questions about firmware updates and the like? Right now, that forum looks a tad empty, I see lots more useful information here. ;)

Is this a request or a demand? :rolleyes: Is this an "official" MediaGate forum? Will there actually be manufacturer's representatives that will answer questions about firmware updates and the like? Right now, that forum looks a tad empty, I see lots more useful information here. ;)


Its a demand :D , No but really it would be more convenient to answer as much as possible and have Mediagate discussions in that forum. Yes there will be a manufacture representative on board giving as much help as possible.

As of now it is empty as it was just started several days ago, and with the new MG-350HD coming out very soon, we know there will be alot of questions on hand. Also we are looking for somebody who knows the Mediagate units inside out to give us a helping hand on moderating and answering consumer questions.

So give it time as the forum will continue to expand as all new things do.

Thanks

@anywareus

Welcome to this thread mate...

Are you guys really going to be serious about giving users some REAL support , in real I mean answering REAL questions ie not just "re-reading" stuff from the MAG-35 manual , and passing the buck to Al Tech?

Is it going to be a REAL support forum or just a "selling tool" for the MG-350HD?

Please don't think I am being "funny" here , but I think if you have read a good deal of this thread , you will understand that many of us Loyal MG-35 users feel a little bit "Cheated" by Al tech is their lack of REAL support , ie Firmware that matches the KR one,major bug fixes etc etc etc etc..

As we all know , the MG-35 is a great product , its just a great shame that many of use will not suggest it to people because of the lack of support from the maker.. I mean if we get the same support for the MG-350HD , as we have for the MG-35,why should we bother buying one?

Please don't think we are blaming you , all we want is some support..

Its only fair that we give you guys a chance , as a gesture of good will , how about getting Al Tech to release the GPL Kernel sources , as they are bound todo under the license , as discussed here..

@anywareus

Welcome to this thread mate...

Are you guys really going to be serious about giving users some REAL support , in real I mean answering REAL questions ie not just "re-reading" stuff from the MAG-35 manual , and passing the buck to Al Tech?

Is it going to be a REAL support forum or just a "selling tool" for the MG-350HD?

Please don't think I am being "funny" here , but I think if you have read a good deal of this thread , you will understand that many of us Loyal MG-35 users feel a little bit "Cheated" by Al tech is their lack of REAL support , ie Firmware that matches the KR one,major bug fixes etc etc etc etc..

As we all know , the MG-35 is a great product , its just a great shame that many of use will not suggest it to people because of the lack of support from the maker.. I mean if we get the same support for the MG-350HD , as we have for the MG-35,why should we bother buying one?

Please don't think we are blaming you , all we want is some support..

Its only fair that we give you guys a chance , as a gesture of good will , how about getting Al Tech to release the GPL Kernel sources , as they are bound todo under the license , as discussed here..


The ultimate goal of the Mediagateusa forum is to gather Mediagate users and to discuss thier concerns just like the AVS forum. Although I agree that there was not enough REAL support, this is what we are hear to fix. Even though this is out of our freetime, we are trying our best to support the Mediagate product in the US and Canada Market.

Although you must realize that their are no perfect products in the world, we can only try our best to satisfy your concerns. We gather information from Altech and provide you with what we get.

As of now we can only answer questions that we have tested ourselves and since this is on our sparetime basis please be patient, as we can direct other questions to Al tech for better support.

The ultimate goal of the Mediagateusa forum is to gather Mediagate users and to discuss thier concerns just like the AVS forum...
Please don’t get me wrong. What I love with AVS is the critical mass of knowledge, innovation and the will to share information and support each other. To me that’s what makes user communities such AVS special and highly interesting. I have benefited a lot from other users contributions over the years and that is my main driver to take the opportunity to give something back.

You are now suggesting that I should spend my time elsewhere, that I should help you build a forum. You have to excuse me for asking what’s in it for me and also for questioning what your key driver is.

If it’s like you say a question of providing us customers with better support then I’m more than willing to help. But I then have to ask my self if I am talking to the right person? Are you empowered to actually make a difference like providing the GPL source code or a new firmware in line with customer specifications? If not I guess my time is better spent at AVS.

Please prove me wrong and publish GPL source code, get us in direct contact with the lead developers at Al Tech or anything else that would impress me!

The ultimate goal of the Mediagateusa forum is to gather Mediagate users and to discuss thier concerns just like the AVS forum. Although I agree that there was not enough REAL support, this is what we are hear to fix. Even though this is out of our freetime, we are trying our best to support the Mediagate product in the US and Canada Market.

Although you must realize that their are no perfect products in the world, we can only try our best to satisfy your concerns. We gather information from Altech and provide you with what we get.

As of now we can only answer questions that we have tested ourselves and since this is on our sparetime basis please be patient, as we can direct other questions to Al tech for better support. anywareus,
In a prior post you described how you are now the exclusive distributor for USA and CA for the Mediagate product. To me, that indicates you import them and then sell the units to retail outlets we in turn buy from.

That might be a "sparetime" import business for you, but your involvement is more than your "freetime" comment statement indicates. Basically, it is YOUR business.

We will be patient with you, but most of those involved lately in this thread are looking to improve the user interface of our MG-35 players. Why??? because Altech has stated that they do not consider it important enough to allocate time and resources... Why? because they have a new-improved model coming out any-day-now. Oh, they hinted a new release of firmware might be offered soon for the MG-35, but made no mention of when, or what changes it includes.

Trust me, if the MG-35 had a better, more wife-acceptance-factor friendly user interface, and better file system management, we would all be enjoying it, instead of being somewhat frustrated by its current flaws. Odds are we would not be working towards improving it ourselves.

Collectively, the folks involved in this thread will be able to add the features we desire. I'll bet is is only a matter of time. It would be great if the GPL was followed so we could build on the exact firmware we require. Yes, we will probably "brick" a mediagate or two. On the other hand, many will be "bricked" because a power or network failure occurs at the time of upgrade by normal consumers. (It has already occurred at least once we know of) Do you handle returns from your retail outlets?

If you wish to post here in AVS and ask us point normal folks with the usual "How Do I play an MP3 question" to your new forum, fine... but to me, somehow, at this point in time, your forum is not the place for the hardware/software functional decomposition currently taking place here. If you wish to participate in this thread too, geat, we will welcome your involvement. Just keep in mind this thread is not for your commercial "Here is a link to a review of my new product" stuff. That will get you nowhere.

This exploration of the firmware in the MG-35 is being done in OUR freetime. You are in a position to leverage from Altech information we might have a harder time getting. As of now, they are in violation of the GPL license. Perhaps you could ask them to comply... that would help us. We can then decide if the GPL tarball is then available on your forum, the Yahoo forum, the forum set up by one of this thread's participants, or somewhere else...

I guess what I'm saying is don't expect a mass migration to your forum from AVS... Until there is a good reason to participate there, most will not. Unless there is a good reason to act as a volunteer "moderator" on your BUSINESS forum, most will not. Perhaps you forget... we purchased the MG-35 to enjoy music and movies, and for most of us, that is how we would rather spend our "freetime"...

Joe L.

I never saw a manufacturer forum where ppl discuss possible firmware hack.

What I understand here is that many ppl here are able to modify the firmware AND try to have some clue from the manufacturer to be albe to correct some issue on an OPEN SOURCE os.

why?

be able to use it as a FTP server for easy file transfer and maybe use it as a personnal internet FTP server.

Adding Samba to make it a real NAS storage to improve transfer speed, be able to use it without any software need for accessing the unit as the usb transfer seems to be in the slow usb 1.1 transfer speed. Adding btw other os compatibility as the client software is limited to windows 2000/xp.

Many ppl here are using a nas storage in conjunction with this unit. It should be really cool to enable a real nas storage with the MG-35 to make an all around purpose unit.

I'm about to buy this but what's annoying me is the 1.1 usb speed and the slow (can someone confim this?) NDAS transfer speed as I will have to transfer about 80GIG of média in it's harddrive.

I'll be waiting to have a good hacked bios before buying the unit. If mediagate is able to helping those modders to make a better product, I think sales will follow.

We opened this forum to gather concerns to make improvements for the current and future products. We need user opinions to give us feedback so we may have future firmware upgrades. So we will not open the issue of how to "HACK" into our Products, but we will disscus some other stuff that only we know about.

This is the offical user forum for the Mediagate US and Canada market, official meaning, made by the representative, and read by the representative, and answers by the representative.

Since we currently do not have the staff to check the forum every hour we are requesting technological support from viewers in this AVS forum to help us answer technological questions regarding the Mediagate products. Yes forum Moderating is time consuming and by helping us, we can provide our Moderators with future products of the Mediagate line before anyone else may get there hands on it to test/review and keep.

We dont expect a mass migration to hop from forum to forum but again this is the official mediagate forum so any one is welcomed back anytime to check the news, update firmwares and deals, also about the new upcoming products.

Feature request for a future firmware:

- Would it be possible to allow us to delete a file over the network PC from the MG-35?

This is something that would be really usefull.

Thanks.

... this is the official mediagate forum so any one is welcomed back anytime to check the ... update firmwares ...Looking forward to that!

... and the slow (can someone confim this?) NDAS transfer speed ...
Yes I can. The LAN in my house is in good condition. It hosts both Linux and Windows servers. I stream live tv using my Dreambox (http://www.dream-multimedia-tv.de/) (a GPL-oriented PVR and STB), VLC (http://www.videolan.org/vlc/) (open source media player) etc.

I bought my MG-35 because I wanted to solve the problem with my kids scratching their DVDs. My initial idea was to make backups as ISO-images on my Linux media server and serve them to my MG-35 via a SMB share (using Samba). The idea was good but I got stuttering while playing DVD ISO-files from my Linux box, especially action scenes witch complex audio and video. It works better from a Windows share (for some reason) but I finally bought a 300GB disk for the MG-35 (making it possible to bring the collection along to the summer house). My kids DVD collection is about 180 GB of data and I initially tried to transfer it to the new drive using NDAS (I got a Freecom unit so I got the key bundled with the unit). The transfer rate was dreadful; transferring a ripped DVD of about 4GB took something like 20 minutes. I then removed the MG-35 from the AV-rack and brought it to my PC and connected it trough USB. The transfer speed was much better but it still takes some time transferring 180 GB of data.

I selected the MG-35 because it was cheap, read ISO-files and SMB-shares. I didn’t want my media player to rely on proprietary server software (thank god there are several UPnP AV servers evolving from both open source and other parties). NDAS could have been user friendly but feels a bit awkward. Read-writable services for CIFS, SMB, FTP or even NFS would have been better from my point of view (more in line with common open standards and a wider range of supporting software). I still find my MG-35 useful as a cheap media player but I will soon lose interest in it if I can’t find a way to tweak it further according to my needs.

Anyone marketing a thing like the MG-35 should take a look at user driven modding projects like NSLU2-Linux (http://www.nslu2-linux.org/wiki/Main/HomePage). What would products like Linksys NSLU2 and the like be without it, just a cheap NAS device among others! User modifications are what makes it interesting and I can prove that it has improved sales figures (almost everyone I know bought at least one just to play with). It is the same with my Dreambox (http://www.dream-multimedia-tv.de/) etc.

If that is not enough learn from the banking business. Isn’t it ironic that I feel that I get better service using my internet bank compared to old school banking offices? I happily do the job my self if only the bank provide me with the opportunity! Isn’t that an amazing transformation of an old and well established business model? Just makes me wonder what keeps the media industry from being as creative! One thing I do know is that if nothing else pushes me towards open source solutions, DRM and proprietary solutions will!

Just sprung to my mind, maybe we could harvest some from the NSLU2-Linux (http://www.nslu2-linux.org/wiki/Main/HomePage) project? It is ARM, it's a NAS, they use OpenEmbedded and it is packages oriented. Just a thought...

Ps. They got some interesting information regarding NTFS drivers for Linux: (http://www.nslu2-linux.org/wiki/FAQ/NTFS)
There are three NTFS drivers for Linux in existance:

* Captive - http://www.jankratochvil.net/project/captive/

This driver has full read/write support for NTFS because it uses a wrapper around the Windows ntfs.sys binary driver. Porting this to the NSLU2 would require finding a ntfs.sys compiled for ARM and then trying to port the Captive wrapper. Finding a ARM compatible ntfs.sys from Microsoft is basically impossible unless Microsoft decide to port Windows to ARM. Using something like QEMU to emulate a x86 platform to run the ntfs.sys driver is in theory possible but it is not an ideal solution and would entail a large amount of work. You could for example boot a full i386 linux installation in qemu. This installation could access the NTFS via a network block device from the ARM side of things. The i386 qemu could then export the accessed file system via NFS or other means back to the ARM. Short answer is still no. Plus it would be rather slow.

* Linux NTFS project - http://www.linux-ntfs.org/

This is a reimplementation of the NTFS file system as a normal Linux driver. As such, it is probably more portable, but it is also more limited. Write support is extremely limited (can only modify existing files, no file size changes), and probably not useful to most NSLU2 users.

Recent (April 2005+) builds of OpenSlug come with the Linux NTFS project kernel module in the flash (though not installed). mount -t ntfs /dev/sdb1 /mnt (with appropriate device/directory) will mount a Windows NTFS partition for read access. At present the (experimental) write access is not compiled in - so the mount is read-only.

* Commercial Paragon NTFS for Linux - http://www.ntfs-linux.com/

This is a commercial package which fully supports NTFS read and write. Linksys has included a copy of the driver in 2.3R63 and above.

The Paragon driver is available installation in Unslung as a ipkg. Install it (ipkg install ufsd) and the ipkg will download the Linksys firmware, extract the kernel module and install it. We can not distribute the module itself and must do it via this method.

We opened this forum to gather concerns to make improvements for the current and future products.Excellent...
We need user opinions to give us feedback so we may have future firmware upgrades.This is the step that is sorely needed. We both win, you (with improved firmware) will get far better "reviews" and more sales, we will get better products for our homes and be your best salepeople as we demonstrate our units to our friends. A win-win.
So we will not open the issue of how to "HACK" into our Products, but we will disscus some other stuff that only we know about.Never expected you to tell us how to "hack" your product. You should understand though ... the GPL license requires Antech share modified source back to the Linux user community so it may benefit. This is in return for how Antech benefitted by not having to write from scratch an operating system for your media player. We are not asking for propritary code, but for what is legally required under the GPL.

We will certainly welcome tips, firmware and product announcements, disclosure of possible "hidden features" or "easter-eggs" (if you can, and if they exist) Press X/Y/Z on the remote to "reboot" or similar. Press A/B/C to sort differently, or to switch from movie to music mode, etc. A list of the numeric shortcut commands that are not in the user manual would be a nice first step.
This is the offical user forum for the Mediagate US and Canada market, official meaning, made by the representative, and read by the representative, and answers by the representative.

Since we currently do not have the staff to check the forum every hour we are requesting technological support from viewers in this AVS forum to help us answer technological questions regarding the Mediagate products.
understood. As long as it is not days or weeks before a company rep responds it will be fine. Understand your new forum is not the focus of your business. (sales to your retail distributors apparently is your focus)
Yes forum Moderating is time consuming and by helping us, we can provide our Moderators with future products of the Mediagate line before anyone else may get there hands on it to test/review and keep.You will find folks willing to help if they think they can benefit, or beta test, or get their hands on newer products. At least the parties win by working together.

We dont expect a mass migration to hop from forum to forum but again this is the official mediagate forum so any one is welcomed back anytime to check the news, update firmwares and deals, also about the new upcoming products.Fair enough, and I again extend the invite for you to participate here as we work to make the MG-35 even better. As I mentioned earlier, we are equally obligated to share improvements we make on GPL code in return. You win with more sales of a product with a much improved user interface. We win with a better media player.

Joe L.

Again we are trying are best to get major support from Al tech, so bare with us. In the meantime it seems within the next few day a firmware upgrade 1.4.5 will be available, lets keep our fingers crossed.

thanks for everyones understanding and patience

Is this useful or is it old news... (http://user.it.uu.se/~alse7905/EM85xxDVD/)

Has anybody had any luck with this? they advertise it in thier promos, but know one seems to know anything about it!!!! :confused:

Cheers Paul.


The airlinktek website states:

"The MG-35 can be configured in collaboration with web-based movie distributor as a set-top box or media gateway to access, play and/or download the legal movies from the website directly without home PC."

I would like to setup a website with divx encoded videos for which I have rights to and share them with subscribers that will own MG-35s. I need to know how to set up the MG-35 to download the videos from the remote site with out needing a computer. I can setup the site in any way needed to be compatible with the MG-35.

I would really appreciate assistance with this.

"Hack" your products indeed we should demand a refund for your sub-par product with hacked dvd code. Your product is worthless as is. This reminds me of the Rockbox project. Back in the day Archos left their jokeboxes (intended spelling) with buggy firmware and substandard interface. When it was over with we had games, better play control even grayscale video etc...

I've tried out a couple mp3 players, video players only to find they all have that great korean know how in making a nice product but, for some reason can't make a halfway decent firmware. None of them.

I'm personally glad these guys want to work on the firmware I had thought about "hacking the h*ll out of it (ripping out the insides) and sticking a mini itx compuer in it..to be my media player. That way I could install whatever software I want into it.

Come on open up the firmware and anything released will be considered beta software and anyone that messes up their player consider it out of warranty. Heck I don't care because the player as is....is useless anyway.

Actually come to think of it..maybe you could talk to the rockbox guys and see if you can use rockbox as a replacement audio player section...would be very very cool.


In the meantime warn others about this flawed software and tell them not to buy these crappy mediagate products...what a sad sad Christmas Present for me!


Chaos.



If I made too many mistakes typing I have nerve damage in one hand




We opened this forum to gather concerns to make improvements for the current and future products. We need user opinions to give us feedback so we may have future firmware upgrades. So we will not open the issue of how to "HACK" into our Products, but we will disscus some other stuff that only we know about.

This is the offical user forum for the Mediagate US and Canada market, official meaning, made by the representative, and read by the representative, and answers by the representative.

Since we currently do not have the staff to check the forum every hour we are requesting technological support from viewers in this AVS forum to help us answer technological questions regarding the Mediagate products. Yes forum Moderating is time consuming and by helping us, we can provide our Moderators with future products of the Mediagate line before anyone else may get there hands on it to test/review and keep.

We dont expect a mass migration to hop from forum to forum but again this is the official mediagate forum so any one is welcomed back anytime to check the news, update firmwares and deals, also about the new upcoming products.

So we will not open the issue of how to "HACK" into our Products


Careful with the word "our" - once the sale is complete, the hardware is owned by the purchaser. It's up to them what software they run on it.

And the software that's supplied is for the most part not copyright Al Tech. The majority is covered by the GPL and Al Tech (and yourselves!) are distributing it without a licence.

Now, you'll have to excuse me, I've got some legal and ethical hacking to get back to. :-)

Ian

* Linux NTFS project - http://www.linux-ntfs.org/

This is a reimplementation of the NTFS file system as a normal Linux driver. As such, it is probably more portable, but it is also more limited. Write support is extremely limited (can only modify existing files, no file size changes), and probably not useful to most NSLU2 users.


For the avoidance of doubt, this is what the MG-35 has and write support is compiled in. The NTFS disk can be unmounted, remounted and files can be written to it via FTP.

But there are heavy caveats.

Ian

Rapidshare link for Official English Beta Firmware for MG-35 1.4.5 - Tested by myself , seems to work ok , upgraded fine on my MG-35 - report to follow..

****USE AT YOUR OWN RISK****



http://rapidshare.de/files/28074505/MG-35_1.4.5_Official_English_Beta_Firmware.rar.html

We pressured Al Tech to get us the latest firmware and it is available now. It is a direct port from the kr version so it is a beta version.

Please discuss your opinion here as well as at the official MediatgateUSA forum located in my sig.

Thanks to all!

It would be a bit classier if you put it on a server that doesn't run you through a bunch of hoops just to download a file. :) Thanks for providing it, don't mean to look a gift horse in the mouth.

It would be a bit classier if you put it on a server that doesn't run you through a bunch of hoops just to download a file. :) Thanks for providing it, don't mean to look a gift horse in the mouth.

I agree mate , but sadly hosting is not free these days,so I guess it is the best we can do for now,as the link will never expire and also is not limited to bandwidth , like many other Free Services are , if you know any better free hosts that provide the above I am always willing to listen...

Regards

Teddy

der ppl that is what i am offering at the above url , all the files are on the site etc, anyway good to see the 1.4.5 is out :)

kewl this is my 5th post, i can now post url's :)

What's new/fixed in the MG-35 1.4.5 beta release?

Guys,

I've been thinking (and coding) a program that will remount all HD's in RW/EXEC mode and attempt a SAMBA/Windows Sharing command ... the basic code does:

loop:
check for fat32/ntfs drive
if found remount it in RW/exec mode and break
wait for 3 seconds, loop around upto 3 times
if there are any 'successes' it''' then look for a /hdd/sbin/init.sh file and run that

this way we dont have to reflash our MG's to run new code ...

i'll post it to adunder when it's done but i need some testers to see if it all works correctly with NTFS & Samba drives

any suggestions/thoughts ????

What's new/fixed in the MG-35 1.4.5 beta release?


I went to the trouble of putting a read_me in the archive.

----------------------------------------------------------------------------------------------------
English Version MG-35 Firmware 1.4.5 Beta

1) DTS problem in DVD Manager fixed

2) Memory allocation is done for Slide show.Photo quality would be better.If back ground music file size is big, that could cause some noise or sudden stop in music play.

3) Some other interanl bug fixed.

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

As you can see , as clear as mud really , from the limited testing I have done so far , VERY little has changed , lip sync and stuttering on CORRECTLY encloded Avi's is stil a big issue for me.. Maybe they just took 1.4.5 and hex edited the version no. - who relally knows?....

I'm starting to believe that they just change the version # and nothing is actually done. Horrible horrible company. Distributing the firmware on Rapidshare is well deserving.

What we want to see in firmware updates

1.Overhaul primative interface
2.Fix Divx playback issues
3 Interactive Manual on the thing
4.Dancing Cow background


anything other than....
When background song churning fix error with display fix onto pixel

The chipset it self does not support AVI file, this version of 1.4.5 is basic change of the korean 1.4.5 to the english version thats it, and for those who think the korean version is better that is wrong. anyways, please provide the Bugs on the Mediagate forum, because that is the only way AL-tech will see it.

once again, we will try our best to fix bugs little by little, please understand we are human too.

The chipset it self does not support AVI file, this version of 1.4.5 is basic change of the korean 1.4.5 to the english version thats it, and for those who think the korean version is better that is wrong. anyways, please provide the Bugs on the Mediagate forum, because that is the only way AL-tech will see it.

once again, we will try our best to fix bugs little by little, please understand we are human too.

When I mean Avi , I mean various Divx /xvid files , if you check out these forums you will see many, many people complaining of Lip sync and jerky issues on the MG-35 - as far as I know Al Tech has never updated the Divx or Xvid codecs in ANY of their firmware releases,even though the codecs have been changed many times by their producers - I wil post this info yet again at the Mediagate forums , as have a few other people..

anywareus

As I am a reseller of the Australia Anyware, what area do you work in the US base??

tgault
Email me devilsown01@adunder.org and I will send you the details for your upload to the http://www.adunder.org site etc.

as far as I know Al Tech has never updated the Divx or Xvid codecs in ANY of their firmware releases,even though the codecs have been changed many times by their producers

Despite giving you a well-meaning hard time over GPL issues, I do appreciate your efforts to improve the quality and support of the MG-35.

But Al Tech do seem to be a bit of a brick wall. :-(

Ian

As you've all perhaps seen :-) , I'm approaching Al Tech via several routes to try and encourage them to address their legal issues regards copyright infringment in their products.

However, it's worth noting that there are issues we also need to ponder -
1) Are we allowed to distribute unmodified MG-35 flash images? I guess that it could be argued that Al Tech have given implied consent.
2) What about modified images? These contain elements that are proprietary to Al Tech and Sigma Designs. While they play fast and lose with Intellectual Property law, I guess we can make moral arguments that it's OK for us to, but we should give consideration to alternatives.

Perhaps we need a tool (windows and Linux!) that will assemble a new flash image by automatically extracting the proprietary parts from an image? I know this isn't as neat for people as downloading a simple flash, but I'd argue it's better that we occupy the moral high ground.

Ian

I agree mate , but sadly hosting is not free these days

I'm not sure that my personal web space has any bandwidth restrictions. I'm just checking with the chap who runs my ISP to see. A 3MByte file isn't exactly going to cause melt-down!

I've downloaded the 1.4.5 firmware and will play with making a trackerless torrent and people can see if this works for them. I'd recommend uTorrent if you don't have a ********** client.

What's best for people, a RAR as it is now or a ZIP? My RAR unpacker is deeply ugly but maybe people have better ones and find RARs more pleasant than I do?

Ian

I'm not sure that my personal web space has any bandwidth restrictions. I'm just checking with the chap who runs my ISP to see. A 3MByte file isn't exactly going to cause melt-down!

I've downloaded the 1.4.5 firmware and will play with making a trackerless torrent and people can see if this works for them. I'd recommend uTorrent if you don't have a ********** client.

What's best for people, a RAR as it is now or a ZIP? My RAR unpacker is deeply ugly but maybe people have better ones and find RARs more pleasant than I do?

Ian

hi mate, you can always upload it to www.adunder.org if you like.

What's best for people, a RAR as it is now or a ZIP? My RAR unpacker is deeply ugly but maybe people have better ones and find RARs more pleasant than I do?
I would say ZIP (based on wider application support = better chance that anyone might be able to extract it with whatever software already installed). I personally recommend 7-Zip (http://www.7-zip.org/) for the ones that would like to change from a commersial archiver (e.g. WinZip, WinRar etc.) to a free alternative (that is as good or even better).

However, it's worth noting that there are issues we also need to ponder...God point...

Perhaps we need a tool (windows and Linux!) that will assemble a new flash image by automatically extracting the proprietary parts from an image?I could do that, something user friendly, GUI, drag-and-drop, or whatever needed...

Windows, no problem with the GUI (I could put something native Win32 together in minutes). Linux ... I would probably have to use Python + WxWindows (my only experience with Linux GUI development so far)... Such a solution could also be used on a Win32 platform (Python and WxPython is cross platform)... Just let me know what needs to be done...

hi mate, you can always upload it to www.adunder.org if you like.

OK, I'll reregister, but I'm sure someone else will beat me to it. :-)

Ian

However, it's worth noting that there are issues we also need to ponder -
1) Are we allowed to distribute unmodified MG-35 flash images? I guess that it could be argued that Al Tech have given implied consent.

I got full email concent from anywareus before I distributed the file - being as they are helping us to obtain the firmware,It only fair we honour what they want re distributing





2) What about modified images? These contain elements that are proprietary to Al Tech and Sigma Designs. While they play fast and lose with Intellectual Property law, I guess we can make moral arguments that it's OK for us to, but we should give consideration to alternatives

I agree here totally,as you know from my previous posts,this is why I suggested using a "3rd Party" free host in the first place,as to avoid any legal matters with members here.It may mean that it takes 5 secs longer to download,but I think its worth it.none of us really want a "Cease and Desist Letter" Do we?


Perhaps we need a tool (windows and Linux!) that will assemble a new flash image by automatically extracting the proprietary parts from an image? I know this isn't as neat for people as downloading a simple flash, but I'd argue it's better that we occupy the moral high ground.

Yes,this is a really great idea and would save anyone from any legal issues.
Another approach you might want to consider (used in a DVD firmware group I used to be in) was to use one of the many "patch generator" programs that are available - ie it takes the "stock" firmware and compares it to a "hacked" flash file , it then generates a patch that you apply to the "stock" firmware and it produces a "hacked" flash file,that the user can then flash.The file that gets distributed is only a "patch" file,so no legal worries.Just something you might like to consider.

Just a side note,I used Winrar as these days I use nothing else , zip is so outdated these days when it comes to password protected files,splitting of archives etc etc.I cannot understand why anywareus distribute the file unpacked , this is very dodge as its very easy for the file to become corrupt during ftp etc,at least "wrapping" it with rare or even zip , protects it from any damage that might cause a bad flash..

I agree here totally,as you know from my previous posts,this is why I suggested using a "3rd Party" free host in the first place,as to avoid any legal matters with members here.It may mean that it takes 5 secs longer to download,but I think its worth it.none of us really want a "Cease and Desist Letter" Do we?


does this mean you will need adunder.org or you wont be needing adunder.org??

@DevilsOwn

Its up to you matey really,should you want to risk any legal issues.Having been involed with this type of stuff in the past,I myself , would not use my own personal web space.Having said that,we are all grateful for the time and trouble you have devoted to this project.. its always good to have as many "mirrors" as possible..

...I cannot understand why anywareus distribute the file unpacked , this is very dodge as its very easy for the file to become corrupt during ftp etc... I thought about that since I received the uncompressed update directly via email from MGsidekick. Since he sent it that way, no checksum or anything, I decided to throw caution to the wind and updated my MG-35 simply by detaching the update from the message and writing to the MG's HDD. I was pleased to observe it checking the update before flashing. So... That being the case, further binary integrity assurance is probably redundant.

Just posted at the Al Tech Support board:


[MG-35] v1.4.5 Firmware

Does not say anything about it being still a beta?? - Anywhereus , is this the same as we already have? or is it now a "release" version - please can you confirm , as it looks like Al tech may be releasing betas on their site and not saying so??

http://www.airlinktek.com/english/firmware/MG35_1.4.5_Eng.upgrade
--------------------------------------------------------------------------------------------------------------

[MG-350HD] v1.0.4 Firmware (Simplied Chinese)

The first "update" for the MG-350HD - might be interesting for those "in the know" to take a look at.. as usual no read me included..

http://www.airlinktek.com/english/firmware/MG350_1.0.4_CHS.upgrade

Wow The MG-350HD now has sound files built in and plays a cute little animation at bootup - check this out..

http://rapidshare.de/files/28170560/mediagate.avi.html

Also from the GUI it looks like the slide show and mp3 playing has random and other features..

I guess its just too much to expect to ever see any of these features on the MG-35?

Hello,

Would updating the codecs on the firmware be something that the "hacked" firmware modifications team be able to do?

Would updating the codecs on the firmware be something that the "hacked" firmware modifications team be able to do?

Everything is possible, given enough work. But without the information on the hardware, khwl.o, etc. it's deeply non trivial.

But dead easy for Al Tech to do - the hardest part is the extensive testing that would be required to make sure they haven't regressed. Our approach would be to have an automated test suite that runs hundreds of test case through the system, captures the output, and reports problems, but something tells me that Al Tech don't work this way!

Ian

I myself dont know , that is for one of the other guys to tell us,but if it is possible,it is looking more and more llke al Tech are forcing us todo it ourselves,as its looks like they are not interested in fixing this themselves,or at least letting us know if it can be fixed for not..

Hi all,

I just got my replacement MG-35 today, so I should be back in the game now. The new one has the same hardware revision number printed on the board, but it came with the NDAS ID and write key on a sticker on the device (it's a freecom).

First off, since Anyware-US is now distributing the MG-35 and offering the firmware images in the US, they are now legally culpable in US courts to provide the full source code for GPL'ed software. No if's and's or but's about it.

Freecom Germany would probably be a better legal target though. As I understand it, the laws in Germany provide for immediate injuctions against sales and distribution in cases of copyright dispute.

I still wouldn't worry about the distribution of modified firmware images. If any legal challenges are presented, it would probably consist of a cease and desist letter, which is easy to comply with. Anything stronger could result in a countersuit for the GPL violations and I seriously doubt that ALTech wants to put their feet into those waters.

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

The v1.4.5 firmware image provided by anywareus and the "official" ALTech version are exactly the same. No differences at all.

"Containerizing" the firmware image in a zip or rar file is somewhat redundant. There are already 2 separate checksums built into the file. Granted, the checksums are a simple dword addition routine, but it should be good enough for simple transmission errors.

Also, there is a korean v1.0.5 available for the MG-350 if you check the korean site. Yet again, support for alternate languages is lagging behind. I'm guessing that they don't have any real translators on the payroll.

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

Codec updates... So far as I know, there's no real way to update the codecs. The EM8511 does the decoding in hardware, so new software is unlikely to be able to do much. Perhaps some minor alterations would be possible, like better a/v sync by separating the files into their component streams before sending them to the chip for decoding, but it seems unlikely.

On a normal computer it's possible to update the codecs since they are implemented 100% in software. On the MG-25/35/350, they are implemented in hardware.

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

From all the searches I've been doing online, it looks highly likely that the Sigma SDK comes with several example executables. These probably include dvdplayer.bin, mp4play, mp3play and fileplayer.bin. Another example app that I've seen references to is called netplayer. This should be capable of playing content directly from the net, such as internet radio.

Why ALTech never bothered to implement this is beyond me.

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

If it is decided that distributing modified firmware images is a bad idea, then a util that rips apart the firmware images and reassembles them is probably a bad idea. We're talking some serious work here, and we don't really know what is copyrighted by ALTech and Sigma and what isn't.

The app would have to be capable of splitting out the firmware headers (there are 2), the bootloader, the linux.gz and the cramfs image. It would then need to extract the cramfs image, insert the new files, then recreate the cramfs image. Finally it would need to check the cramfs image for consistency, reassemble all the parts, then recalculate the checksums and sizes for the 2 headers. Not exactly a simple task.

A better option would probably be a binary patch like teddystacker suggests. Of course, given the fact that the cramfs image is compressed, the patch wouldn't be that small.

I would also have to guess that there is very, very little in the firmware image that is copyrighted by ALTech. Given that they had to sign an NDA with Sigma to get the dev kit, and the fact that the MG-35's binaries look extremely similar to other Sigma based players, ALTech can probably only claim copyright on SOME of the JPG and PNG images and the "upgrader" binary. Though, the upgrader binary probably contains GPL'ed source code as well, so even that's iffy.

Also, the number of binaries that seem to contain GPL'ed code is so extensive that Sigma Designs can probably lay claim only to the bootloader and the khwl.o kernel module. The ndas modules are probably copyrighted by Ximeta, though much of the NDAS linux code (except the NDAS core) has since been made open source.

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

Hidden deep inside the recesses of Google is an HTML conversion of a PDF file that is no longer available. The PDF file is a datasheet for the EM8400 processor. There are bound to be differences, but much of the core is probably very similar.

One thing I noted is that the EM8400 doesn't seem to contain specific JTAG or serial pins. Then again, there aren't any embedded systems that use only the EM8400 as a processor, so I still hold out hope for the EM8500.

Anyway, if you'd like to see it, click here (http://www.google.com/search?q=cache:kp5o5C0ET3QJ:www.uni-klu.ac.at/~akoenig/activy2003/EM840x10a.pdf+em8400+databook&hl=en&ct=clnk&cd=1).

That's about all I've got for now..

pb

@PB

Very good to see you back,your posts have been VERY much missed here in the last few days..

When and if you get the time (I fully understand you must be VERY busy with your upcoming move) , is there any chance you could assemble a firmware with the New Graphics from palmqvistr inserted? - think you should use maybe stock 1.4.4 (as 1.4.5 does appear to be even worse).I know myself,and a few others would dearly love to see what the update Gui looks like when on the machine...

Kind regards and thanks

Teddy

Mediagate 35.
If you could help I would be greatly gratfull.
I have just bought a MG35 with a 200gb hard drive. It pluged in no problems to the network and streams off the network great. It will not recognise the hard drive or info on it. I first formated it 200gb NTFS and no go so last night formated it 20gb Fat32, and 80 gb NTFS and 90gb NTFS. Still won't recognise internal hard drive.
Updated firmware from 1.4.3 to 1.4.4 and no go, 1.4.4 to 1.4.5 and still no go.
Hard drive work perfectly on usb
Also where do I get a NDAS 20 digit number and write number.

Mediagate 35.
If you could help I would be greatly gratfull.
I have just bought a MG35 with a 200gb hard drive. It pluged in no problems to the network and streams off the network great. It will not recognise the hard drive or info on it. I first formated it 200gb NTFS and no go so last night formated it 20gb Fat32, and 80 gb NTFS and 90gb NTFS. Still won't recognise internal hard drive.
Updated firmware from 1.4.3 to 1.4.4 and no go, 1.4.4 to 1.4.5 and still no go.
Hard drive work perfectly on usb
Also where do I get a NDAS 20 digit number and write number.

Just about to go to bed - but one thought - is the Hard disc jumper set to MASTER Not Cable select?

I have a 320gb in mine formatted one single NTFS Primary Partition.

Ref the NDAS numbers , if they are not on a sticker on the bottom of your machine ,you have to order it from a website and it will cost you $20 - not all MG-35 come with a free key,as I found out :-)

Sorry I cannot help more atm

Regards

Teddy

Mediagate 35.
If you could help I would be greatly gratfull.
I have just bought a MG35 with a 200gb hard drive. It pluged in no problems to the network and streams off the network great. It will not recognise the hard drive or info on it. I first formated it 200gb NTFS and no go so last night formated it 20gb Fat32, and 80 gb NTFS and 90gb NTFS. Still won't recognise internal hard drive.
Hard drive work perfectly on usb.That is exactly how mine acted until I set the jumper to "master' It would work as the usb drive and could be partitioned and formatted, but not recognized by the mediagate processor.

Check the jumpers on the back of the drive.

Joe L.

Thanks for the help very much appreciated.
I had checked the ladle ond on seting up from the manual it said to Master the drive and it came Cable Select so changed it to Master.
After reading your posts I reset it to Cable select and it works perfectly so the Seagate Hard drive Lable must be wrong.
Will get on to the suppliers for the NDAS on Monday,

Thanks again.

I run my MG-35 straight off a NAS that it is directly connected to. One thing I would like to see in a modified firmware is either a "Favourites" on the main menu or a way to automatically set a start up selection.

At the moment I have to select Network, then my NAS after a network scan delay. I have to do this every time even though there is no HDD (why does it give me the main menu if I can't select an internal HDD??). The network scan is also the longest wait and is redundant for me as I only stream from one device (as I am sure most people do).

I just got my replacement MG-35 today, so I should be back in the game now.


Hurrah!


Freecom Germany would probably be a better legal target though. As I understand it, the laws in Germany provide for immediate injuctions against sales and distribution in cases of copyright dispute.


I have been bugging Freecom UK and they now say they have passed it to the product manager in Holland. They have said they will prepare an up-to-date GPL release!


I still wouldn't worry about the distribution of modified firmware images.


You might be right. It's just that I'm in the consumer electronics business and spend a lot of time making sure that everything is GPL/NDA/whatever clean so I carry it through to my private life. :-)


Codec updates... So far as I know, there's no real way to update the codecs. The EM8511 does the decoding in hardware, so new software is unlikely to be able to do much.


Most of these systems actually split the task between software and hardware. Software handles the complexities of the file formats, demuxing, parsing, etc. while the hardware does the heavy lifting of the "inner loops" that move the pixels around and do YUV->RGB


Hidden deep inside the recesses of Google is an HTML conversion of a PDF file that is no longer available. The PDF file is a datasheet for the EM8400 processor. There are bound to be differences, but much of the core is probably very similar.


Yes, I downloaded that a while ago to look for JTAG clues, but as it uses a MIPS core rather than ARM, I didn't think it too relevant.

Ian

I run my MG-35 straight off a NAS that it is directly connected to. One thing I would like to see in a modified firmware is either a "Favourites" on the main menu or a way to automatically set a start up selection.


That's *exactly* what I'm wanting to do.

The easiest way to do this would be to provide an alternate nbtscan that puts your NAS into /hosts/hosts and creates a dir in /net

The safest way to do this is to add a line to sashrc that mounts a share on your nas over the directory containing /bin that has the new nbtscan. This new executable could just run a script to do the work in /hosts and /net, so everyone could use the same one.

Or could the new nbtscan just be a script with a #! at the start? I guess dvdplayer.bin uses an exec() and I don't know if this automatically detects the #!

Time for some playing!

Ian

It works!

Here is what I did (I have a Linux machine called TERA that contains all my smb shares including my own home directory on the machine. Its IP is 192.168.1.65)

On the MG-35
smbmount //192.168.1.65/home /net/home rw
cp /bin/* /net/home/MG-35/bin/
mount -o bind /net/home/MG-35/bin /bin
(Note that this isn't the way to finally do it as the dvdplayer.bin will emty /net/home on returning to the top level screen and thereby removes its own /bin!)

On my Linux box I go into ~/MG-35/home/bin (which is now also the MG-35's bin) and create a text file called nbtscan that contains -
#!/bin/sh
cp /bin/testhosts /hosts/hosts
mkdir /net/TERA

The file testhosts contains -
192.168.1.65 TERA

So, if you create an smb share on your NDAS box called "bin" and change sashrc to mount this over /bin (smbmount) then you will then have your NDAS as the only network connected machine and there won't be a long scan to find it.

If you don't set the bin smb mount as public then the MG-35 won't show it in the list of shares on your NDAS.

Note that I forgot to set +x on the new nbtscan script but it doesn't matter as the MG-35 didn't complain.

Another option is to have a small hard disk (I'm going to try a CF) in your MG-35 and mount smb shares over directories in here (should be able to do this from sashrc)

Ian

Hi all,

Well.. I was trying to load a firmware with EmuMannen's custom graphics and I somehow managed to screw the pooch again.

This time the load went fine. It got to the point where it told me to turn it off and on. When I tried to turn it on, the power LED came on and the blue FIP LED started flashing. That's it. Power on, blue LED flashing.

So.. Knowing that the bootloader was probably intact, I decided to have another look at the serial interface.

This time, I tore open a USB serial cable based on the Prolific PL-2303X interface IC. I had to remove the RS232 level converter IC and rewire, basically, the whole damned thing. Finally got the cable to the point where it did a loopback correctly in my terminal software and started fishing for pins on the MG35.

Success.. Sort of. The pins are:
J9-Pin1: TX
J9-Pin5: RX
J9-Pin7: GND

With the comm port set to 38400-8-N-1, I get the following output:
Jasper Bootloader v1.0.0 (Feb 10 2006 15:34:08)
Supports BootMenu Flash Network
This version of fips use micom with power control, version[3]
Swapping erase regions for broken CFI table.
0031.0032 mfr 00ec id 2275 Top bootsector
Flash 0 at address 0x00000000
ID : AMD/Fujitsu Standard
Size : 4096 KB
Regions : 2
0 : 0x003e0000 - 0x00004000 * 8
1 : 0x00000000 - 0x00020000 * 31
0BF0IDENTIFY FAILED

Inptr=
00000014
Inflating....

Final Inptr=000A27FD
Original LEN =0014BB48OutCnt = 0014BB48
Original CRC =B1201065
Computed CRC =B1201065
01008000

So this looks like the boot console port, but I can't seem to get a menu out of it. If I hold down any key as I power on the device, the sequence stops after "This version of fips..." and the terminal echos all input given to it.

If anyone has any ideas, please let me know.

pb

Well.. I was trying to load a firmware with EmuMannen's custom graphics and I somehow managed to screw the pooch again.


Bum. Any theories on what went wrong?


Success.. Sort of. The pins are:
J9-Pin1: TX
J9-Pin5: RX
J9-Pin7: GND

With the comm port set to 38400-8-N-1, I get the following output:
[code]Jasper Bootloader v1.0.0 (Feb 10 2006 15:34:08)


Great stuff. My serial level switcher *just* arrived from Canada so I can also play with this.


So this looks like the boot console port, but I can't seem to get a menu out of it. If I hold down any key as I power on the device, the sequence stops after "This version of fips..." and the terminal echos all input given to it.


I'd guess that it's waiting for a pass phrase to be entered. Or maybe a hardware handshake line to twiddle.

Try typing in a few strings from the ROM? Maybe "flyduck" as a first go?

Ian

Hi Gadgetmind,

waiting for a pass phrase to be entered.

Freaking brilliant!

The pass phrase is:
MediaGate.

Note the capitalization and the period at the end.

pb

Hi Gadgetmind,



Freaking brilliant!

The pass phrase is:
MediaGate.

Note the capitalization and the period at the end.

pb

You guys are simply amazing!!! - you both just made my day here - does this mean we now have full serial access to re-flash?.If so I presume this really "opens things up"?

... Maybe "flyduck" as a first go?
Good thinking! :p
Freaking brilliant!

The pass phrase is:
MediaGate...
God, I just love this "hide-and-seek-game"! :D

Keep up the good work guys (hate to have my MG-35 taken hostage by the rest of the family)... :(

does this mean we now have full serial access to re-flash?.If so I presume this really "opens things up"?

Yes, it's an important "next stage"

However, the ROM image that the serial utility needs is certainly different format wise to what updater.bin requires.

Hopefully pbarrette can now explore the serial boot menus and find how to ymodem dump the flash (other than the 8k boot area) If he does, then I can dump mine and send him the image for him to recover his unit.

Sadly, I haven't had any time to play with the serial/jtag this weekend due to a sudden influx of inlaws. :-)

Ian

Original LEN =0014BB48OutCnt = 0014BB48


Hmm, that 0x14BB48 rings a bell. It's 1,358,664 in decimal, which is the exact size of the uncompressed kernel.

So, it looks like your kernel at least is intact in the flash.

It's odd that there are no further messages as the kernel starts to boot. I could understand it starting and then complaining that the cramfs is toast but don't know why it should be mute (unless it starts with different serial settings/port/whatever)

Unless it got the wrong entry point for the kernel?

Ian

When I tried to turn it on, the power LED came on and the blue FIP LED started flashing. That's it. Power on, blue LED flashing.




Real strange that it does this,just as if its in USB mode,with a USB device attatched,as opposed to being in player "boot" mode.. what happens if you plug in a USB device?

Original LEN =0014BB48OutCnt = 0014BB48
Original CRC =B1201065
Computed CRC =B1201065
01008000


Hmmm, that 0x01008000 doesn't fit my (probably wrong) theory regards the boot process.

Here is what I thought happened -
Boot at address 0
First 8k of the boot rom does h/w initialisation including programming of SDRAM (lives at address 0x01000000)
A copy is then done from the boot ROM to address 0x01002000 (this copy comes from somewhere before 0x2000 in the ROM) - roughly 56KBytes are copied.
Jump to 0x01002000
First 8k of SDRAM is then mapped over the ROM at address zero.
Kernel is unpacked to address 0x01010000
Jump to 0x01010000

However, there is a lot of guesswork in there.

Ian

For what it's worth, my flash is different and I get different messages.

0031.0033 mfr 0001 id 22c4 Bottom bootsector
Flash 0 at address 0x00000000
ID : AMD/Fujitsu Standard
Size : 4096 KB
Regions : 4
0 : 0x00000000 - 0x00008000 * 1
1 : 0x00008000 - 0x00004000 * 2
2 : 0x00010000 - 0x00010000 * 1
3 : 0x00020000 - 0x00020000 * 31
0BF0IDENTIFY FAILED

The "01008000" is also the last output I see, but my unit goes on to boot OK.

Ian

OK, some more random woffle.

Inlaws have gone, so I've now got my serial rigged up. There is a memory dump command, so I hunted for the start of the cramfs and kernel in the ROM.

The cramfs is at 0xE2809 (as reported by the kernel boot) This suggests that the maximum size of the cramfs is 0x31D7F7, or just over 3MBytes. Loads of room!
The compressed kernel is in the ROM at 0x40004 and is 0xA27FD long
The kernel boot loader is at 0x6000 (execute this with "boot flash")
The kernel is loaded to 0x01008000 to be executed.

There are commands to download code and jump to an address - we could try new kernels by using "download serial 0x01008000" and then "boot 0x01008000" (I'm downloading one as I type this message!)

So, getting the serial loader to reflash kernel and cramfs doesn't look that difficult. There is a download command, which lets you download the boot, romfs, kernel or to an address. This suggests it might handle the erase/flash for romfs and kernel (let's not touch boot!) including downloading to ram before starting.

There are also separate flash commands, but I'd rather not touch those until we have jtag sussed.

pbarrette: Have you tried
"download serial romfs" and sending the cramFS.img via ymodem?

You can also try checking these commands -
boot> dump 0x40004 64
00040004 : 1F 8B 08 08 13 32 4B 43 04 03 6C 69 6E 75 78 2E .....2KC..linux.
00040014 : 62 69 6E 00 EC FD 7F 7C 5D 55 95 FF 8F 9F 73 7F bin....|]U....s.
00040024 : 24 B7 B7 A1 B9 69 52 08 21 C2 69 1B 20 62 80 53 $....iR.!.i. b.S
00040034 : 88 18 6B 80 5B 5A B5 4A 95 0B 2D 50 B4 32 17 28 ..k.[Z.J..-P.2.(
boot> dump 0xe2809 64
000E2809 : 45 3D CD 28 00 E0 28 00 03 00 00 00 00 00 00 00 E=.(..(.........
000E2819 : 43 6F 6D 70 72 65 73 73 65 64 20 52 4F 4D 46 53 Compressed ROMFS
000E2829 : 88 8A A7 33 00 00 00 00 98 06 00 00 0B 01 00 00 ...3............
000E2839 : 43 6F 6D 70 72 65 73 73 65 64 00 00 00 00 00 00 Compressed......

This might suggest what went wrong with your reflash.

Ian




Ian

Woohoo, I just ran a different kernel! OK, so not much different (hex editor on linux.bin) but ...

<4>JASPER ide controller activated
<4> ide0: BM-DMA at 0x500e00-0x500e0f, BIOS settings: hda:pio, hdb:pio
<4>JESTER use arena[0] for cramfs [0x000e2809]

Note the JESTER instead of JASPER.

BTW, the cramFS comes almost immediately after the kernel. The cramFS starts at 0xE2809, so subtract 0xA27FD and we get 0x4000C. The kernel actually starts at 0x40004, so there are eight bytes of padding somewhere.

I'm going to have to read blkmem.c to see how the kernel finds the arena - we need larger kernels!

Ian

The download and boot commands are interesting -

boot> help download
download [media] <target> : download image via various media
[media] : serial / net (network)
<target> : boot / romfs / kernel / [addr]
boot> help boot
boot [target] : boot kernel
flash : boot from flash (0x00006000)
kernel : boot kernel on RAM (0x01008000)
image : boot image on RAM (0x01400000)
[addr] : jump to specified address

A download of "boot" downloads to 0x13E0000
A download of "kernel" downloads to 0x1008000
A download of romfs downloads to 0x0x1400000

Note that the latter downloads to the location that's described as being where "boot image" will jump to. "boot image" with nothing downloaded tries a deflate, which fails.

The flash command is also interesting, obviously!

boot> help flash
flash [command] <options> : flash commands
probe <addr> : probe flash
list : show flash chip information
erase [addr] <len> : erase one or more sectors of flash memory
eraseall : erase all flash memory
writeb [addr] [data] : write one byte of data into specified address
writew [addr] [data] : write one word of data into specified even address
write [to] [from] [len] : write block of data into specified address
boot : write boot loader image on RAM into FLASH
romfs : write ROMFS image on RAM into FLASH

I have a feeling that the romfs being referred to is *not* our cramFS - I suspect that it's a (somehow!) combined kernel and cramFS.

I guess we can try downloading such images into memory with "download serial romfs" and booting with "boot image" - this may be enough to recover a unit as it should decompress the kernel from ram into ram (yes!) and then run with the cramFS in ram. Obviously there will be less system ram for this configuration (8MBytes less?) but it might be enough to let you reflash with a good image.

Testing this will be slow via serial and I can't get the rom loader to handle dhcp on my network. I'll probably try it static but need to reconfigure tftp on my Linux machine first.

BTW, the config command seems to write the config to flash! It invalidates the old config and drop a new one on the end. My 1st config was written to 0x3B1e0 and my 2nd to 0x3b5c8

Ian

Nice one Ian , Keep the info coming as you discover it,I have to admit I dont understand most of it , but sure makes interesting reading.I am sure there are loys of others obtaining a great deal of useful info here...

More findings - I hope they help someone!

Here is a dump just before the compressed kernel - the E2809 is the address at which the cramFS can be found
boot> dump 0x40000 32
00040000 : 09 28 0E 00 1F 8B 08 08 13 32 4B 43 04 03 6C 69 .(.......2KC..li
00040010 : 6E 75 78 2E 62 69 6E 00 EC FD 7F 7C 5D 55 95 FF nux.bin....|]U..

Here is the last byte of the compressed kernel, the 8 bytes of "padding" and then then start of the cramFS
boot> dump 0xE2800 32
000E2800 : 03 65 10 20 B1 48 BB 14 00 45 3D CD 28 00 E0 28 .e. .H...E=.(..(
000E2810 : 00 03 00 00 00 00 00 00 00 43 6F 6D 70 72 65 73 .........Compres

The B1201065 is the checksum of the kernel
The 14BB48 is the length of the kernel

I don't have time to dive back thr0ugh the old messages to look at the format of the update files (I guess some of these fields match?), but I'd hope that this is enough to let us try making a romfs from scratch that we can run from ram. It might be as simple as changing the address of the cramFS just before the kernel (so we get the one from ram), or this might be an offset and not required.

Ian

Nice one Ian , Keep the info coming as you discover it,I have to admit I dont understand most of it , but sure makes interesting reading.I am sure there are loys of others obtaining a great deal of useful info here...

Thanks - no more for today as the red wine and roast beef are really starting to kick in. :)

But I'm pretty hopeful that we can send a new kernel+cramFS down into SDRAM and boot the MG-35 off this rather than the ROM. Great for development and for recovery.

I guess we still need jtag recovery for if we toast the boot loader.

Ian

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

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

My efforts to put anything at 0x1400000 that "boot image" will even deflate successfully have failed.

I 1st tried downloading a Linux.gz with a 4 byte offset to the cramFS stuck on the front, but this failed.

I then realised that I could do it faster and tried using memcpy from 0x40000 to 0x1400000 but this also failed.

Enough for now!

Ian

Of course, it could be that my thinking of the image at 0x1400000 in terms of what's in memory are wrong - could it be as simple as putting an update file (or part of it) at the image location and then using "boot image" to test it and "flash image" to put it into flash?

That would be nice. :)

BTW, is anyone else wanting to play with the serial loader? The guy from who I bought mine is selling another (eBay item - 160013561939) and I can provide a photo showing where the plug the various pins. No soldering required!

Ian

What a Salesman! - I would not really know what I am doing , but I guess its good to have one should at some point in time,just incase I trash my machine with a bad flash.As it looks now as though some sort of recovery will be possible with Serial and maybe later with JTAG.Please could you upload some pics to the Yahoo group and maybe a small "how its done" txt file to here?

Again , many thanks for all your hard work today and in the past - this has indeed been a fun day,seeing events unfold...

Please could you upload some pics to the Yahoo group and maybe a small "how its done" txt file to here?


Yup, will do. t's actually all pretty easy to connect up - five minutes of that. I may do some chopping on my case to get the serial on the back full-time.

BTW, if anyone is playing at using "download serial romfs" and "boot image" you probably don't need to send the whole lot to the MG-35. If you just send a few k and check that they deflate starts with an inptr of 0x14 then this is a quick go/no-go.

Ian

Yup, will do. t's actually all pretty easy to connect up - five minutes of that. I may do some chopping on my case to get the serial on the back full-time.

Ian

Well, you may want to hold off on chopping your own MG , as we are only 20 quid short ($35 US for our American readers) of having enough to buy and ship a Freecom to you..

shame on altering your own unit , when you can "abuse" the development machine :-)

Well, you may want to hold off on chopping your own MG , as we are only 20 quid short ($35 US for our American readers) of having enough to buy and ship a Freecom to you..


Well, if the serial keeps on going really well, there might be better candidates for this unit. Though the JTAG phase could still be scary ...

I saw a Freecom unit with a 40GB drive go for £50 on eBay a few days ago - wish I'd bid but I was sure it was going higher.

Ian

Yeah , have been checking bids and finishing prices for 2+ weeks now , I really think the best we can expect one for is UKP 84.00 + 7.95 shipping for the Freecom of Ebay UK , buying here in the states would be cheaper , but after shipping , really only a few $ difference..

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

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

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

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

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

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

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

Please take a look at the site of the HD Mediabox from PixelMagix,
user forum and ftp site for firmware
The HD Mediabox from PixelMagix (http://www.pixelmagicsystems.com/products/media_players/hd_mediabox.htm) is a great product but it is unfortunately based on Sigma Designs EM8621L and not Sigma Designs EM8511 (as MG-35). What we got is not a generic Linux device with a custom frame buffer (like an Xbox). The ARM processor isn’t the most powerful one (200MHz) and we therefore need some additional hardware support (provided by Sigma Designs chipset). That’s why we can’t just through in something like MPlayer instead of the default software used for media playback.

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

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

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

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

LaCie SliverScreen:
http://www.matbe.com/images/biblio/art_lacie-silverscreen/000000008066.jpg http://www.matbe.com/images/biblio/art_lacie-silverscreen/000000008058.jpg http://www.matbe.com/images/biblio/art_lacie-silverscreen/000000008054.jpg

Modix HD-3510:
http://www.thg.ru/video/20050201/images/modix_mainmenue.jpg http://www.thg.ru/video/20050201/images/modix_video-menue.jpg http://www.thg.ru/video/20050201/images/modix_setup1.jpg

Sigma Designs EM8511 based media players GUI cont.

Vantec AVOX Jukebox:
http://www.bigbruin.com/reviews05/vantecavox/small/mainmenu.jpg http://www.bigbruin.com/reviews05/vantecavox/small/videosetup.jpg http://www.bigbruin.com/reviews05/vantecavox/small/generalsetup.jpg

iZak Portable Media Device:
http://www.mediamania.se/mediaspelare25/izak/produktbilder_iZak_Screens.jpg

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

@EmuMannen

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


http://www.lgnetwork.com/lgnetwork/download/read.jsp?seq=853&prdt_seq=70&ca_no=021

@EmuMannen

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

http://rapidshare.de/files/28460567/AVOX_1.3.7_CHN.zip.html

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

Interesting point here is that this MG-25 clone has a screensaver , so it must be super easy for al Tech to add one to the MG-35?I spotted that too... It would be really nice if the screen-saver was a separate program and not internal to dvdplayer.

Joe L.

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

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

http://www.digitalcowboy.jp/products/mc35ul/image/mc35ultitle.png
http://www.digitalcowboy.jp/products/mc35ul/image/fu02.png
http://www.digitalcowboy.jp/products/mc35ul/image/josd.png

Take a look at the following page, it hosts firmwares for several models, DC-MC35UL2, DC-MC35UL/N and DC-MC35UL etc... (http://www.digitalcowboy.jp/support/index.html)

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


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

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

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


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


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

Ian

A few thoughts -

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

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

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

Ian

Hi All,

My box is working again..

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

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

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

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

Hope that makes sense.

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

@Gadgetmind..

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

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

@EmuMannen,

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

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

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

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

@All,

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

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

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

pb

Sigma em8511 based players:

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

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

Skins, firmware and link to a dedicated forum at:

mediabox_dnsalias_com

(sorry, I can't post urls).

My box is working again..


Woot! Great news!


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


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

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


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


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


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

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

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


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

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


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


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

Anyway, great progress.

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

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

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

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

Ian

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

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

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

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

Ian

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


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

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

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

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

Ian

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

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

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

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

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

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

Ian

My box is working again..Thats great!
Your custom graphics are great. A hell of a lot nicer on the eyes than the boring grey. I do have a few comments though..Shoot...
1) The logon image doesn't really fit with the rest of the Blue/Yellow theme.I know but did you like the logon image?
2) The smiley face selection circle is a bit much. How about just a circle?I was planning for a plain circle but I then played around a bit, will correct ASAP...
3) Images with rounded edges have an odd scan-shift problem.I guess it's because I did'n dither the final images and the combination of high color originals and the limited palette at hand for the final result. A screenshot would be valuable for evaluation and for future corrections (or alternative strategies)...

The last is difficult to describe, so I'll take some pictures when I get home.That would help a lot, I did everything more or less blind, just trying to eye-ball the final result based on different layers I had in Photoshop...


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

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

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

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

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

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

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

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

Ian

@austinv

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

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

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

A few thoughts -

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

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

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

Keep up the good work!

Anybody here know how to set up a wiki?


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

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

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


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


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

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

Ian

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

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


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


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


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

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

Ian

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

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

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

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


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

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

/dvdplayer.bin &

#sleep 3

#/sbin/ifconfig eth0 192.168.0.222 up


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

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

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

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

Not much content yet!

[later]

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

Ian

The donation poll at the Yahoo group is now complate, and I have posted info at the group on how people can donate and what's going to happen to the money.... I can't seem to locate this group. (The one called Mediagate doesn't have any polls.) Can you give a link?

Also, I would recommend that this opportunity to contribute be the first question in the wiki FAQ.

I can't seem to locate this group. (The one called Mediagate doesn't have any polls.) Can you give a link?

Here is the link:
http://groups.yahoo.com/group/mg-35_firmware_mods/

Like numerous other readers:
I have been following this post for quite a while and reading everything here without really understanding the technical side. I am very impressed with all the work that has gone into this box. I purchased the MG-35 after researching quite a few of these media players and found that it gave the best bang for the buck ($115.00 w/ free shipping U.S. w/o ndas or drive at PC4USA). The one thing that lacks is the gui. I have scoured the web for alternative gui sources (mostly for UPnP mediaplayers and so close to buying a ADS Tech MXL-581 or a Hauppage MediaMVP both for cost reasons). In my browsing I came across oxl~box (can't link to it anymore) and SwissCenter both geared towards UPnP and especially the Pinnacle Showcenter 200. SwissCenter interests me most for the gui looks like what would fit for wife and kids use. Is there anyway to utilize the information from swisscenter to create this gui with the mediagate? Or, could J.River's Mediacenters database (cinemar uses J.River for MusicLobby gui) be used in conjunction with the MG-35?

Thanks for all the work

UAN

swisscenter_co_uk
jriver_com
cinemaronline_com

we have our MG-350 Coming this month, and we only have 500pcs for US and Canada Customer of the first order, please come to the following website to pre-order it.


http://www.xpcgear.com/ (http://http://www.xpcgear.com/ )

http://www.ewaggle.com/

http://www.pc4usa.com/ (http://www.xpcgear.com/ )

Well, if the support for the new one is the same as for the MG35 then you better don't use this forum for your advertisement

The guys here are working and brainstorming for a better firmware what should have been done by the manufacturer

You should help them on your 'official' site instead of recommending a new product here

I just tried and failed to get a romfs down via ethernet

I set a static config for the MG-35 ethernet (dhcp doesn't work for me from the serial loader but it works fine when Linux has booted)
I kicked my tftp server to serve from /home/tftp (what a pain!)
I sussed you need to use "net arp a.b.c.d" to get the arp cache filled before you can do anything netish
I have got "download net romfs" to initiate a whole load of tftp transfer activity, but there are numerous timeouts and it eventually dies.

I'm now trying a romfs down serial just for the hell of it. 17 minutes.

I have still got my serial at 38,400 - I'm not sure how much faster my USB to serial will go, and the MG-35 stores the config in flash - I could end up with a serial speed set faster than I can handle.

Ian

And another negative result.

I stuck a romfs (everything after the "ROFS") at 0x1400000 using "download serial romfs" but "boot image" still gave deflate errors.

I'll try again some other time. Another interesting snippet is that an MG-35 without its lid interferes with my wireless network and kept killing my putty session to my Linux box. "Somewhat annoying" until I figured it out.

Still, what's important is that we can now reflash a semi-bricked unit.

pbarrette - can you confirm that "everything after ROFS" is the right thing to download?

Ian

And another negative result.

I stuck a romfs (everything after the "ROFS") at 0x1400000 using "download serial romfs" but "boot image" still gave deflate errors.

I'll try again some other time. Another interesting snippet is that an MG-35 without its lid interferes with my wireless network and kept killing my putty session to my Linux box. "Somewhat annoying" until I figured it out.

Still, what's important is that we can now reflash a semi-bricked unit.

pbarrette - can you confirm that "everything after ROFS" is the right thing to download?

Ian
I think he said he used just the 4 bytes immediately prior to the kernel. Those bytes held the offset of the cramfs.

You might have included too much of the header intended for the normal upgrade parser.

Joe L.

Well, if the support for the new one is the same as for the MG35 then you better don't use this forum for your advertisement

The guys here are working and brainstorming for a better firmware what should have been done by the manufacturer

You should help them on your 'official' site instead of of recommending a new product here
You could say that this user community is doing for free what Mediagate can't do for money... :p

And now a positive(ish) result.

What "boot image" expects is a full rom image at 0x1400000

So -
boot> memcpy 0x1400000 0 0x400000 (4MBytes of rom to 0x1400000)
boot> boot image

Results in a successful inflate of the kernel and the box booting. However, it's currently hard to tell if it's using the new kernel and/or cramFS.

I guess I'd also need -
mem wl 0x1440000 0x014e2809
to tell it to use the new cramFS

More experiments later. I guess I need to copy the kernel and cramFS to RAM and thenmake some changes and check they appear.

Of course, there is the question of whether this is actually worthwhile. Developing using the normal reflash isn't too bad and this isn't exactly slick.

And my wiggler arrived today. :-)

Ian

I think he said he used just the 4 bytes immediately prior to the kernel. Those bytes held the offset of the cramfs.

You might have included too much of the header intended for the normal upgrade parser.

Joe L.

Yes, you might be right. I'll wait for 100% confirmation and then add this information to the wiki page.

I guess I could experiment with reflashing my own box this way, but I'm a wimp. :)

Ian

Yes, you might be right. I'll wait for 100% confirmation and then add this information to the wiki page.

I guess I could experiment with reflashing my own box this way, but I'm a wimp. :)

IanI fully understand... I'm cautious too. I've not even flashed either of my MG-35's yet to any upgrade to 1.4.5. One is 1.4.3, the other 1.4.4. One came with an NDAS key, and the other with a manufacture date one month earlier did not. Both ordered from mwave.com on the same order... (Guess they mixed the stock on their shelves) FYI: units with production date of 2006 02 did NOT come with NDAS key sticker or NDAS CD, my unit with 2006 03 production date did and had an additional sticker on the front of the box stating NDAS.

I'm watching this thread, and you both are way beyond me at working in the ARM environment. Like most I would love for ftp and read-write NTFS support to be included. I do have rusty kernel development skills from back in the Sys-5 Unix days so this all interests me as I have a unRaid server with SMB shares on my lan and would love to make the unit a bit more friendly.

Again, thanks for all the great work. Be careful of ESD issues as you probe in the unit. A stray static charge can brick a unit way faster than a bad upgrade. Use a wrist-strap or something to keep electro-static-discharge from being an issue as you probe around looking for the JTAG points. Keep your cell phone away from the unit during an upgrade. It would definitely cause problems if it corrupted an in-progress upload.

Joe L.

Argh!!

There's too many posts, so I keep forgetting what I need to talk about..

First. EmuMannen.. Images of the new GUI interface:

The HD/NET selection screen:
http://peterbarrette.com/MG35/NewGui-1sm.jpg (http://peterbarrette.com/MG35/NewGui-1.jpg)

The media selection screen:
http://peterbarrette.com/MG35/NewGui-2sm.jpg (http://peterbarrette.com/MG35/NewGui-2.jpg)

An issue with font color vs background on the setup screen:
http://peterbarrette.com/MG35/NewGui-3sm.jpg (http://peterbarrette.com/MG35/NewGui-3.jpg)

The odd scan-shift problem.. Note that the movie reel has the problem, but the speaker doesn't:
http://peterbarrette.com/MG35/NewGui-Split.jpg

I'm guessing that it's a problem with the way the scanlines are handled. I remember reading something (KiSS related maybe) about image formatting for TV display and dealing with scanlines during upscaling. I'm sure that's the issue, but don't remember what the fix is.

As for the varying firmware images and their contents.. All of the firmware images for Mediagate clones seem to be built from the same dev kit. Whomever is compiling the firmware is apparently pretty lazy. So there's a lot of stuff in all the firmware images I've seen that doesn't need to be there or is duplicated. Also, the "ifconfig" line is commented out in the stock MG-35 firmware images as well. I believe that the init process grabs the network settings out of the flash memory and configs the interface.

So you end up with crap like USB and network drivers in the firmware images when the devices don't have the hardware. Or png images which aren't used by the GUI. Or multiple copies of busybox with different functions compiled in, but named as the function.

Basically, lazy developers at ALTech making things confusing.

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

@ Gadgetmind,

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

The command "flash romfs" erases the flash region from "0x40000" to "0x3FFFFF" then it writes the contents of "0x1400000" into that flash region. So I didn't try to use memcpy to do that.

Originally it wasn't working at all, but then you said that the bootloader was trying to get the kernel at "0x40004" and a light went on. I remembered that the ".upgrade" image expected the ROFS section to consist of 4bytes+Linux.gz+Cramfs.img and calculates it's checksum using this combined data. The "4bytes" are the offset for Cramfs.img.

The MG-35 firmware format follows these guidelines:

[UPGIXM02] (ASCII)
[VERS] (Dword) - Firmware version (digit per byte)
[BOOT] (ASCII)
[CKSMb] (Dword) - Checksum of bootloader
[OFFSb] (Dword) - Offset to bootloader in flash
[BOOTLEN] (Dword) - Length of bootloader
[BOOTLDR] (Data) - * Start of the bootloader data
...
[ROFS] (ASCII)
[CKSMr] (Dword) - Checksum of ROFS
[OFFSr] (Dword) - Offset to ROFS in flash
[ROFSLEN] (Dword) - Length of ROFS ([OFFSc]+[LINUX]+[CRAMFS])
[OFFSc] (Dword) - * Offset to Cramfs.img in flash
[LINXGZ] (Data) - Start of the linux.gz data
...
[CRAMFS] (Data) - Start of the Cramfs.img data
...

(* = Section checksum calculation starts here)


So that puts the [LINXGZ] start at 0x40004 and gives me the 4 byte padding that I was missing.

...the compressed size of the kernel either includes the size and crc dwords on the end...
The specification for gzip means that you will always get the uncompressed filesize and a CRC32 as the last bytes of the file. So those 8 bytes should always be there if the file was compressed with a copy of gzip that conforms to the standard.

The Linux.gz and Cramfs.img are concatenated with no data in between.

Serial port stuff...

The bootloader saves the config settings, but I can't get it to save a new default serial baudrate. So no worries there. I usually connect at 38400 then issue "config serial 115200" and disconnect, change the baud on my comm port and reconnect. Since the serial interface is a 3-wire deal, the MG35 doesn't notice the dis/re-connect at all.

Also note that there's an unlisted "config save" command, but that doesn't seem to change the default baudrate either.

Don't worry about flashing the ROMFS via serial. First, it won't let you flash unless you have first successfully downloaded something to "romfs". Second, if your ROMFS image consists of [OFFSc]+[LINXGZ]+[CRAMFS], then it should be fine. If not, you can always download and flash a default ROMFS by chopping one of the default firmwares. That's exactly what I did to get my box working again. Since it was still hooked up to the serial port, I also used this method to write the custom gui firmware image.

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

Finally...

There are some issues that I need to work out before I upload the new GUI firmware image:
1) I changed the telnet shell to "lash" which looks nice, but doesn't like to execute some of the binaries. Sash had no problems, so I need to revert.
2) Someone mentioned that my custom firmware images break ISO viewing. I tested the firmware and that's true. I need to figure out why ISO's are broken and fix that.

pb

An issue with font color vs background on the setup screen:

I was afraid of running into problems with text colors not matching the backdrop (when altering the palette). Hard to analyze from that small picture. What is the problem (can you describe it)?

Ps. Oups. Dident realize that I could click on the pictures to get a better one... How can we figure out what palette index is used for text in the GUI? Any ideas?


The odd scan-shift problem.. Note that the movie reel has the problem, but the speaker doesn't:

That is because MG-35 is using 720x480 for its GUI. It perfectly fit NTSC 480 lines but not PAL 576 lines. The artefacts is because of interpolation to fill in the "missing" scan lines when "upconverting" to PAL. I guess only PAL users will see this phenomena (as usual). Little to do about (the only thing I can think of would be to develop a specific PAL theme using 720x576 and squeeze the final graphics down to 720x480 just to reduce the effect, maybe not worth the effort)...

.......... only thing I can think of would be to develop a specific PAL theme using 720x576 and squeeze the final graphics down to 720x480 just to reduce the effect, maybe not worth the effort)...


Whoa Whoa there big fella ...... Not worth the effort !!!!
What about us in the colonies :)

In all seriousness the current GUI doesnt bother me as much as the lack of decent MP3 ID3 support does.

Once again keep up the good work you brilliant developers ..... (you know who you are). In my eyes you are putting the manufacture to shame. Well done.


Mike

(the only thing I can think of would be to develop a specific PAL theme using 720x576 and squeeze the final graphics down to 720x480 just to reduce the effect, maybe not worth the effort)...

Well, as it's you putting in the effort, and me (another PAL user) getting the benefits, I think it's very worthwhile. :)

Ian

I just did some mild wiki editing (thanks all who have joined in - it's starting to look good!) and have uploaded a recovery romfs.m35 I thought it worth blowing 30% of our wiki file area on this as everything else will be pictures and these are small as long as you reduce the resolution.

There is currently no link that I can see on the wiki to the adunder.org site and nothing telling people where to find updated firmware.

Have we made a decision on where the "official" location will be for new firmware images? I think it needs to be somewhere that won't change/move, where we don't have serious space problems, and where people don't have to jump through too many hoops to do the download.

Ian

Obviously you guys have so many sites setup you will not be needing adunder.org so i will close it down, and we will all use the 3 site that have been setup + this forum :)

How does this sound for the specification of a .update file splitter.joiner?

--------------------------------------------------------------------------------
mg35tool <split | join > [-v version] [-b boot_file] [-k kernel_file] [-c cramfs_file] <update_file>
A tool for splitting and combining .update files for the MG-35 media player. This tool automatically removes all header information when splitting files and automatically recalculates it again when joining files.

-b Specifies name of boot loader file. Default when splitting is Boot.rom. When joining, the BOOT section of the update file is only included if this option is specified.

-k Specify a compressed kernel file. Default is Linux.gz

-c Specify a compressed filing system file. Default is CramFS.img

-v Specify the version of the .update file in the format major.minor.patch This information will be built into the update file's header when joining. This option has no effect when splitting.

Exmples -
mg35tool split MG35_1.4.3.upgrade
This will split the upgrade file and produce three files, Boot.rom, Linux.gz and CramFS.img

mg35tool join -k kernel.gz -c test.img MG35-test.update
This will take kernel.gz and test.img and produce an update file with a ROFS section but no BOOT section. All sizes and checksums will be calculated automatically as will the offset to the CramFS that is required to directly precede the kernel.
--------------------------------------------------------------------------------

I'd hope that with just a little care the program would run just fine whether built for Windows or Linux.

Anyone feel they can knock this together in a couple of hours or do I have to dust off Kernigan and Ritchie this weekend? :)

Ian

Obviously you guys have so many sites setup you will not be needing adunder.org so i will close it down, and we will all use the 3 site that have been setup + this forum :)

Here seems to be great for chatting.
The "official" site is great for bugging the distributors. :-)
The wiki is great for collating information.
Yahoo for files?
Rapidshare for files?
Adunder for files?

Dunno.

Ian