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

I agree with the above Ian , always good to have as many mirrors for files as possible , I will still provide my rapidshare file area for those that have Rapidshare accounts or do not mind the "hoops"...

Also added a link to the Wiki at the Yahoo Group..

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

Someone mentioned it earlier (I think) but what about using a torrent ??

Mike

Someone mentioned it earlier (I think) but what about using a torrent ??


I think that was me, but the firmware is pretty small. I chatted to my ISP and he said my personal web site doesn't have a bandwidth limit but to "Play nice". A few hundred downloads of some 3MByte files won't bother him at all.

But only I can upload to this site, which isn't ideal.

But here is the new firmware - http://www.foxhill.co.uk/MG-35_1.4.5_Official_English_Beta_Firmware.rar - it should be very quick and easy for you to download this and I own the domain so it won't change/die.

Ian

Yes good point about the size, not really worth it for a torrent.

I'll have a look at my own domain and see if there would be any bandwidth issues for me and if not I will host (mirror) the files as well.

Perhaps if multiple people can host the files (working from the same list of files ie not a true mirror) we could have download points for various regions in the world.

Thoughts ?

Mike

Perhaps if multiple people can host the files (working from the same list of files ie not a true mirror) we could have download points for various regions in the world.


Again, they are tiddly files, so it's not a big issue. I guess we ought to worry more about creating the content rather than where to put it. :)

To that end, I have done a few minutes work on the MG-35 development page on the wiki.

http://mediagate.pbwiki.com/MG35Development

It needs more work, but so little time ...

Ian

Hi EmuMannen,

Take a look at the KiSS developer pages here (http://dev.kiss-technology.com/tv-graphics/). They suggest using a convolution matrix to avoid flicker, but it would probably work to reduce interpolation artifacts as well.

Those pics were taken with my MG35 set to 1080i using the component outputs. The interpolation problems are less noticable with 720p, but text is fuzzy. The problem mostly dissapears at 480p, but who wants to run that? :)

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.

Has anyone tried such an image on the MG-35 via the GUI? Or is this kind of "high risk" activity the kind of thing that needs to wait for the development unit?

Ian

Hi all,

I'm going to be out of the loop for a little while starting tomorrow (business trip).

I have uploaded a new version of MgPalSwap to the yahoo files area. Functionality is the same, but the "-h" help message was broken in the last one.

If anyone wants to try out EmuMannen's new graphics, you will need to inject his custom palette into dvdplayer.bin and put the new executable (along with the modified images) into a new cramfs image.

MgPalSwap requires a Photoshop ACT format palette, a copy of dvdplayer.bin and the hexadecimal offset to the system palette. For the dvdplayer.bin found in the Mediagate v1.4.4 firmware image, this offset is: 0xF8A60

Editing dvdplayer.bin would be done like this:
mgpalswap -p palette.act -o 0xF8A60

This will create a new file called "output.bin". This should be renamed to dvdplayer.bin and placed in the new cramfs image.

The system palette is stored in dvdplayer.bin as a series of dwords with RGB color values much like a Photoshop ACT palette. The difference is that each color in an ACT palette uses 3 bytes (ie: FF-FF-FF) while the Mediagate system palette uses 4 (FF-FF-FF-00). The default system palette has the 4th byte set to zero for all colors. This may be an alpha value that Mediagate is not using. That's something that EmuMannen could possibly explore.

If anyone has time, it would be great if someone could figure out why my custom firmware breaks ISO support since I won't have time to figure this out for at least a week.

pb

Hi Ian,

That's high risk.

The problem is that there exists the possibility that the MG35's upgrader software will erase the bootloader expecting it to be a part of the new firmware image.

If upgrader was programmed correctly, then it should see that there is no BOOT section and not erase the bootloader, but we don't know for sure if that's the case.

pb

Hi Ian,

That's high risk.

The problem is that there exists the possibility that the MG35's upgrader software will erase the bootloader expecting it to be a part of the new firmware image.

If upgrader was programmed correctly, then it should see that there is no BOOT section and not erase the bootloader, but we don't know for sure if that's the case.

pbpbarrette,

From what you have discovered in old ".upgrade" files the bootloader section (at that time) was optional. We do not know if it is always expected with the current upgrader program. (it could have changed since that early release)

Do we know where the "upgrader" is located yet? From what I've read it seems it might be part of dvdplayer.bin, but dvdplayer could call a separate program to do the actual upgrade when a ".upgrade" file is selected in the file-system.

With what we now know, it might not be a bad time to attempt a disassembly of the "upgrader." It cannot be too complicated, basic parsing of the sections, calc of checksums, load into memory, and perhaps, invoking the same routines we found in the bootloader to write it to flash memory. Of course, if it is part of dvdplayer.bin it might be a huge task to find the section of code dealing with the upgrade process. I'm hoping it is a separate .bin.

So... if we had the "upgrade" binary and an ARM disassembler, it would be a great sub-task for a person with assembler skills and tools. At least we would then know the risks and what it would do if it got handed a .upgrade" image without a bootloader section.

Joe L.

The system palette is stored in dvdplayer.bin as a series of dwords with RGB color values much like a Photoshop ACT palette. The difference is that each color in an ACT palette uses 3 bytes (ie: FF-FF-FF) while the Mediagate system palette uses 4 (FF-FF-FF-00). The default system palette has the 4th byte set to zero for all colors. This may be an alpha value that Mediagate is not using. That's something that EmuMannen could possibly explore.
Aaaarrrrgggg... They probably got an alpha channel but they don't use it, thats lame! Photoshop ACT palette lack alpha information (why should they include it when paletted images lack alpha channel in Photoshop). Maybe we should make a program that could produce native MG-35 (4 byte) palette information based on different sources. ACT-files would produce palettes with 0x00 alpha-bytes but the alpha information from sources supporting alpha (e.g. PNG files) could be tranfered and maintained into this native MG-35 palette format.

It should be easy to test if MG-35 is actually making use of that byte as an alpha channel. Just pad the "alpha" byte in the systems palette with something like 0x7F making graphics semi-transparent if alpha is supported...

If upgrader was programmed correctly, then it should see that there is no BOOT section and not erase the bootloader, but we don't know for sure if that's the case.


Yes, "programmed correctly" is rather a worry with Al Tech. :)

I guess I need to get around to taking some MG-25 firmware to bits and checking whether the uploader.bin is the same as the MG-35 one. Or just wait until JTAG reflash is (hopefully) going.

Ian

Do we know where the "upgrader" is located yet?
- snip -
With what we now know, it might not be a bad time to attempt a disassembly of the "upgrader."
- snip -
So... if we had the "upgrade" binary and an ARM disassembler, it would be a great sub-task for a person with assembler skills and tools.


It's in /bin/upgrader

The standard arm-elf objdump can disassemble but there is 77k of upgrader to work through.

I was working with a hex editor last night (look at the config format in the NV part of the flash) and had hex on the left and ascii on the right. My wife walked up and said, "Hey, I didn't know you could read Ancient!" :)

Ian

It's in /bin/upgrader

The standard arm-elf objdump can disassemble but there is 77k of upgrader to work through.

I was working with a hex editor last night (look at the config format in the NV part of the flash) and had hex on the left and ascii on the right. My wife walked up and said, "Hey, I didn't know you could read Ancient!" :)

IanIf you are anything like me, the programming language is not important. It is simply a matter of where you put the semi-colons. ;) There just might be one named "Ancient" (and assembly comes fairly close) 77k is more than I would have guessed. Clearly, not a hand-assembled program, but probably compiled "C" For what it is doing I can't envision it needing more than 1 to 2k of native assembly, and likely far less.

Rather than wade through 77k of assembly, a shortcut might be to see if the "upgrader.bin" in that old .upgrade file (where the BOOT section was missing) is any different than the current upgrader.bin.

If they are the same, odds are higher that the current upgrader will not erase the boot section of the flash if presented with a .upgrade image that has no BOOT section. I guess we still would not know if it was the same as the one in the prior release....the one used to process the .upgrade file with the missing BOOT section... arghhhh....

Joe L.

If you are anything like me, the programming language is not important. It is simply a matter of where you put the semi-colons. ;)


Yes, I'm happy tackling anything, but as a self-confessed, old-school, hairy-hacker, assembler is where I tend to be happiest. I've written several 100k+ line programs entirely in assembler!

But I've written Java (for home automation!) and a fair bit of Python, and a tiny bit of C.


77k is more than I would have guessed. Clearly, not a hand-assembled program, but probably compiled "C"


While the updater is running, Linux cannot access the cramFS as the flash is being erased/programmed. I'm not at all sure how they achieve this. But if this indeed what is happening, updater will have to contain all the graphics used during the programming and a few other bits and bobs.


If they are the same, odds are higher that the current upgrader will not erase the boot section of the flash if presented with a .upgrade image that has no BOOT section.


I think that pb is right and it's high risk. We've cracked most of the problem by sussing serial flash, and making sure that the loader never gets erased, and being able to reflash it if it does, it just the icing on the cake.

Ian

Yes, I'm happy tackling anything, but as a self-confessed, old-school, hairy-hacker, assembler is where I tend to be happiest. I've written several 100k+ line programs entirely in assembler!

But I've written Java (for home automation!) and a fair bit of Python, and a tiny bit of C.Like you, give me a good old 1GL, and I can deal with it. Most of my assembler was on the Z80. Largest hand written assembler program was a full blown editor, complete with formatting.

Nowadays I code mostly in 3GL and 4GL languages. As I said... mostly a matter of learning new syntax... the fundamentals are all the same. I'll bet I've done over 100K lines of "C" and far more than that in various other languages over the years.
While the updater is running, Linux cannot access the cramFS as the flash is being erased/programmed. I'm not at all sure how they achieve this. But if this indeed what is happening, updater will have to contain all the graphics used during the programming and a few other bits and bobs.

I think that pb is right and it's high risk. We've cracked most of the problem by sussing serial flash, and making sure that the loader never gets erased, and being able to reflash it if it does, it just the icing on the cake.

IanI too think pbarrette is right, it is not worth the risk at this time.

Did you ever load a new ROMFS image yesterday through the serial port and get it to flash? From what pb posted, it looked like it was looking for only 4 bytes prior to the kernel.

Have you tried to boot the newly loaded in-memory image rather than storing it to flash first. That would make changes far less risky as you would only flash after proving everything worked as expected.

Joe L.

Hi again,

My explanation above was brief because I wanted to immediately warn of the danger and didn't have a whole lot of time.

The reality is that "/bin/upgrader" probably is capable of correctly flashing an ".upgrade" image that lacks the [BOOT] section. This can't, however, be guaranteed. So it would be best to wait until the development box is purchased and have the reciever (Ian) test a BOOT-less image on it. Since he may well kill it just looking for a JTAG port anyway, there's less risk with the development box.

However, if you really want to risk permanently bricking your own, personal MG-35.. Then by all means, let us know how it went.

The Sigma/ALTech development kit appears to have a one-shot compile system. Basically, every time they change anything in the firmware, their dev kit recompiles the kernel, all the binaries, the bootloader and creates the cramfs filesystem in one shot. This means that virtually every binary is slightly different from each firmware revision to the next. That makes it a lot more difficult to determine what changes are merely cosmetic and which are functional.

The next problem is that the firmware image that is missing the BOOT section is for the MG-25 and NOT the MG-35. While the devices are extremely similar and have a very similar ".upgrade" image format, they are not the same. One assumes that ALTech (Sigma?) just recycled code and that they should be very similar, but the reality is that we just don't know.

The MG-35 works this way:
"/dvdplayer.bin" is the GUI. It displays the interface on the screen and calls external software to perform other functions. It is also responsible for insmodding the fip and khwl modules. When you play an mp3, dvdplayer.bin calls on "/bin/mp3play" to actually play the file. Likewise, it calls on "/mpegplayer.bin" to play MPG1/2 files, etc.

When you want to perform a firmware upgrade, dvdplayer calls on "/bin/upgrader" to do it. The GUI gets the status from the output of "upgrader" so the user knows what's happening. In the meantime, all the graphics being displayed on the screen are retained in the display buffer, so "upgrader" doesn't have to worry about that part. In fact, if you change "logontsc.jpg" in your new ".upgrade" file, you can see how this is true.

When the device has finished flashing a new image, it tells you to turn it off. When you hit the power button, it briefly displays the logon image before powering down. If the new firmware image contains a different logon image, this is the one you see flash on the screen just before the device turns off.

Like JL realized, even if we knew that the MG25-117 "/bin/upgrader" was the same as the MG35-144's, we wouldn't know if the previous version of "/bin/upgrader" was the same, so we still wouldn't have an answer. The reality is that a binary file comparison shows the MG25 "upgrader" to be significantly different from the MG35's. Likewise, the "/bin/upgrader"'s found in MG35-13x firmwares differ significantly from MG35-14x versions. Again, figuring out which differences are cosmetic and which change functionality would not be a simple task.

So right now, I suggest leaving it alone until we get the dev box going. Then a simple test on an expendable box will tell us if it works or not.

In the meantime, if you want to be absolutely sure that your next firmware flash doesn't kill the bootloader, then use the serial port interface to do download and flash the ROFS section only.

pb

Largest hand written assembler program was a full blown editor, complete with formatting.


I did a number of 3D games in Z80 for machines such as the Sinclair Spectrum. One was a faithfull ripof^H^H^H^H^H tribute to the Star Wars arcade game.

Anyway, enough of this, or I'll be going all "Four Yorkshiremen" :)


Did you ever load a new ROMFS image yesterday through the serial port and get it to flash? From what pb posted, it looked like it was looking for only 4 bytes prior to the kernel.


That wasn't what I was trying to do. Our home TV viewing depends on our MG-35 and no way am I going to risk bricking it without high confidence. As it happens, when I was doing would have flashed, but "boot image" needs a full flash image at the start of ram and not just the dword + kernel + cramFS.


Have you tried to boot the newly loaded in-memory image rather than storing it to flash first. That would make changes far less risky as you would only flash after proving everything worked as expected.


That was what I was trying. Running just the kernel from ram is easy (and I have now documented on the wiki) but while I got a full flash image to boot from RAM, it's pretty obvious to me now that this image is different to an image that you'd put into flash. It needs some changes to find the cramFS in ram and to start the page cache after this.

We have a few choices for development now -
1) Just flash via the GUI. If it dies, recover via serial (takes 5 mins or so)
2) Test new kernels via download to memory. Avoids a full reflash if the kernel is duff but uses the in-flash cramFS.
3) For testing with the in-flash kernel, mount bits of the HD (or SMB shares) to get a totally/partially different VFS.

(1) is obvious and working, (2) I have mostly documented on the wiki, and (3) needs more work and more documentation.

I think we're now in pretty good shape regards enabling development. I'm planning to tackle JTAG, rebuilding a replacement kernel, and (if no other bugger volunteers!) the m35tool for handling split/join of .update files.

Replacement graphics seem in hand.

I guess we now need to press-gang a few other people to tackle a few other areas. But managing programmers is like herding cats, and it's 10x worse when they are volunteers. :)

Ian

When the device has finished flashing a new image, it tells you to turn it off. When you hit the power button, it briefly displays the logon image before powering down. If the new firmware image contains a different logon image, this is the one you see flash on the screen just before the device turns off.


I'm starting to feel a bit queasy. If you're going to reflash the cramFS while the FS is still running, you have to do a whole lot right. It doesn't sound like they are doing any of it. It's no wonder that reflashes can fail. And the more stuff like telnet and ftp that we have that can be triggered by network traffic, then the worse it will probably be.

<thinks hard>

Ah hah! uClinux is maybe more forgiving in this regard as code isn't faulted into ram on an ongoing basis. It's hard easier with uClinux to make sure that accesses to the FS aren't done at unexpected times.

Ian

So it would be best to wait until the development box is purchased and have the reciever (Ian) test a BOOT-less image on it.


Never since Christmas 1968 will I have broken a present so quickly after receiving it. :)


Since he may well kill it just looking for a JTAG port anyway, there's less risk with the development box.


Hey, I regularly work on boards with 14,000 UK pounds worth of silicon on them, and I haven't yet killed enough to get fired! :)

Ian

Hey, I regularly work on boards with 14,000 UK pounds worth of silicon on them, and I haven't yet killed enough to get fired! :)

IanWell... some of the suggestions I've read in this thread (example: probing with a speaker to find the serial port) did not indicate a lot of experience with ESD issues or with the voltages and logic levels likely to be found as you search out the jtag pins. I still remember those ESD training films in Western-Electric classes. The boards were *very* expensive back then...(over $10,000 in 1973 dollars) and I did not get fired either :D

I did not know your background and I certainly don't want you to disturb your family's TV watching by zapping a board, that might get you killed.... by your family members :eek:

Carry on...

Joe L.

Never since Christmas 1968 will I have broken a present so quickly after receiving it. :)

Ian

Ian, Pleasse tell us all what you broke in 1968? , I dearly hope it was NOT your "Johnny Seven one Man Army Gun"? or your Original Battery operated Delek by Louis Marx?

I could go on for hours chatting about the rubbery feel when laying your fingers on the keyboard of a ZX Spectrum, my first ASM book by some guy called Peter Norton, my precious CBM-SX64 in mint condition, and my custom built cocktail cabinet running MAME etc. but you would probably just tell me to get a life, wouldn’t you? :p

Snap back to reality, we still got some issues regarding the GUI. I guess we got most of what we need figured out but there is still a big potential for further exploration. The main issue right now is the “font color issue”. We do know how to alter the palette in dvdplayer.bin so that custom image files show up with the right colors. We also know that changes in the palette affect text colors and even some graphics (e.g. like the frames drawn behind the values in the configuration menu) but we don’t know enough to gain control over this issue yet.

My guess is that these elements of the GUI (text, frames etc.) uses fixed indexes in the palette when assigning colors. Any smart developer would have assigned a fixed number of colors at the beginning or the end of the palette for this purpose but that doesent seem to be the case with the MG-35 (why am I not surprised, just as lame as finding orphaned CVS directories in the production firmware).

The original palette has white (#FFFFFF) as index 1 and black (#000000) as index 256. It also has magenta (#FF00FF), often used to indicate a transparency mask, as index 255. This could have made sense since dvdplayer.bin mainly use black and white as text color (making these colors predictable if attached at the beginning and end of the palette).

The settings menu is a bit of a deviation. It doesn’t act as integrated as the other menus so I started to suspect that it actually was another executable called from dvdplayer.bin (the only way to get to this menu is by pushing the “settings” button and that is also the only way to get back, not like hitting “left” to back out of the rest of the menus in dvdplayer.bin).

I then found \bin\setup so I started to suspect that dvdplayer.bin is calling \bin\setup when you hit the “setup” button. That would create further questions if I am right on this one. The overlaid PNG images in the settings menu use the same palette as defined in dvdplayer.bin but might be another process. The problem is that it is not using just black and white to render text and other objects drawn in runtime!

My major problem right now is trying to figure out what indexes in the palette that are used for drawing in runtime (because they have to be accounted for when making up a custom palette and custom graphics). The simplest way to do this would be a dump of the memory area holding the screen image from the different menus. Using a palette with 256 unique values would then make it easy to map graphical elements on screen with the corresponding palette index.

The problem is if we can’t dump the color information on screen pixel by pixel. We then have to use our eyes and try to judge by the picture on the TV screen. Separating #FFFFFF from #FEFEFE with this method would be impossible so it would be almost impossible to make a palette with 256 unique values that could be uniquely separated from each other using this method. We would probably have to break it down into blocks of 16 unique colors + the rest in shades of gray and shift the offset of the colors. We would end up with 16 different palettes and 16 different versions of dvdplayer.bin to be able to pin down what color index goes where. I could prepare the palettes and patch a bunch of dvdplayer.bin but whom in willing to try them out and bring back the result?

There is a chance that the last 24 colors in the palette are reserved somehow. That’s where you find the yellow, green and blue used for highlight and some overlaid elements. This is also where you find magenta used for transparency. The last color before this block is black (#000000) so the block before it got both white and black and black is later on duplicated at index 256. That could indicate that index 1 is used for white and index 232 is used for black (instead of 256) but that would make it illogical to put transparency as index 255 and not use 256 for that. This guesswork doesn’t really make sense to me, I just hope it might be of use to anybody else... :(

Does anyone of you hardware guys know how MG-35 is handling video memory (how much is it, is it rendered to one buffer for SD (NTSC/PAL) and another for up-scaled (720p/1080i) or is it up-scaled on-the-fly etc.)? Is the memory easy accessable?

The problem is if we can’t dump the color information on screen pixel by pixel. We then have to use our eyes and try to judge by the picture on the TV screen. Separating #FFFFFF from #FEFEFE with this method would be impossible so it would be almost impossible to make a palette with 256 unique values that could be uniquely separated from each other using this method. Perhaps you don't need to use your eyes.

If you created the palette of 256 colors and then fed the output of the MG-35 into a video capture card we would then be able to extract a single frame of video and then examine it using any number of tools. Just a thought... As long as the capture card could handle more than 256 colors, and most should, you might not have to rely on your eyes alone.

Joe L.

Perhaps you don't need to use your eyes.

If you created the palette of 256 colors and then fed the output of the MG-35 into a video capture card we would then be able to extract a single frame of video and then examine it using any number of tools. Just a thought... As long as the capture card could handle more than 256 colors, and most should, you might not have to rely on your eyes alone.

Joe L.
That thought already crossed my mind but I don't know if the TV-out signal is reliable enough. Just look how NTSC is handling colors! The slightest tint would ruin the result. That’s why I would like to get straight to the video memory, if possible…

Ian, Pleasse tell us all what you broke in 1968? , I dearly hope it was NOT your "Johnny Seven one Man Army Gun"? or your Original Battery operated Delek by Louis Marx?

No, it was a "safe for indoor use" plastic helicopter. You pulled a plastic strip and it took off. The box picture suggested it then roamed the room looking for bad guys.

In my case, within 30 seconds of opening it, it took off vertically and caused minor cosmetic damage to a lamp shade (my mother said "ruined") and destroying itself in the process. A part of the lamp shade fell onto the sideboard and took a chip out of it.

I tried to console my mother by showing her that by placing a suitably sized finger a carefully calibrated distance into your ear, you could extract varying colours of ear wax that could be used to perform instant and invisible repairs to such chips, but she was beyond reason.

Ian

Does anyone of you hardware guys know how MG-35 is handling video memory (how much is it, is it rendered to one buffer for SD (NTSC/PAL) and another for up-scaled (720p/1080i) or is it up-scaled on-the-fly etc.)? Is the memory easy accessable?

It's a big fat "don't know" from me on all of that other than there is a separate 8MByte SDRAM for the video.

The video memory is on "the other side" of the video hardware, but I'd guess that it's also in memory when doing the static GUI stuff. Traditionally, there would be a /dev/framebuffer or similar, but I suspect we need to do some hunting.

We do have access to /dev/mem, but the results of reading and writing this are at odds with what you get with the dump command in the serial console. I trust the serial console far more.

The ROM is at 0x0000-0000 and goes to 0x003F-FFFF (4Mbytes)
The RAM is at 0x0100-0000 and goes to 0x01FF-FFFF (16MBytes)

When I read between the rom and the ram my box crashed, so this is a hardware region. A bit of poking elsewhere may locate a framebuffer and I'd guess it's between the rom and the ram.

Ian

This guesswork doesn’t really make sense to me, I just hope it might be of use to anybody else... :(

In the spirit of throwing in random observations, the KiSS guys developed a utility call SigmaEdit that pulls font and pallette information out of /bin/init - dunno why it's in there!

http://84.41.208.229/download/apps/sigmaedit%200.1.3f/sigmaedit-0.1.3f.zip

I ran it on our /bin/init and it claimed to have found a font, but the values it gave for dimensions were totally bogus.

I can't find source for this tool, but others may have more luck. It was written by a Russian guy.

Ian

A few observations on the storage of configuration information.

Non-Volatile storage is in the flash.

At 0x20000 is the ascii "BOOT"
The config blocks then start at 0x20048
They are 1000 decimal bytes each.
When you change the config, a new block is written on the end.

Usually when this method is used, the previous block is then invalidated, but I think the MG-35 is actually using a bitfield after "BOOT" where a bit is programmed to a zero to make a block as invalid (so the code looks for the first set bit and can then calculate where the data is)

When I captured my memory a couple of weeks ago, my config data went to roughly 0x38000. It's now at 0x3B1E0. I'm guessing that if the config gets close to the kernel, the area from 0x20000 to 0x2FFFF is erased and the process starts again.

There are strings in the config data that indicate that the path to the romfs.m35 file can be changed, which will make tftp configuration easier. I'd hope the serial loader allows this to be done, but we can now easily flash it ourselves.

There are also the strings "linux.bin" and "loader.bin" - I'm guessing that these are further traces of the DVD parentage of the device.

Ian

I've just ordered our development box from eBay. It was £92.90 in total, which the fund money came within a few pence of covering.

I've also shelled out about £30 for wigglers and serial leads, and paid $20 into the fund, and am today getting together the parts to attach to the unit to let me easily (and safely!) probe the JTAG, but I don't think my wife has noticed, yet. :)

Ian

...
I ran it on our /bin/init and it claimed to have found a font, but the values it gave for dimensions were totally bogus.
...
I have already posted this link (http://sigma-players.nd.e-wro.pl/firmware.htm) but I would like to highlight it again. It contains a lot of information regarding fonts embedded in dvdplayer.bin and other firmware related issues like building a new romfs.bin etc.

I will also take a look at SigmaEdit but I have no idea how relevant KiSS firmwares might be to a MG-35 device...

Ps. pbarrette, could you please share the format of the ACT-file and the MG-35 systems palette (or the source to your palette injection program)?

The video memory is on "the other side" of the video hardware, but I'd guess that it's also in memory when doing the static GUI stuff.

Hmmm. Looking through hardware.h in include/asm/arch-jasper in the KiSS firmware, I find confirmation that the hardware regs are where I thought they were (actually at 0x500000) and also a lot of mention of DMA. So, the framebuffer might be in system memory and be dma'd to the video chip.

I guess I can boot the box, use dd to dump all of the ram, move a cursor on the screen, dump the ram again, and then diff the two dumps. I should be able to spot the changes.

If anyone has time on their hands, you'll need a busybox with dd built-in, mount the dir it's in as rw (smb or from hd)
and do -
./busybox dd if=/dev/mem of=mem1.bin bs=1m skip=0x1000000 count=16
or something like that.

Ian

I am going trough KiSS (custom) development forums right now. Lots of interesting stuff. I am looking for information regarding kernel development and kernel config right now. I have added links in the wiki to a binary arm-elf-toolchain that is used by the KiSS user developers and that works according to them 100%. I also added a link to a binary arm-elf-toolchain version for the Linux 2.6 Kernel.

I don't know if you already got this link (http://www.jacek.it.pl/kiss/gpl/). It links to KiSS kernel sources with Sigma and KiSS patches + several kernel configs + busybox sources.

Has anyone tried running the MG-35 with a KiSS uClinux kernel? Maybe it's possible to build the KiSS kernel without KiSS pathes (just Sigma patches) and get it running on the MG-35? The KiSS guys semms to have several custom made kernels running on the KiSS units (with ext2 support etc.).

I'm no kernel hacker but maybe this can be of help for someone that is familiar with Linux kernel development...

I have added links in the wiki to a binary arm-elf-toolchain that is used by the KiSS user developers and that works according to them 100%. I also added a link to a binary arm-elf-toolchain version for the Linux 2.6 Kernel.

I don't know if you already got this link (http://www.jacek.it.pl/kiss/gpl/). It links to KiSS kernel sources with Sigma and KiSS patches + several kernel configs + busybox sources.


I think I already had most of that there, but the more the merrier.


Has anyone tried running the MG-35 with a KiSS uClinux kernel? Maybe it's possible to build the KiSS kernel without KiSS pathes (just Sigma patches) and get it running on the MG-35? The KiSS guys semms to have several custom made kernels running on the KiSS units (with ext2 support etc.).


I'm going to have a bash at this, particularly now that we can run kernels without reflashing. But the config will need quite a tweak from what KiSS uses - the flash and SDRAM layout seem different. Still, it's worth a go. 1st job might be to try and get a KiSS kernel to at least start to boot and give some serial output.

This task would be massively easier if Al Tech would do their duty. :(

Ian

By the way, what views do people have regards telling Al Tech and/or Freecom that we're now happily reflashing with custom firmware and are able to recover (mostly) from bad flashing?

Might it help prompt a GPL release or might it hinder it?

Ian

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.

The KiSS kernel is set to default to 115200. Did you try booting a kernel after switching to this speed? I'll try tonight and see if I get kernel boot output.

Ian

By the way, what views do people have regards telling Al Tech and/or Freecom that we're now happily reflashing with custom firmware and are able to recover (mostly) from bad flashing?

Might it help prompt a GPL release or might it hinder it?

Ian

Well, I presume that Al Tech are not totally stupid and I presume that anywhereus have told them whats going on,even if not, a two second Google search is all that is needed.I would just carry on for a while until we have a nice stable firmware with a new Gui and maybe some other features added.I really dont think they are interested in the MG-35 any longer,but might be interested in how all this stuff might affect sales of the MG-350HD,as they must have sunk a great deal of $ into its development - I really hope they learn a lesson from all this.I mean, I am sure all it would take its just a weeks programming / testing by Al Tech to sort many of the MG-35's outstanding issues.
It may be that they dont have a In House programmer, and would have to pay a third party developer todo it...

I guess I can boot the box, use dd to dump all of the ram, move a cursor on the screen, dump the ram again, and then diff the two dumps. I should be able to spot the changes.
I don't know but I guess that the MG-35 has to render it's GUI in a backbuffer (probably using 720x480 based on the backdrop graphics). The backbuffer is then probably sent somewhere for upscaling or whatever needed to get the image to the display device. The last step might be out of reach in Sigma silicon or whatever but the backbuffer might be within reach (maybe in that separate 8MByte SDRAM for the video)? 720x480@8bpp is less than 3MB, 720x480@16bpp is about 5.5MB and 720x480@32bpp is just over 11MB...

The last step might be out of reach in Sigma silicon

Yes, that's normally the case. The hardware will usually fetch just as many lines of video as it needs to do a multi-tap upscale as the on chip line buffers needed for this are rather expensive in term of silicon area. This is done on-the-fly as the video is output via the TVE.

Any other approach would be very memory bandwidth intensive and memory hungry.

Ian

I have just posted a message over at the Yahoo group detailing where the monies donated so far have gone.
I understand Ian is now in the process of buying the development box to trash like he did in 1968 :-)

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

Don't get too excited.

I just booted a KiSS kernel after making heavy mods to the .config.

It is finding the cramFS, though I had to bodge this.
It does seem to be finding most (all?) hardware.
It is giving me boot printk messages and starting a serial console.
It is running /etc/sashrc

But this dies with -
/> Using khwl.o
unresolved symbol gpio_enable_irq

So, the MG-35 kernel has a kernel symbol that the khwl.o module needs and which isn't in the KiSS kernel source. A google search for this symbol gets zero hits (well, until Google update from this thread!), which isn't good.

I suspect this bit of code is rather short and we could get the address from /proc/ksyms and disassemble it from the existing kernel. Or it might be in the Sigma Designs GPL release of their kernel - I can't check now as my wife wants something called a conversation and it seems that grunts and me shouting "Busy!" don't count. :)

If anyone else wants to play with this, the links to the ARM tools and the KiSS kernel source are on the development page on the wiki. .config available on request.

Ian

Or it might be in the Sigma Designs GPL release of their kernel

Nope, not there. :(

But all this function will be doing is twiddling a hardware bit or two to set an SoC GPIO pin so that it generates an interrupt. Not hard.

But what else are we missing? I'm going to resend all my emails to Al Tech and Freecom!!!!

Ian

So, the MG-35 kernel has a kernel symbol that the khwl.o module needs and which isn't in the KiSS kernel source.
Thats bad... I loaded khwl.o in my hexeditor and the is full of EM85xx related stuff and references to some "CQuasarBoard". Did a search on google using some of the strings and ended up at the following site (http://www.worlddivx.it/). Dont ask me how but I did find out that one of the firmare iso-files on this page (http://www.worlddivx.it/lettori/firmware.php) also contained a khwl.o file. The firmware belong to the Yamakawa DVD-365DivX and the iso-file can be downloaded from here (http://www.worlddivx.it/lettori/firmwareup.php?up=12). I dont know if it can be of use but we now know that there are other Sigma based devices out there using khwl.o (so probably part of a Sigma dev kit and not developed inhouse)...

Ps. The following string was also found in khwl.o:
../../gcc-2.95.3/gcc/libgcc2.c /opt/em85xx/src/arm-elf-gcc/gcc GNU C 2.95.3 20010315 (release)(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from http://www.snapgear.com/)

Further references to Sigma, Quasar Board, khwl.o and KiSS on this wiki page... (http://who.is.free.fr/wiki/index.php?SigmaDesign)

It may be that they dont have a In House programmer, and would have to pay a third party developer to do it... You know, given the trivial nature of some of these fixes which have never been done in months of waiting, I think you're right on. I booted up the Digital Cowboy firmware 1.4.5 last night, and it's bug-for-bug compatible with Mediagate 1.4.5 firmware. I think this argues for a common code base developed by neither company.

A couple of random observations on my firmware flashing last night. Contrary to an earlier report, I think the graphic are noticeably prettier than Mediagate's. The Japanese is a bigger annoyance for us so I flashed it back again. If you flash the Digital Cowboy firmware on your Mediagate, all the menus are still legible (in English). The only trouble you will have is flashing it back again, because the reflash commentary/progress popup is all Japanese. Don't panic! Just go on faith and wait for the progress bar to finish before cycling power. :)

Another much stupider thing I tried last night was to attempt a flash of the AVOX firmware. This is an MG-25 clone, and not an MG-35 clone. (I got confused by the file names... Mental note: don't download arbitrary firmware updates and then come back to them days later when you may or may not remember what they are!) Anyhow, if you attempt to reflash your MG-35 with an update file for the AVOX, you will crash your box when it attempts to validate the file's checksums. At this point, nothing is lost other than your time to unplug your Mediagate and plug it back in again.

But this dies with -
/> Using khwl.o
unresolved symbol gpio_enable_irq

So, the MG-35 kernel has a kernel symbol that the khwl.o module needs and which isn't in the KiSS kernel source. A google search for this symbol gets zero hits (well, until Google update from this thread!), which isn't good.

Sanity check, I know we already gone trough this page (http://user.it.uu.se/~alse7905/EM85xxDVD/) but take another look at it.

Primarily, we need information about khwl.o. Any information regarding the module or the EM85xx chip is greatly appreciated.
khwl.o is inkluded in the original kiss firmware binaries (http://user.it.uu.se/cgi-bin/cgiwrap/alse7905/download?kiss-dp500-2.8.3.tar.gz).

The page also contains a link to the source for kiss_khwl.o (http://user.it.uu.se/cgi-bin/cgiwrap/alse7905/download?kiss_khwl.tar.gz) etc.

So the symbol has to be there somewhere...

So the symbol has to be there somewhere...

Sadly not. I've read the (reverse engineered) source of khwl.o and the MG-35 version is clearly different - gpio_enable_irq isn't in any of the available source that I have found, neither called from the driver nor supplied by the kernel.

But let's not fixate on this issue - we can probably work around it. But we'll hit many other such issues if Al Tech don't meet the licence conditions and supply the source.

Ian

This is a long shot but "gpio enable irq" leads to a lot of information regarding ARM and Blackfin Processor options. Did you enable GPIO IRQ Demultiplexing in the kernel config?
Blackfin Processor Options --->
Enable GPIO IRQ Demultiplexing
--- Asynchronous Memory Configuration
EBIU_AMBCTL Control --->
(0x3592) Bank 3

if you want to know more about intercepting kernel calls and the like just google "Loadable Kernel Module Interceptor"

khwl.o does lots of ioctl calls so we may be able to reverse engineer those. i'm talking with some russian guys about it so hopefully some time soon ....

Phew!!! I just finished reading through all 44 pages in this thread. I just discoverd the MG-35 today and I'm excited about the potential I see here! Great work Guys!!

Before finding the MG35, I was just going to try to find a modded Xbox. Can anyone tell me in what ways the MG35 would be better?

Thanks!!

Kristi

For the most part xbox would be better. It has a stronger main processor so all media is done in software not hardware. This makes adding codec support much easier for the xbox. The xbox should almost every file, definately everything the mg-35 can play.

The one major benifit that the mg-35 has for me is it is silent. No fan, possibly no hard drive. Also power consumption, not really a big advantage but it is there, als maybe cost of unit. Cost really depends on what is in the modded xbox. If getting a xbox for just a media center I would definately suggest a softmodded xbox as they are cheaper then a chipped box.

This is a long shot but "gpio enable irq" leads to a lot of information regarding ARM and Blackfin Processor options. Did you enable GPIO IRQ Demultiplexing in the kernel config?
Blackfin Processor Options --->
Enable GPIO IRQ Demultiplexing
--- Asynchronous Memory Configuration
EBIU_AMBCTL Control --->
(0x3592) Bank 3

Unless I was being more stupid that usualy, gpio_enable_irq is simply not in the source tree that I have. The only thing that will put it there is changing/editing a source file to include that function.

Ian

if you want to know more about intercepting kernel calls and the like just google "Loadable Kernel Module Interceptor"

khwl.o does lots of ioctl calls so we may be able to reverse engineer those. i'm talking with some russian guys about it so hopefully some time soon ....

Did you see this link http://user.it.uu.se/cgi-bin/cgiwrap/alse7905/download?kiss_khwl.tar.gz to some reverse engineered khwl.o source code? It doesn't call gpio_enable_irq.

Intercepting calls to our khwl.o sounds promising, but the whole task of getting this kernel working is feeling quite daunting right now. :(

Ian

I was just going to try to find a modded Xbox. Can anyone tell me in what ways the MG35 would be better?


Smaller, cheaper, quieter, can be turned on with your remote. But codec support isn't as good and there are nothing like as many fancy features as on the xbox. Yet!

Ian

BTW, I've updated the development page on the wiki with progress on running the KiSS kernel and also with links to the khwl source, etc.

I've included a terminal log of the kernel booting and me (mis)typing my way around to see what's there and what isn't.

proc didn't get populated - dunno why. Also the box picked up the wrong IP address - again it's a mystery. But given the gating factor of khwl not working, I didn't go much further.

However, I did build ext2 support into this kernel if someone wanted to play with it. And there also seem to be options regards enabling extra IDE features that suggest speed ups. I haven't tried these as my MG-35 doesn't have a HD fitted. I'll find an old one for the development box.

Note that I directly entered the cramFS address into the .config - the MG-35 kernel seems to manage this via an indirection at 0x40000 suggesting more source code hackery.

Ian

I wonder if we might do better by contacting Al Tech in Korean and maybe also Freecom in German?

I did some checking on Freecom gmbh and the names of their CEO and CFO are on their site. Sadly, they are not a public company. Just imagine what effect a letter to the CFO of a PLC would have if said letter was from a shareholder and suggested that you had concerns about them selling products that infringed 3rd party copyrights and perhaps their accounts should make a provision for future action regards said products. :)

I wonder if Freecom sell via any distributors that are PLCs?

Ian

Information on this Freecom product is available here -

http://www.openfsg.com

They have the arm toolchain and a full source release in the downloads section and have clearly done the work to separate GPL and proprietary.

This bodes well. I'm continuing to push them regards a GPL release for the MG-35.

Meanwhile, I'm downloading the FSG source to see if it's of any use. It's big!

Ian

my MG-35 doesn't have a HD fitted. I'll find an old one for the development box.First... thanks for all your work and efforts.
Second, an FYI:
When I first got my MG-35 I installed an old 40 gig drive I had laying around. I formatted it as NTFS and loaded it with a number of .avi files and a two ISO images of DVDs I own.

The old disk drive was NOT one that ran silently and it ran so hot I could hardly hold it by hand. Even worse, every 10 - 20 seconds I could hear the heads seek back and forth across the platters. A second or two later, the video display of whatever I was watching would stutter. (apparently, a few second's of video is buffered so the effect of the head-seek/recalibration is delayed)

My first impressions of the MG-35 were not too high. Since the unit was to be used as night in my bedroom, the noise from the drive was an important factor. The old 40 gig drive would not do.

I ordered a 250 gig Hitachi "Deskstar" drive advertised as low power and silent. Once installed I went through the process of partitioning and formatting it. It was barely warm and the only noise I could hear was when it initially spins up. I learned the drive goes to sleep when not used for a while. Even better for standby energy use.

When playing videos and ISO image I saw none of the stuttering I had with the old 40 gig drive as it re-positioned the heads.

So... I guess what I'm saying is that an old drive may not work very well in the MG-35 once you get past the development stage. A newer drive makes a huge difference.

Joe L.

So... I guess what I'm saying is that an old drive may not work very well in the MG-35 once you get past the development stage. A newer drive makes a huge difference.


Yup, I'm only going to use the drive for development. For normal use, I pull all the content off the 2TByte raid server in my databunker. Yes, really!

Modern hard drives have really improved. For even less heat/noise a 2.5" drive is a good but expensive alternative.

Ian

I haven't been exhaustive, but at least the following is missing from the kernel I built.

01018618 gpio_enable_irq
010186b4 gpio_disable_irq
010186fc gpio_irq_enabled
01018738 gpio_irq_pending
01018770 gpio_clear_irq
010187a8 gpio_set_dir
010187ec gpio_set_data

fipmodule.o uses all but gpio_irq_enabled.

Everything else in arch-jasper seems to be there. This suggests that we're just short of a single arch file for handling EM85xx gpio. But there are only 300-400 bytes of code involved, so we have a fall-back solution!

Ian

I have uploaded a new palette file (Spectrum.act) to Yahoo Groups (also attached to this post). It is a full spectrum palette (from purple to red). It will make the GUI look terrible but it should make it easy to estimate in what part of the palette MG-35 is assigning colors for text and runtime drawn objects.

Please, if anyone got time, inject this palette in dvdplayer.bin. Then run it and look for the colors of text in all menus (the text drawn at runtime not the one on graphics like PNG and JPEG images). I am especially interested in the setup menu because it also has rounded squares drawn in runtime behind the values (values are text).

Please report back any findings (menu, text or graphics element, color).

ian,

if no-one has put their hand up for the firmware extractor/creator i'll do it .... i figure your time is much better spent on other things.

and yeah, the kernel thing is a big leap but we'll get there eventually !!!

torquil

ian/pb,

you may want to have a look at the page ... it has some hints about things. it's in chinese thou ...

lunar.blog.edu.cn / user1 / 3313 / archives / 2005 / 63957.shtml

guys,

here's some info from russia. also, it appears from other info that the OSD ram is the last 512k of RAM ....

Yes, originally they used microwindows (we don't) and wrote a 'driver' which called low-level funcs of khwl.o. We had to reverse-engineer the interface of khwl - and created our libs.

The graphics has some parts:
- 8-bit OSD (plus 24+8-bit palette with alpha) - used for GUI;
- YUV-buffer for direct access - used for JPEG output;
- video decoder interface - to display MPEG streams;
- SPU interface - to process subtitles and DVD highlights;

There's no fbdev (but you can write one), and all dvdplayer/fileplayer binaries call the driver's functions directly (via ioctl). The ioctl numbers and memory addresses may vary for different firmwares/players and khwl's.
The basic concept for OSD is just to get the memory pointers for 8-bit buffer (640x480 bytes) and header-buffer (8+256*4 bytes) with palette. The concept for YUV-buffer is much alike the DMA-transfers of memory blocks for UV and Y planes (YUV 4:2:2 or 4:2:0, 720x480).

you may want to have a look at the page ... it has some hints about things. it's in chinese thou ...
Great job, below is an auto-translation of the page (http://lunar.blog.edu.cn/user1/3313/archives/2005/63957.shtml)


EM85XX knowledge base
[ 2005-2-1 9:28:00 | By: Just ]

Step of step of translation software
1. "-2.4 enters uClinux through cd uClinux" -2.4 tables of contents <br>
1. $ cd /EM85xx/thirdparties directory<br>
1. $ cd /EM85xx/kernelmode<br>
1. $ cd /EM85xx/fileplayer<br>
1. $ cd /EM85xx/dvdplayer<br>
1. $ cd /EM85xx/loaders<br>
1. Establishes QuickLoader<br>
BackLinks
<? Plugin BackLinks exclude||='' include_self||=1 noheader||=0 page||='' info||=''? >
CalendarPlugin
<? Plugin Calendar month_offset=+1? >
<? Plugin Calendar start_wday=1? >
! Patch for 1.2
GaryBenson wrote the first calendar implementation for PhpWiki 1.2.
(Since 1.2 doesn't support plugins, it uses a =###CALENDAR###= token
[ patch|http://inauspicious.org/files/phpwiki/phpwiki-1.2.0-calendar.patch ]
(on 1.2.0), and
CategoryCategory
<? Plugin TitleSearch s=Category noheader=1 exclude=CategoryCategory? >
On the Envision development board disposes USB
1 ~ inputs ~make menuconfig, increase config-envision-usb. <br>
[ http://www.hdtv.com.hk/em85xx/wiki/gb/upload/usb1.jpg ]
6 under uClinux-2.4.17/driver/usb table of contents usbcore.o, hc_sl811.o, usb-storage.o<br>
Bin/busybox insmod hc_sl811.o<br>
FAQ
[ Q: With busybox ifconfig eth0 up 192.168.1.106 netmask 255.255.255.0 establishments networks, prompt cannot find ifconfig? ] <br>
[ Q:ENVISION 8,510 IDE network supports DMA read-write? ] <br>
[ Q: Changes to how in 8,510 platforms memory from 8MB 16MB? ] Br>
[ Q: In PVP 8,510 software, has what difference about hard disk actuation ata.o and the Linux IDE actuation? ] <br>
[ Q: In PVP 8,510 software, how lets software when the start, outputs in the television? ] <br>
[ Q: In PVP 8,510 software, how increases a pressed key? ] <br>
[ Q: In ENVISION 8,510 whether supports "mixes the sound"? ] Is ~Microphone~ inputs and superimposes Microphone the detention input, then (or other forms audio frequency) mixes with another group MPEG audio frequency. <br>
FullRecentChanges
<? Plugin RecentChanges days||=3 show_all=1 daylist=1,3,7,30,90, -1? >
FullTextSearch
<? Plugin IncludePage page=FindPage quiet=1 section=Tips sectionhead=1? >
FuzzyPages
<? Plugin IncludePage page=FindPage quiet=1 section=Tips sectionhead=1? >
GoodStyle
10th-grade English students, unknowingly extols some virtues of
HelloWorldPlugin
"\$Revision: 1.1 $");
InterWiki
ISBN:020171499X.
InterWikiMap
Dict http://www.dict.org/bin/Dict? Database=*&Form=Dict1&Strategy=*&Query=
Dictionary http://www.dict.org/bin/Dict? Database=*&Form=Dict1&Strategy=*&Query=
FreeBSDman http://www.FreeBSD.org/cgi/man.cgi? Apropos=1&query=
YpsiEyeball http://sknkwrks.dyndns.org:1957/writewiki/wiki.pl?
Internet Radio
1 copy netraddio.tar.gz to Em85xx directory <br>
1. Go to "netradio" directory<br>
1. Edit "fileplayer.cpp" <br>
2. You must remark from line 96 to 123<br>
10. Edit "isonav.cpp" <br>
11. Add below source code after line 1078<br>
While (1) {<br>
If (getEvent (&scan_code, 1,000) >0) {<br>
Atapi_TrayOperation (atapi_handle, 1); <br>
Sleep (1); <br>
12. Add below source code after line 1039<br>
Sleep (1); <br>
Player_confd=-1; <br>
13. Add below source code after line 363<br>
Player_confd=-1; <br>
14. Edit "startosd.c" and add below source code after line 152
15. Edit "libhandleer.c" and add below source code after line 373<br>
GrText (wPtr->wid, wPtr->gc,230,330, ipHMSStr, -1, GR_TFASCII); <br>
GrDrawImageToFit (wPtr->wid, wPtr->gc,265, 350, 105, 37, imglistenoffId); <br>
Case 1:<br>
~GrDrawImageToFit (wPtr->wid, wPtr->gc,135, radioItem [ curSel ] y,404,30, radioItem [ curSel ] imgradioOffId); <br>
If (curSel == SERVER1) curSel = RADIORETURN; <br>
~GrText (wPtr->wid, wPtr->gc,230,330, ipHMSStr, -1, GR_TFASCII); <br>
GrDrawImageToFit (wPtr->wid, wPtr->gc,265, 350, 105, 37, imglistenonId); <br>
Case 1:<br>
~GrDrawImageToFit (wPtr->wid, wPtr->gc,135, radioItem [ curSel ] y,404,30, radioItem [ curSel ] imgradioOnId); <br>
~GrText (wPtr->wid, wPtr->gc,230,330, ipHMSStr, -1, GR_TFASCII); <br>
~GrDrawImageToFit (wPtr->wid, wPtr->gc,265, 350, 105, 37, imglistenoffId); <br>
Case 1:<br>
~GrDrawImageToFit (wPtr->wid, wPtr->gc,135, radioItem [ curSel ] y,404,30, radioItem [ curSel ] imgradioOffId); <br>
If (curSel == RADIORETURN) curSel = SERVER1; <br>
GrText (wPtr->wid, wPtr->gc, curX, curY, ipHMSStr, -1, GR_TFASCII); <br>
GrText (wPtr->wid, gc_pal244, curX + retwidth, curY, &iptxtStr [ curIdMax ],1, GR_TFASCII); <br>
~GrDrawImageToFit (wPtr->wid, wPtr->gc,265, 350, 105, 37, imglistenonId); <br>
Case 1:<br>
~GrDrawImageToFit (wPtr->wid, wPtr->gc,135, radioItem [ curSel ] y,404,30, radioItem [ curSel ] imgradioOnId); <br>
Case SERVER1:<br>
Ipstr= "http://64.236.34.141:80/stream/1018"; <br>
Ipstr= "http://205.188.209.193:80/stream/1040"; <br>
Ipstr= "http://152.163.134.164:80/stream/1006"; <br>
Ipstr= "http://205.188.209.193:80/stream/1003"; <br>
Ipstr= "http://152.163.134.164:80/stream/1024";
Ipstr= "http://205.188.209.193:80/stream/1017"; <br>
Proxy_status=1; <br>
~GrText (wPtr->wid, wPtr->gc, curX, curY, ipHMSStr, -1, GR_TFASCII); <br>
~GrText (wPtr->wid, gc_pal244, curX + retwidth, curY, &iptxtStr [ curIdMax ],1, GR_TFASCII); <br>
Char *envp~ [ 1 ] = {NULL}; <br>
Argv~ [ 1 ] =ipstr; <br>
If (proxy_status == 1) <br>
_exit (1); <br>
Gc1 = wPtr->gc; <br>
~//OsdDrawPictureEx (wPtr, 20, 15, 38, 31, "img/lib/proxyend1.png"); <br>
~GrText (wPtr->wid, wPtr->gc,40,120, "Server 1:", -1, GR_TFASCII); <br>
~GrText (wPtr->wid, wPtr->gc,40,150, "Server 2:", -1, GR_TFASCII); <br>
~GrText (wPtr->wid, wPtr->gc,40,180, "Server 3:", -1, GR_TFASCII); <br>
~GrText (wPtr->wid, wPtr->gc,40,210, "Server 4:", -1, GR_TFASCII); <br>
~GrText (wPtr->wid, wPtr->gc,40,240, "Server 5:", -1, GR_TFASCII); <br>
~GrText (wPtr->wid, wPtr->gc,40,270, "Server 6:", -1, GR_TFASCII); <br>
~GrText (wPtr->wid, wPtr->gc,140,300, "Proxy status:", -1, GR_TFASCII); <br>
~~GrText (wPtr->wid, wPtr->gc,140,330, "Proxy IP:", -1, GR_TFASCII); <br>
~GrText (wPtr->wid, wPtr->gc,150,420, "To set, press Up Down, then enter", -1, GR_TFASCII); <br>
IpHMSStr~ [ 0 ] = ipHMSStr~ [ 1 ] = ipHMSStr~ [ 2 ] = '0'; <br>
IpHMSStr~ [ 8 ] = ipHMSStr~ [ 9 ] = ipHMSStr~ [ 10 ] = '0'; <br>
IpHMSStr~ [ 12 ] = ipHMSStr~ [ 13 ] = ipHMSStr~ [ 14 ] = '0'; <br>
IpHMSStr~ [ 16 ] = ipHMSStr~ [ 17 ] = ipHMSStr~ [ 18 ] = ipHMSStr~ [ 18 ] = '0'; <br>
CurIdMax = 19; CurY = 330; <br>
~GrText (wPtr->wid, wPtr->gc,230,330, iptxtStr, -1, GR_TFASCII); <br>
~GrFillRect (wPtr->wid, wPtr->gc_pal0, DIR_MSG_XPOS-10, DIR_MSG_YPOS-20, DIR_WIDTH, DIR_YOFF); <br>
ImgproxyoffId = ~GrLoadImageFromFile ("img/lib/proxyend1.png", 0); <br>
~GrDrawImageToFit (wPtr->wid, wPtr->gc,265, 350, 105, 37, imglistenoffId); <br>
~GrDrawImageToFit (wPtr->wid, wPtr->gc,135, radioItem~ [ i ] y,404,30, radioItem~ [ i ] imgradioOffId); <br>
~GrDrawImageToFit (wPtr->wid, wPtr->gc,135, radioItem~ [ 0 ] y,404,30, radioItem~ [ 0 ] imgradioOnId); <br>
~GrDrawImageToFit (wPtr->wid, wPtr->gc,135, radioItem~ [ 0 ] y,404,30, radioItem~ [ 0 ] imgradioOnId); <br>
For (i=1; I < 6; I++) {<br>
~GrDrawImageToFit (wPtr->wid, wPtr->gc,135, radioItem~ [ i ] y,,404,30, radioItem~ [ i ] imgradioOffId); <<br>
GrGetGCTextSize (gc1, str, curId, GR_TFASCII, &retwidth, &retheight, &retbase);
~GrText (wid, gc_pal64, x, curY, &str~ [ curId ],1, GR_TFASCII);
~GrText (wid, gc1, x, curY, &str~ [ curId ],1, GR_TFASCII);
GrGetGCTextSize (gc1, str, curId, GR_TFASCII, &retwidth, &retheight, &retbase); <br>
~GrText (wid, gc_pal244, curX+retwidth, curY, &str~ [ curId ],1, GR_TFASCII); <br>
~GrText (wid, gc_pal244, x, curY, &str~ [ curId ],1, GR_TFASCII); <br>
~GrText (wPtr->wid, wPtr->gc, curX + retwidth, curY, &iptxtStr~ [ curId ],1, GR_TFASCII); <br>
If (curId == 3 || curId == 7 || curId == 11 || curId == 15) curId--;
~GrText (wPtr->wid, gc_pal244, curX + retwidth, curY, &iptxtStr~ [ curId ],1, GR_TFASCII); <br>
~GrText (wPtr->wid, wPtr->gc, curX + retwidth, curY, &iptxtStr~ [ curId ],1, GR_TFASCII); <br>
If (curId == 3 || curId == 7 || curId == 11 || curId == 15) curId++;
~GrText (wPtr->wid, gc_pal244, curX + retwidth, curY, &iptxtStr~ [ curId ],1, GR_TFASCII); <br>
~GrText (wPtr->wid, gc_pal64, curX, curY, iptxtStr, -1, GR_TFASCII);
CurIdMax = 19; CurY = 330;
IpHMSStr~ [ 0 ] = ipHMSStr~ [ 1 ] = ipHMSStr~ [ 2 ] = '0';
IpHMSStr~ [ 8 ] = ipHMSStr~ [ 9 ] = ipHMSStr~ [ 10 ] = '0';
IpHMSStr~ [ 12 ] = ipHMSStr~ [ 13 ] = ipHMSStr~ [ 14 ] = '0';
IpHMSStr~ [ 16 ] = ipHMSStr~ [ 17 ] = ipHMSStr~ [ 18 ] = ipHMSStr~ [ 19 ] = '0';
//printf ("is 1\n");
Digit = 0x31;
If (curId == 0 || curId == 1 || curId == 4 || curId == 5 || curId == 8 || curId == 9 || curId == 12 || curId == 13 || curId == 16 || curId == 17 || curId == 18)
~ProxyIpDrawDigit (iptxtStr, digit,1);
Else if (curId == 2 || curId == 6 || curId == 10 || curId == 14)
16. Add source cod after line 11<br>
{"img/lib/server1on.png", "img/lib/server1off.png", "img/lib/server1text.png",0.,0,1 million},
{"img/lib/server2on.png", "img/lib/server2off.png", "img/lib/server2text.png",0.,0,13 million},
{"img/lib/server3on.png", "img/lib/server3off.png", "img/lib/server3ext.png",0.,0,16 million},
{"img/lib/server4on.png", "img/lib/server4off.png", "img/lib/server4text.png",0.,0,19 million},
Static int curId = 19, curIdMax = 19, curRow = 0, curCol = 0;
Static GR_GC_ID gc1, gc_pal0, gc_pal6, gc_pal244;
#define SERVER1 0
#define SERVER2 1
16. Edit "dirhandler.c" and add source code in the end<br>
17.Run "make" to compile dvdplayer<br>
18.Run Dvdplayer.bin<br>
19.Press "Canccle" to run irplayer.bin<br>
MagicPhpWikiURLs
<? Plugin-form TitleSearch formsize=12? >
<? Plugin-form TitleSearch formsize=12? >
NewMarkupTestPage
* l1
Term1:
Definition1.1
Definition1.2
* ul1
# ul1-ol1
# ul1-ol2
* ul1-ol2-ul1
* ul1-ol2-ul2
* ul1-ol2-ul2-ul1
* ul1-ol2-ul2-ul2
* l1
* level 1
* l1
*l1
*l1
*l1
! ! ! H1
! ! ! H1
OGG
1.cp vorbis.cpp fileplay/<br>
1. Edits in fileplay Makefile<br>
(ext~ [ 0 ] == 'M' && ext~ [ 1 ] == 'P' && ext~ [ 2 ] == '3') ||<br>
Add: (ext~ [ 0 ] == 'O' && ext~ [ 1 ] == 'G' && ext~ [ 2 ] == 'G') ||<br>
(ext~ [ 0 ] == 'O' && ext~ [ 1 ] == 'G' && ext~ [ 2 ] == 'M') ||<br>
(ext~ [ 0 ] == 'M' && ext~ [ 1 ] == 'P' && ext~ [ 2 ] == '3') || <br>
Add: (ext~ [ 0 ] == 'O' && ext~ [ 1 ] == 'G' && ext~ [ 2 ] == 'G') || <br>
(ext~ [ 0 ] == 'O' && ext~ [ 1 ] == 'G' && ext~ [ 2 ] == 'M') || <br>
OldMarkupTestPage
* l1
; Term1:definition1.1
; : Defintion1.2
*ul1
*#ul1-ol1
*#ul1-ol2
*#*ul1-ol2-ul1
*#*ul1-ol2-ul2
*#**ul1-ol2-ul2-ul1
*#**ul1-ol2-ul2-ul1
*l1
* level 1
* l1
*l1
*l1
*l1
! ! ! H1
! ! ! H1
OldTextFormattingRules
__Footnotes:__ Use [ [ 1 ], [ [ 2 ], [ [ 3 ]... %%%
* You can create footnotes by using [ [ 1 ], [ [ 2 ], [ [ 3 ]... like this here [ 1 ]. See footnote for counterpart. (If the [ [ is in the first column, it is a footnote ''definition'' rather than a footnote ''reference'' [ 1 ].)
[ 1 ] By using [ [ 1 ] a second time (in the first column) the footnote itself is ''defined''. You may refer to a footnote as many times as you want, but you may only define it once on the page. Note the the [ [ 1 ] in the footnote links back to the first reference, if there are multiple references there will be +'s after the [ [ 1 ] which will link to the other references. (References which come ''after'' the footnote ''definition'' will not be linked to.)
PageGroupTestOne
Loop=1
PgsrcTranslation
Using two words before they will work in PhpWiki 1.3.5pre:
PhotoAlbumPlugin
Height=100%
Width=100%
Photo-01.jpg; My girlfriend and I
PhpHighlightPlugin
In =<? Php= and =? >=, then set =wrap= to =0=. The default value is =1=
PhpWikiDocumentation
Reclimit=1
Firstreversed=1
Include_self||=1
The Q:EM85xx.envision.tar.gz development package translates software moves when the Envision board, how establishes IP and netmask?
Bin/busybox ifconfig eth0 up 192.168.1.106 netmask 255.255.255.0<br>
How many does Q:EM85xx support biggest system ram and flash is?
Sdram most greatly supports the 16M byte
Q:ENVISION 8,510 IDE network supports DMA read-write?
If IDE, network and CF card are all used, Uart1 is not available and IDE only work in PIO mode. Is it right? <br>
The Q:OSD greatest size is how many
Writes a procedure, demonstrates video, uses HDTV 1920*1080i the resolution, then superimposes OSD in above, <br> in the /kernelmodule/realmagichwl_kernelland/realmagichwl.h document <br>
91. #define REALMAGICHWL_VGAWIDTH 640<br>
Q: 2 2MB Flash changes 4MB Flash when the EMVISION board on, which does the software and hardware aspect need to revise?
1. removes U17 <br>
Q: The development board can meet the hard disk size has the limit?
Certainly is not develops the board about the hard disk size limit to cause, mainly is because of the operating system decision, theoretically speaking Linux may support the biggest hard disk is 128GB, therefore EM85xx supports the hard disk size also should be 128GB, certainly this is a theory value, regarding this we have not tested, but the 80GB hard disk is does not have the question.
Q: Asked how is at in 85 and 86 platforms changes the net card the MAC address?
Has an application procedure under. the /armutils_2.3.41.0_DCC/gnutools/thirdparties/rtl8139-diag table of contents, may carry on read-write to EEPROM, you need first the EEPROM in data read-out, after revises the MAC address to interpolate again, after again opened had the new MAC address, made when the new board also was allowed to produce the data the bin document, then burnt the piece. <br>
Q: How enlarges the typeface
In 1. device.h 104 lines of increase
GrText (wPtr->wid, wPtr->gc,50,150, "? handles hides the truth from spacious lump to copy Cui Chenjian ABCDEFG0123456789", -1, GR_TFASCII);
Q: How enlarges the typeface (by Han Wenwei example)
In 1. device.h 104 lines of increase
~GrText (wPtr->wid, wPtr->gc,50,150, "? handles hides the truth from spacious lump to copy Cui Chenjian ABCDEFG0123456789", -1, GR_TFASCII);
Q: How transforms the RGB signal YUV (422 patterns) the signal
Unsigned long y = 257* (unsigned long) r + 504* (unsigned long) g + 98* (unsigned long) b + 16,000; <br>
Y = y/1,000; <br>
Unsigned long u = -148* (unsigned long) r - 291* (unsigned long) g + 449* (unsigned long) b + 128,000; <br>
U = u/1,000; <br>
Unsigned long v = 439* (unsigned long) r - 368* (unsigned long) g - 71* (unsigned long) b + 128,000; <br>
V = v/1,000; <br>
Q: How supports the multithreading
1./because translates uclibc to need a uclinux document the support, met first guarantees you already to dispose uclinux, moreover should guarantee arm-elf-gcc was allowed to use
INCFLAGS = -I/home/danny/EM85xx-10-17-2003/uClinux-2.4/include
Q: I can to the CPU ultra frequency? How does?
// CPU CLOCK = 162MHZ
#define PLLREG_DIV 1
#define PLLREG_DIV 1
CPU basic frequency =27MHz * (58 + 2)/((3 + 2) * 2) = 162MHz. <br>
Q: I want to change romfs.bin the start address, needs to change these aspects to be able the normal operation?
~ for example if will tacitly approve 0x6000 will alter to 0x10000<br>
1. revises loader.bin<br>
1) cd uClinux-2.4.17
3) selects "System Type", alters to "FLASH Base Address" value 0x6000 0x10000<br>
Q: I want to support the Han article in EM85xx to demonstrate that, how should do?
1st, fromhttp://www.microwindow.orgdownloading fonts
1. cd uClinux-2.4.17<br>
Q: I want to support the Japanese in EM85xx to demonstrate that, how should do?
1. cd uClinux-2.4.17<br>
Q: I want to support Chinese in EM85xx to demonstrate that, how should do?
1. cd uClinux-2.4.17<br>
3. selects File system-->Nation Language Support-->simplified chinese charset (CP936, gb2312) <br>
Q: I when make the promotion, frequently has the ID number not right wrong prompt?
1. this ID number not specific meaning, but the promotion version certainly must maintain consistently with the original edition
Q: With busybox ifconfig eth0 up 192.168.1.106 netmask 255.255.255.0 establishments networks, prompt cannot find ifconfig?
Q: Changes to how in 8,510 platforms memory from 8MB 16MB?
Kernel has assigned 15.5M, surplus 0.5M assigns for OSD. <br>
Q: In ENVISION 8,510 whether supports "mixes the sound"?
Q: In PVP 8,510 software, how increases a pressed key?
1. ~ please pay attention in ~piodrv/pio.c function pio0_write () and pio0_read (), as well as how does pio0_write () read in a pio register value in piodrv/linux.c, and calculates the value. <br>
2. uses the step 1 center in pvp/input/input.c the value to increase the pressed key the great definition, and () center increases the code in get_input. <br>
Q: In PVP 8,510 software, how lets software when the start, outputs in the television?
In pvp/main.cpp, some variable toggle_display defines the output, 1 is yuv (namely television outputs), 0 is RGB, please look at document pvp/mpegdev/em85xx.cpp about the demonstration establishment. <br>
Loader w/Splash screen v1.0.3 alpha<br>
1. Compile the loaders directory as usual<br>
1. The splash screen is the bmp file stored in romfs directory, it is a
1. set "FLASH Base Address" to 40,000 in configuration menual of uClinux. <br>
Q: In PVP 8,510 software, has what difference about hard disk actuation ata.o and the Linux IDE actuation?
Q: Downloads in loader.bin & romfs.bin after FlexRom is common "KABOOOOM! ! " Error message output?
1. address wires connections have question <br>
Q: Often is common in the translation source code "arm-elf-gcc: Command not is found "the wrong prompt, what reason?
1st, whether please inspect the reset line correct connection (concrete connection please refers to related documents) in the simulator and on the Debug platelet. <br>
RandomPage
The amount of random pages is a number from 1 to 20.
<? Plugin RandomPage pages||=10 info||=''? >
RecentChanges
<? Plugin RecentChanges days||=7 daylist=1,3,7,30,90, 0? >
RecentEdits
<? Plugin RecentChanges days||=3 show_all||=1 show_minor=1 daylist=1,3,7,30,90,0? >
ReleaseNotes
PhpWiki 1.3.x development branch.
PhpWiki 1.2 is a huge advance over version 1.0:
PhpWiki 1.1.9 includes Spanish language pages, a full implementation
PhpWiki 1.1.6 is a major revision of PhpWiki. The ability to have
As we move towards a 1.2 release we will be adding logging, top ten
Below are the release notes for version 1.03, the last release of the
1.0 PhpWiki series. --Steve Wainstead, mailto:swain@panix.com
Version 1.0 is a near-perfect clone of the Portland Pattern
Version 1.01 includes a patch that fixes a small error with rendering
Screen Savers
Int right_flag = 1; <br>
In each place increase such sentence fip_flag=1; (Condition which guarantees according to VFD demonstration different judgement screen)
Fip_flag = 1; <br>
If (flag_~ScreenSaver == 1) <br>
Right_flag = 1; <br>
(3) increases fip_flag=1 in the below sentence; (Has mark) <br>
If ((in_stop_mode == 1) && (main_menu_active == 0)) <br>
Fip_flag = 1; // screen guarantees <br>
Fip_flag = 1; // screen guarantees <br>
Atapi_~TrayOperation (atapi_handle, 1); <br>
Authenticate_disc = 1; <br>
Logo_displayed = 1; <br>
Fip_flag = 1; // screen guarantees <br>
If (fip_flag == 1 && time_flag == 0) <br><br>
Time_start = tv.tv_sec * 1,000 + tv.tv_usec/1000; <br>
Time_flag = 1; <br>
If (time_flag == 1) <br>
Time_end = tv.tv_sec * 1,000 + tv.tv_usec/1000; <br>
If ((time_end - time_start) > 1000*60*5 && (time_end - time_start) < 1000*60*25) //idle 5 minutes<br>
If ((time_end - time_start) %,100 == 0 &&jpeg_flag == 0) //delay 0.1 second<br>
Jpeg_flag = 1; <br>
Flag_~ScreenSaver = 1; <br>
If ((time_end - time_start) %,100 == 0) <br>
If ((time_end - time_start) == 1000*60*25) //idle 25 minutes<br>
Standby_flag = 1; <br>
If (in_stop_mode == 2 && standby_flag == 1) <br>
W = 120; <br>
H = 100; <br>
If (global_x < 250 && right_flag==1) <br>
Else if (global_x>=250 && global_x<x_mid && right_flag==1) <br>
Else if (global_x>=x_mid && global_x<310 && right_flag==1) <br>
Else if (global_x>=310 && global_x< (720-w-40) && right_flag==1) <br>
Else if (global_x == (720-w-40) && right_flag==1) <br>
Left_flag = 1; <br>
If (global_x>=310 && global_x<= (720-w-40) && left_flag == 1) <br>
Else if (global_x<310 && global_x>x_mid && left_flag==1) <br>
Else if (global_x<=x_mid && global_x>250 && left_flag==1) <br>
Else if (global_x<=250 && global_x>30 && left_flag==1) <br>
Else if (global_x <= 30 && left_flag==1) <br>
Right_flag = 1; <br>
In fip_display_symbol (PLAY_FIP_ON, 1); Latter increases <br>
Valid_bookmark = 1;
Dvd_stop_msg_on = 1; // screen guarantees <br>
Fip_flag = 1; // screen guarantees <br>
In fip_display_symbol (PLAY_FIP_ON, 1); Latter <br>
TextFormattingRules
Term 1 |
Definition 1 begins here.
Term 1.1 |
Definition 1.1
Term 1.2 |
Definition 1.2
This is part of definition 1.
Term 1 |
Definition 1 begins here.
Term 1.1 |
Definition 1.1
Term 1.2 |
Definition 1.2
This is part of definition 1.
TitleSearch
<? Plugin IncludePage page=FindPage quiet=1 section=Tips sectionhead=1? >
VFD, the kneading board, the remote control revise
1st, the establishment must test project: <br>
(1) opens the fiptest.cpp document and carries on as follows revises <br>
// is 1 to test<br>
#define FIP_TEST_KEYS 1<br>
#define D_FIP_ON 1<br>
#define TWIRL_1_FIP_ON 5
#define TWIRL_6_FIP_ON 10
#define TWIRL_MID_FIP_ON 11
#define MP3_FIP_ON 12
#define L_FIP_ON 13
#define R_FIP_ON 14
#define PBC_FIP_ON 15
#define REPEAT_FIP_ON 16
#define ALL_FIP_ON 17
#define PLAY_FIP_ON 18
#define PAUSE_FIP_ON 19
#define DOLBYDIGITAL_FIP_ON 21
#define V1_FIP_ON 26
Note: If on VFD this symbole, we had not could its value establishment be -1<br>
#define SC_PANEL_PREV 0x10000010
#define SC_PANEL_NEXT 0x01000001
#define SC_PANEL_EJECT 0x00100000
#define SC_PANEL_PLAY 0x00010000
#define SC_PANEL_STOP 0x00000100
WAV
1, in fileplay.h document, <br>
Chunk~ [ i ] = chunk~ [ i+1 ]; <br>
Chunk~ [ i+1 ] = temp; <br>
Case 0x0001: // PCM<br>
Case 0x0001: //PCM<br>
Fip_display_symbol (DOLBYDIGITAL_FIP_ON, 1); <br>
Fip_display_symbol (MP3_FIP_ON, 1); <br>
Else if (audioFormat.formatTag == 0x0001) // PCM<br>
If ((audioFormat.nSamplesPerSec == 16,000) ||<br>
(audioFormat.nSamplesPerSec == 44,100) ||<br>
Fip_display_symbol (DOLBYDIGITAL_FIP_ON, 1); <br>
Fip_display_symbol (MP3_FIP_ON, 1); <br>
Else if (audioFormat.formatTag == 0x0001) {<br>
Ext~ [ 0 ] == 'M' && ext~ [ 1 ] == 'P' && ext~ [ 2 ] == '3') ||<br>
(ext~ [ 0 ] == 'W' && ext~ [ 1 ] == 'A' && ext~ [ 2 ] == 'V') ||<br>
WMA
1. decompresses libraries.tar.gz and the copy libwma table of contents to the /libraries table of contents in. <br>
If ((ext~ [ 0 ] == 'M' && ext~ [ 1 ] == 'P' && ext~ [ 2 ] == '3') ||<br>
(ext~ [ 0 ] == 'A' && ext~ [ 1 ] == 'C' && ext~ [ 2 ] == '3')) {
If ((ext~ [ 0 ] == 'M' && ext~ [ 1 ] == 'P' && ext~ [ 2 ] == '3') ||<br>
(ext~ [ 0 ] == 'A' && ext~ [ 1 ] == 'C' && ext~ [ 2 ] == '3') ||<br>
(ext~ [ 0 ] == 'W' && ext~ [ 1 ] == 'M' && ext~ [ 2 ] == 'A')) {<br>
If ((ext~ [ 0 ] == 'M' && ext~ [ 1 ] == 'P' && ext~ [ 2 ] == '3') ||<br>
(ext~ [ 0 ] == 'A' && ext~ [ 1 ] == 'C' && ext~ [ 2 ] == '3')) {<br>
If ((ext~ [ 0 ] == 'M' && ext~ [ 1 ] == 'P' && ext~ [ 2 ] == '3') ||<br>
(ext~ [ 0 ] == 'A' && ext~ [ 1 ] == 'C' && ext~ [ 2 ] == '3') ||<br>
(ext~ [ 0 ] == 'W' && ext~ [ 1 ] == 'M' && ext~ [ 2 ] == 'A')) {<br>
WabiSabi
(quoted from "[ WABI-SABI: FOR ARTISTS, DESIGNERS, POETS & PHILOSOPHERS | http://www.amazon.com/exec/obidos/tg/detail/-/1880656124/qid=1054098290/sr=1-1/ref=sr_1_1/104-9834820-5562358? V=glance&s=books], "1994, Leonard Koren)
In Japan around the 12th century. Zen emphasizes '' "direct, intuitive
(also taken from WABI-SABI: FOR ARTISTS, DESIGNERS, POETS & PHILOSOPHERS, 1994, Leonard Koren):
WikiPlugin
<? Plugin BackLinks page= [ pagename ] noheader=1? >
[ Q:Debug uses how does the string mouth line do
1please rebuild a null model cable by connect connect pin 2,3 and 5, and leave all other pins open. The pin 2 and 3 must be cross over. <br>
"Use service term"
1st, how about visits this website, please cannot disclose gives any person. <br><br>
Each language file name demonstration support
1 inputs make menuconfig in uClinux-2.4.17 to redeploy Kernel. <br>
3.1 mount iso9660 (compact disc) <br>
3.1.1 opens the EM85XX\isonav.cpp document. <br>
3.1.2 revises in isoNavigatorThread function <br>
Retval= mount ("/dev/cdroms/cdrom0", "/cdrom", "iso9660", MS_RDONLY | MS_NOSUID | MS_NODEV, "iocharset =gb2312, codepage =cp936"); <br>
3.2.1 EM85XX\dvdplayer\main.cpp in sentence: <br>
Retval=mount ("/dev/ide/host0/bus0/target0/lun0/part1", "/cdrom", "vfat", MS_RDONLY | MS_NOSUID | MS_NODEV, NULL); <br>
Firmware promotion
1) cd uClinux-2.4 <br>
@Version 1.0.1.0 // establishment edition number <br>
@Date 2003-07-01 // date <br>
~@Player ~HuaLu SH-418 Divx // player model <br>
@Reset 1 // whether in promotion time eliminates in EEPROM the data, the if 1 elimination, else does not eliminate <br>
Development system building
1st, installs Server, please completely installs redhat 8.0 and starts the samba service (about the samba disposition, please refer to related books). <br>
1.1st, compact disc on tools-install.tar.gz document copy to hard disk on. <br>
1.2nd, tar zxfv tools-install.tar.gz // releases tools-install.tar.gz. <br>
1.3rd, orders with cp the tools-install copy to in the system /opt table of contents, namely: Cp -r tools-install \opt\<br>
1.4th, copy genromfs (produces the romfs.bin document with him) to linux in the system bin table of contents (if does not have this document, please produce this document). <br>
1 pc. FR3-32M FlexRomIII from Tech Tools (see ordering info). <br>
1 pc. ACM-16 module from Tech Tools for the FlexRomIII (see ordering info). <br>
1 pc. Header 1x5 (for modification of ACM-16 module) <br>
1 pc. IDE 40 pin cable. (Cable should be shorter than 6 inches) <br>
1 pc. customized cable for A18 to A20 connection. (Preparation see next page.) Br>
__PREPARATION ACM16 MODULE__<br>
1) Solder one header 1x5 into position of JP5<br>
3) prepare one customized cable to connect signals A~ [ 20. 18 ] from ACM16 to the target board<br>
4) connect customized cable to JP5 and JP4 (A 20, 19, 18) <br>
6) connect 40 pin IDE cable to JP1 (be aware of pin1) <br>
7) Plug ACM16 module into FlexRomIII emulator box. <br>
1 pc. female header 1x3<br>
1 pc. female header 1x2<br>
1 pc. female header 1x1<br>
1) connect 40 pin IDE cable to JP1 (be aware of pin1 - if this connector is reversed then power<br>
2) connect customized cable to J31 (A20, 19, 18) <br>
3) connect reset line with clip to J14 as shown<br>
4) set jumper J32 to postion 1-2 (EMU) <br>
(PARTNUMBER 53-000717) <br>
1) connect 40 pin IDE cable to J3 (be aware of pin1 - if this connector is reversed then power<br>
2) connect customized cable to J7 (A20, 19, 18) <br>
[ http://www.hdtv.com.hk/em85xx/wiki/gb/upload/hardware1.jpg ] <br>
How mount NFS filing system
1st, from has hit in uClinux patch Linux Kernel include/linux/lockd and the include/linux/nfsd table of contents copy to in the uClinux-2.4 corresponding catalogue. <br>
1) $ make menuconfig <br>
1st, tar zxfv portmap_5beta.tar.gz <br>
1) $ setup <br>
Joins for example: Share/nfsshare 192.168.1.0/255.255.255.0 (rw) <br>
1) $ mount ¨Ct proc none /proc <br>
2) $ bin/busybox ifconfig lo up 127.0.0.1 netmask 255.255.255.0 <br>
3) $ bin/busybox ifconfig eth0 up 192.168.0.107 netmask 255.255.255.0 <br>
How can demonstrate each kind of typeface and the enlargement in the broadcast machine
1st, first joins Microwindows the fonts. <br>
Retval = mount ("/dev/cdroms/cdrom0", "/cdrom", "iso9660", MS_RDONLY | MS_NOSUID | MS_NODEV, "iocharset=gb2312, codepage=936") <br>
How disposes Ram Disk
[ http://www.hdtv.com.hk/em85xx/wiki/gb/upload/ramdisk1.jpg ]
Seventh, cp uclinux2.4.17/drivers/block/rd.o romfs/bin<br>
Eighth, cp uclinux2.4.17/fs/minix/minix.o romfs/bin<br>
How uses the hard disk to carry on the firmware promotion
* (long *) 0x1780000 = 0; // joins a line, supposes the starting value in 0x1780000 is 0 <br>
~IdeTray (1); <br>
* (long *) 0x1780000 =1; After // presses the stop key to suppose the value is 1<br>
If (* (long *) 0x1780000 == 0) // increase line of <br>
How makes the broadcast machine center the PNG picture
1st, opens gif from EM85XX/romfs/imggif with photoshope to attempt <br>
[ http://www.hdtv.com.hk/em85xx/wiki/gb/upload/png1.jpg ] <br>
1st, produces the png chart, after translates document - gif2png which gif2png-2.4.6 can produce may carry out, can transfer according to the following step the gif chart the png chart, namely: . /gif2png ¨co XX.gif, produces of the same name png to attempt <br>
How makes the hard disk broadcast machine
First in the website downloads "linux-2.4.17" from [ http://www.kernel.org ] the essence, specifically goes via <br>
1) [ http://www.kernel.org ] <br>
6) click "linux-2.4. 17.tar.gz" <br>
Simultaneously must [ org in the website download "uClinux-2.4.17-uc0.diff.gz" from http://www.uClinux ] the patch procedure, way <br>
1) [ http://www.uclinux.org ] <br>
3) click "uClinux-2.4.17-uc0.diff.gz" <br>
1) tar zxvf linux-2.4.17.tar.gz // releases kernel, produces Linux table of contents <br>
2) tar zfxv uClinux-2.4.17-uc0.diff.gz // releases the uClinux patch procedure, produces uClinux-2.4.17-uc0.dff <br>
4) patch ¨Cp1 <.. /uClinux-2.4.17-uc0.diff // gives the kernel procedure to get the patch, causes it to become uClinux kernel <br>
[ http://www.hdtv.com.hk/em85xx/wiki/gb/upload/hd1.jpg ]
6.1st, establishment connection type, according to following several charts establishment then <br>
10) make // retranslates kernel to produce new linux.bin and linux.bin.gz <br>
11) make // retranslates <br> under EM85xx_root
12) download loader.bin & romfs.bin to Emulator <br>
13) after the system guidance completes can demonstrate found the hard disk type, and has each district the type, in the usual situation the demonstration is: <br>
/dev/ide/host0/bus0/target0/lun0:p1 p2 (Pn is district which hard disk has) <br>
14) we this time may under the shell condition manually hard disk district mount to the system in, if may write is: <br>
:\>bin\busybox mount ¨Ct vfat /dev/ide/host0/bus0/target0/lun0/part1 <br>
. /cdrom (our supposition was arrived thirdparties\busybox in table of contents document copy in the bin table of contents, and supposition part1 was vfat filing system) <br>
1 Dvdplayer\main.cpp<br>
Retval=mount ("/dev/ide/host0/bus0/target0/lun0/part1", "/cdrom", "vfat", MS_RDONLY | MS_NOSUID | MS_NODEV, NULL); <br>
In "/dev/ide/host0/bus0/target0/lun0/part1" target0 changes target1<br>
~ has again if you did not think mount part1, ~ must change part1 other districts. <br>
Software architecture analysis
1) uClinux 2.4: Linux kernel, in order to save the system space and time, therefore will put in order the essence to carry on the optimization, we might according to "redeploy" which above said to change the system essence, caused him to support multi-purpose or the reduced function support module, simultaneously might establish the different disposition document in the different application situation, achieved the reduced system the load, under uClinux ¨C2.4 table of contents worthy of looking at to following disposition document: <br>
Mpegplayer: Produces mpegplayer.bin, uses in to broadcast MPEG 1 System Stream, MPEG 2 Program Stream, form the and so on MPEG 2 Transport Stream class document, the usage and fileplayer.bin is same. <br>
The first procedure the system initiation moves which after the usual situation is dvdplayer.bin, this procedure mainly completes examines in loader the small dish type, then execution corresponding procedure, because the Em85xx system certainly does not support the line regulation the programming, therefore has while in the master routine (1) the endless loop is at the waiting status, simultaneously in fileplayer.bin and in mpegplayer.bin application procedure pressed key processing similarly is while (1) is the circulation. <br>
While (1) <br>
1. dvdplayer.bin<br>
(1) examines the compact disc the type. <br>
Carries on the firmware promotion through Emulator
1st, first makes a promotion compact disc (Boot CD) <br>
Promotes romfs.bin & loader.bin through Emulator
1st, first makes a promotion compact disc (Boot CD) <br>
Network development
A tftp server uses winagents tftp service V2.1, based on the windows platform, after the installment has tftp the root table of contents, uses for to deposit the customer loader.bin, linux.bin, the romfs.bin three documents, may by customer end downloading. <br>
1) Revises in the loaders table of contents document <br>
1. revises the main.c document, (50,000) alters to DELAY DELAY (1 million) <br>
2. revises the config.h document, #define DOWNLOAD_ROMFS_ADDRESS 0x01400000 <br>
Alters to #define DOWNLOAD_ROMFS_ADDRESS 0x01C00000 <br>
3. alters to Makefile document 16th line of RELEASE = y RELEASE = n. <br>
1. uses QuickLoader increase loader.bin, the system just started when according to the free keyboard, entered loader.bin BootMenu order line of boot><br>
1. cd uClinux-2.4 <br>
5. Select "System Type" and change "FLASH Base Address" to 01C00000<br>
Unsigned int *address = 0x1C00000; <br>
While (! Romfs_check ((unsigned int *) address) && address < 0x1F00000) <br>
Address += 0x1000; <br>
Return (address >= 0x1F00000)? 0: Address; <br>
Network establishment
1. uses "config-net" the disposition document redeploys uClinux-2.4 kernel and translates <br>
6. Character string becomes "@cp -f config-net config" <br> 31 line of "@cp -f config config the"
10. changes found the character string becomes "command ("sh /etc/sashrc");" The site ? strings together <br>
After 11. completes the sach.c document to revise retranslates ("make") "sash" document. <br>
12. enters "/thirdparties/udhcpc" table of contents <br>
13. edits "script.c" document <br>
14. in opens "script.c" in the document to search "run_script ()" function <br>
15. in "str~ [ 256 ];" Weapon evening Zhu Lijia ? suddenly ? "str2~ [ 256 ];" Br>
After 16. will complete and "argv~ [ 0 ] = str; Argv~ [ 1 ] = NULL;" Changes "sprintf (str2," /bin/sh"); Argv~ [ 0 ] = str2; Argv~ [ 1 ] = str; Argv~ [ 2 ] = NULL; "<br>
17. "execve (str, argv, envp);" Changes "execve (str2, argv, envp);" Br>
After 18. "script.c" the document change will complete preserves pays equal attention to newly will translate "udhcpc" document. <br>
19. copies "udhcpc" document to "/romfs/bin in" table of contents <br>
21. if in the table of contents has the init document in "romfs/bin/" please its deletion <br>
Sash command shell (version 1.1.1) <br>
Enter IP Address as XXX.XXX.XXX.XXX (Enter for DHCP): Assigning Static IP Address 192.168.1.106 // inputs IP address <br>
Char str~ [ 100 ]; <br>
Char str2~ [ 100 ]; <br>
Char str3~ [ 100 ]; <br>
Char *agv~ [ 16 ]; <br>
Current_disc_type = -1; <br>
Return 1; <br>
Agv~ [ 1 ] = str2; <br>
Exit (1); <br>
Return 1; <br>
Exit (1); <br>
The network establishment (is restricted in the nextbase-xx.xx.xx.tar.gz development package)
1. uses "config-net" the disposition document redeploys uClinux-2.4 kernel and translates <br>
6. Character string becomes "@cp -f config-net config" <br> 31 line of "@cp -f config config the"
10. changes found the character string becomes "command ("sh /etc/sashrc");" The site ? strings together <br>
After 11. completes the sach.c document to revise retranslates ("make") "sash" document. <br>
12. enters "/thirdparties/udhcpc" table of contents <br>
13. edits "script.c" document <br>
14. in opens "script.c" in the document to search "run_script ()" function <br>
15. in "str [ 256 ];" Weapon evening Zhu Lijia ? suddenly ? "str2 [ 256 ];" Br>
After 16. will complete and "argv [ 0 ] = str; Argv [ 1 ] = NULL;" Changes "sprintf (str2," /bin/sh"); Argv [ 0 ] = str2; Argv<br> [ 1 ] = str; Argv [ 2 ] = NULL; "
17. "execve (str, argv, envp);" Changes "execve (str2, argv, envp);" Br>
After 18. "script.c" the document change will complete preserves pays equal attention to newly will translate "udhcpc" document. <br>
19. copies "udhcpc" document to "/romfs/bin in" table of contents <br>
21. if in the table of contents has the init document in "romfs/bin/" please its deletion. <br>
Sash command shell (version 1.1.1)
Enter IP Address as XXX.XXX.XXX.XXX (Enter for DHCP): Assigning Static IP Address 192.168.1.106 // inputs the <br>IP address
Char str [ 100 ];
Char str2 [ 100 ];
Char str3 [ 100 ];
Char *agv [ 16 ];
Current_disc_type = -1;
Return 1;
Agv [ 1 ] = str2;
Exit (1);
Return 1;
Exit (1);
Http://www.hdtv.com.hk/em85xx/wiki/gb/upload/applets-2002-11-18.tar.gz
Last edited on Thursday, April 8, 2,004 12:45:37 pm.
Hardware platform introduction
* 1, the Em85xx board mainly has main chip EM85XX, this chip 7 microprocessors and MPEG decorder 1/,2/4 is composed by 162Mhz the ARM. <br>
* 2, support biggest RAM and Flash respectively are: 16MB and 4MB. <br>
* 5, network support function: Supports 10MB and the 100MB auto-adapted network connection regarding EM8550, outside hangs DM9000E on the EM8550 board the network chip, this chip mainly passes <br>
Inserts Chinese demonstration in EM85xx
1. Decompression document microwindows-fonts-0.89.tar. <br>
HAVE_GB2312_SUPPORT = Y<br>
Center document asc12, asc16, hzk12, hzk16, hzx12, hzx16 copy to newly built folder in. <br>
Retval = mount <br> (/* "/dev/cdroms/cdrom0" */ "/dev/ide/host0/bus0/target0/lun0/part5", "/cdrom", /* "iso9660" */ "vfat", <br> MS_RDONLY | MS_NOSUID | MS_NODEV, "iocharset=gb2312, codepage=cp936"); <br>
Simplified Chinese charset (CP936, GB2312) selects <br>
Parameter: Name:1. Simplified Chinese is "HZKFONT"
Height: At present supports 12, 16, 24, 32 picture elements, may establish is 12, 16, 24, 32.
GrText (wPtr->wid, wPtr->gc,150,300, "you good", -1, GR_TFASCII);

Reads the full text(507) | reply (1) | the quotation circular(4) | edition


* Previous:JPEG Decompression details
* Next:Linux to IO port resources management


Reply: EM85XX knowledge base
[ 2006-4-1 13:46:00 | By: Yp0203 ]


Ask in microwindow

GR_GC_ID gc, gc_pal0, gc_pal6, gc_pal244;

GR_GC_ID gc_red, gc_gray, gc_test, gc_white;
GR_GC_ID gc_yellow, gc_subtitle;

I knew these all are the color parameters, what but do they have to distinguish?

I already added you was the good friend, hoped our many exchanges, studied to you!

I wonder where the refered "www.hdtv.com.hk/em85xx/wiki" has gone? Looks like it contained a lot of interesting things (http://forum.divx.pl/viewtopic.php?t=17222). A default Apache page is all there is left at: http://www.hdtv.com.hk/

Hi Guys,

did you see the GPL sourcecode on mediagateusa?
(can't post any links yet, sorry)

I wonder if everything is is included.
Keep up the good work

Umtauscher

I've had a quick play with the kernel in the GPL release.

There doesn't seem to be a config that matches the MG-35 - IDE support isn't turned on in any of the supplied ones and the Jasper IDE isn't available in the menu.

And the missing symbols are still no-where to be found.

Ian

guys,

here's some info from russia. also, it appears from other info that the OSD ram is the last 512k of RAM ....

Yes, originally they used microwindows (we don't) and wrote a 'driver' which called low-level funcs of khwl.o. We had to reverse-engineer the interface of khwl - and created our libs.

The graphics has some parts:
- 8-bit OSD (plus 24+8-bit palette with alpha) - used for GUI;
- YUV-buffer for direct access - used for JPEG output;
- video decoder interface - to display MPEG streams;
- SPU interface - to process subtitles and DVD highlights;


Wow, that's all good stuff. The video at 0x1F80000 is backed up by the .confg files in the GPL source release.

Ian

By the way, are there any Linux kernel hackers around who can sanity check my findings with the Airlinktech GPL release? I really can't make the source/config for the kernel match up with the MG-35.

We might be able to "mate" the KiSS config and the supplied config (mainly to get the right IDE options in there), and reverse engineer the missing bits, but it would be so much nicer if Airlinktech would release the right code!

Their GPL releases really should identify which product they are for and which firmware version.

Ian

Please, if anyone got time, inject this palette in dvdplayer.bin. Then run it and look for the colors of text in all menus (the text drawn at runtime not the one on graphics like PNG and JPEG images). I am especially interested in the setup menu because it also has rounded squares drawn in runtime behind the values (values are text).


I'll try and do this at the weekend. But I haven't used any of the Windows tools so far - I'm more of a Linux guy.

Ian

if no-one has put their hand up for the firmware extractor/creator i'll do it .... i figure your time is much better spent on other things.


Woo hoo, a volunteer! Did my rough ideas regards spec make sense? Between this and the wiki file format details, do you have everything you need?

As long as the code includes the bare minimum of std libs, I'm happy to tackle any required Linux builds and testing and can also test on Windows. But I'm not setup to do any builds on Windows.


and yeah, the kernel thing is a big leap but we'll get there eventually !!!


Well, today we got a GPL release from Airlinktek, I also got this separately via Freecom, and I also got an email back from Saerom Kim. Looks like things are moving. We have a kernel, just not the right one, yet.

My main task at the moment is JTAG recovery, but I'm playing with kernels while I wait for the dev box. I'd love someone else to step up and be kernel guru, but can manage simple stuff in the mean time.

Ian

As teddystacker has added a Paypal button to the wiki page, I have changed the password of the wiki to stop any passing person changing it.

Please email me or teddystacker if you want the new password. And I hope you do email us, as the more the merrier on the wiki!

Thanks

Ian

As already posted by umtauscher ,today Al Tech Released what they say is the GPL source code for the MG-35 - here are the download locations:

http://www.airlinktek.com/english/firmware/GPL.zip

and at a non expiring Rapidshare mirror:-

http://rapidshare.de/files/29003462/GPL.zip.html

Hmmmm. This bootloader output -

--------------------------------------------------------
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
--------------------------------------------------------

Looks *very* much like blkmem and CFI output that's generate by Linux. I wonder if flyduck might have "borrowed" a bit of code?

There are signs in some other kernel source that the/a bootloader is built against it.

However, I'm not going to make accusations until it's investigated more closely.

Ian

I'll try and do this at the weekend. But I haven't used any of the Windows tools so far - I'm more of a Linux guy.


OK, palette patched, new cramFS built, kernel and cramFS stuck together, and the file built and checksums patched. It's currently quite a lengthy process with many stages done by hand. I can bash script some of it, but pb's checksum patches and palette patcher are currently windows only.

Roll on a simple splitter/joiner!

I'll try the new firmware with Spectrum palette this weekend. I guess if it doesn't toast my box, and I can flash back to normal firmware, I can send it to EmuMannen for closer inspection.

Ian

I'll try and do this at the weekend. But I haven't used any of the Windows tools so far - I'm more of a Linux guy.
Don't worry I will inject it for you (using my Windows box) and put it on Yahoo Groups for you (or mail it directly, I will need a new password for the wiki anyway). FIY, I will spend the neext week on the French riviera (without Internet access, only family access)...

[begin edit]Baaahh, too late, you already got it sorted...[end edit]

Don't worry I will inject it for you (using my Windows box) and put it on Yahoo Groups for you (or mail it directly, I will need a new password for the wiki anyway).


Don't bother, I've done it, and I'll PM you the new password.


FIY, I will spend the neext week on the French riviera (without Internet access, only family access)...

I'm not sure I like the sound of that! :)

Ian

The development unit is now here with me. I have unpacked just the bits I need and have left everything else and all the packaging in the box.

So far, all I've done is test that it shows video (no HD in it or network connected) and then opened it and moved across the serial. I might do some misc work on it this weekend (new Spectrum palette) but the real stuff will kick off next week.

I'll take the unit to work on Monday and do the fiddly work of wiring from the "JTAG" header to something I can work with, and also fitting suitable series resistors and pull ups/downs.

Then I bring it home and start wiggling. I'd do this at work, but my Linux dev machine there doesn't have parallel, and neither does my notebook (dual boots Ubuntu) But I have a Linux "play" machine here that I can use.

I just have to hope no-one misses one of the desktop storage scopes. :-)

Ian

Great news Ian , have to admit they delivered that quick , did it come with 1.4.4?

Great news Ian , have to admit they delivered that quick , did it come with 1.4.4?

It came with a Freecom firmware, which I think is still back at 1.4.2

The first thing I did was flash it with the image that I built today. The kernel unpacked and then everything ground to a halt. I clearly didn't build the cramFS correctly, probably made a mess of the device nodes. I need to do more reading.

However, I used the serial debrick procedure and romfs.m35 file on the wiki and it worked a treat.

Ian

Phew!,glad to know you de-bricked it ok,otherwise it would be memories of 1968 really quick - to be serious its a good test of the serial recovery tools..

The first thing I did was flash it with the image that I built today. The kernel unpacked and then everything ground to a halt. I clearly didn't build the cramFS correctly, probably made a mess of the device nodes. I need to do more reading.So... did it last as long as your helicopter before you broke it ;)
However, I used the serial debrick procedure and romfs.m35 file on the wiki and it worked a treat.Guess the ear-wax wasn't enough this time to perform the repair. :D

Good luck next week with the wiggling.

Joe L.

Phew!,glad to know you de-bricked it ok,otherwise it would be memories of 1968 really quick - to be serious its a good test of the serial recovery tools..

Yeah, yeah, I was expecting all the helicopter and earwax stuff to come out. You guys never disappoint. :-)

Anyway, my cramFS was pants and I'd copied it without realising this dropped the empty dirs. Doh! I've built a new one from scratch and it's fine.

BTW, I might be cracking up, but it looks like the cramFS I started with (I forget which .update I pulled it from) doesn't have softlinks to busybox but instead has multiple copies.

Is this right?

Ian

Well at long last i have got it through my webhost head that it is a server side issue with my site not sending out new user activation emails, good news is once he has fixed this i will be moving on to a new host with 2gig of webspace and unlimited bandwidth per month, so i can only hope i will be hosting the files and etc again soon :)

...my site not sending out new user activation emails...
Great! But does this mean we can't download any files w/o registering first? :( I think I've registered with 3 new fora and subscribed to 2 yahoo groups in the last 5 days, and that was only for one little gadget! :eek:

hi everyone and thank you for all the great info! I got my mg35 on monday and a 400gb 16mb 7200rpm hdd today. It now transfers 30gb in 20mins :) (usb) I can't wait till someone creates a new gui like cowboys. Cheers

Over on the Mediagateuse forum, Anywareus said -

Anything regard the GPL source code they will answer back after Aug, 25. so when the time is come, i will collect all the information here in this board and send it to them.


So far we think that the kernel source doesn't match the binary one supplied with the MG-35, though I'd like others to give their opinions on this.

We also think that dvdplayer.bin and probably the boot ROM also contain GPLd code.

Perhaps we ought to methodically check the various elements of the MG-35 distribution, say which we consider to be covered by the GPL, and present this to Anywhereus for reporting back to Airlinktek?

I'm perhaps best placed at the moment to tackle the boot ROM. Anyone want to volunteer to check any other parts?

Ian

I have uploaded a new palette file (Spectrum.act) to Yahoo Groups (also attached to this post). It is a full spectrum palette (from purple to red). It will make the GUI look terrible but it should make it easy to estimate in what part of the palette MG-35 is assigning colors for text and runtime drawn objects.


After one aborted attempt whereby I put the palette into a 1.4.3 dvdplayer.bin (thereby putting it in the wrong place!) I now have a Shell144c.upgrade which seems to work and looks really, really nasty. I have successfully flashed back to normal firmware using the GUI.

So, perhaps rather than me describing how lurid it looks, you can just give it a go -
http://www.foxhill.co.uk/Shell144c.upgrade

Own risk, Caveat Emptor, YMMV, and the value of shares may go down as well as up.

Ian

So, perhaps rather than me describing how lurid it looks, you can just give it a go -
Ian, maybe I should have been more explicit in what to expect using the full spectrum palette. What I want is to home in on where in the total palette text colors and other runtime graphics are located. That’s why the palette in evenly separated in the full spectrum (like a rainbow). It will of course distort all graphics (the PNG-images) but that is not of interest for this test. I am only interested in text (and the filled frames behind text values in the settings menu). Let’s say that text that turns out white in the original firmware turns out magenta with the spectrum palette. That will prove to me that the white used for menus is picked somewhere among the first 10 entries in the palette (before it turns purple). If black turns out red then is it among the last 10 entries (before it turns orange) and so on. This test will prove valuable especially for the gray text since gray entries are spread all over the original palette so it is almost impossible to tell the exact index. If such text turns out cyan for example then I know that it should be located around index 100. I could then make up a new palette with unique colors around index 100 and it would then be super easy to know exactly what index is used for the text. This method will cut down try-and-error iterations (it might be enough with just two if we are lucky).

I would be happy to do it my self if my family let me. My unit must be considered a “production unit” but if it is possible to flash it with a new flash (without too much risk of bricking it) with contained functionality (like playing ISO-files, since that is what it is used for), then I’m willing to try it.

What do I need to do in order to try out patched dvdplayer.bin files? Is there a firmware with normal functionality with just telnet added? I want something that could be used as normal during “business hours” but that I could play with at night. Would it be enough to mount an SMB share over the original /bin/ and launch custom dvdplayer.bin files from that share?

I would be happy to do it my self if my family let me. My unit must be considered a “production unit” but if it is possible to flash it with a new flash (without too much risk of bricking it) with contained functionality (like playing ISO-files, since that is what it is used for), then I’m willing to try it.


Your best bet is to flash the .upgrade I linked to, have a look around, make notes, take pictures, and then reflash back to a production firmware. I did pretty much exactly this today and it worked fine.


What do I need to do in order to try out patched dvdplayer.bin files? Is there a firmware with normal functionality with just telnet added? I want something that could be used as normal during “business hours” but that I could play with at night. Would it be enough to mount an SMB share over the original /bin/ and launch custom dvdplayer.bin files from that share?


There is no firmware currently that allows this. dvdplayer.bin is run by sashrc and it doesn't like being shut down and restarted. (Well, I failed, but someone else might succeed.)

What we need is firmware that mounts an smb or hd share before launching dvdplayer. This will need to read some config from somewhere, which is why I was reverse engineering the config file format.

Ian

I would be happy to do it my self if my family let me. My unit must be considered a “production unit” but if it is possible to flash it with a new flash (without too much risk of bricking it) with contained functionality (like playing ISO-files, since that is what it is used for), then I’m willing to try it.



If we get enough money donated (Fund back up top $75.00 atm) , would you be papared to accecpt a "development" unit?,which would free up your family unit.. - Ewaggle.com over here are now selling Mg-35's for only $89.00 + shipping.. I know you are in The Land Of Abba but we can see what develops

Let’s say that text that turns out white in the original firmware turns out magenta with the spectrum palette. That will prove to me that the white used for menus is picked somewhere among the first 10 entries in the palette (before it turns purple). If black turns out red then is it among the last 10 entries (before it turns orange) and so on.

If you give me a list of which bits of text you're interested in, then I can easily complete the table with colours. I just wasn't sure what level of detail to go into.

Ian

This will need to read some config from somewhere, which is why I was reverse engineering the config file format.


BTW, I'm fairly sure that config read/write is done via ioctls to khwl Sussing these calls so that we can get our own area of config would be great. Running a tiny web server in the background to handle our addition UI needs should be easy enough.

Of course, such additional stuff can be on HD for those with HDs fitted. Who else is doing what I'm doing and using the unit just for network media?

Ian

I just made some new 1.4.4 firmware for our box here that uses the nbtscan script I posted earlier (but with a copy rather than an echo as redirection doesn't work!) so our box goes very quickly to our video server rather than taking ages to scan and then select the right machine.

I showed wife and daughter.

I got the quality comment, "Wow, so you're actually improving it rather than just messing around?"

Tsk!

Ian
P.S. The redirection issue meant that my 1st go didn't work and needed some telnet back-door hackery to get the box to reflash over the network. But I just did about half a dozen reflashes in a row on our personal MG-35, which shows how confident I am in the serial recovery. I wish I was brave enough to try a .upgrade file without the BOOT section!

would you be papared to accecpt a "development" unit?,which would free up your family unit..

My view is that anyone actually creating their own .upgrade files need a serial lead.

Is it only pb and myself who've done this so far?

Ian

Who else is doing what I'm doing and using the unit just for network media? I typically test my files first over the net. But since I don't have a networked terabyte sitting in my basement, ;) and the brand new 250GB Seagate in my Mediagate is the largest disk I own, eventually I move the files there and delete them from my PCs.

If we get enough money donated (Fund back up top $75.00 atm) , would you be papared to accecpt a "development" unit?,which would free up your family unit.. - Ewaggle.com over here are now selling Mg-35's for only $89.00 + shipping.. I know you are in The Land Of Abba but we can see what developsThanks for the offer but I try to hold back in favor for the ones doing the low level hardware stuff. I am pretty confident that I can build a new GUI more or less blind (just imagine the final result in Photoshop) as long as someone can act as my eyes (debugging the GUI for anomalies or info like information regarding palette entries etc.).

If you give me a list of which bits of text you're interested in, then I can easily complete the table with colours. I just wasn't sure what level of detail to go into.I will try to put together some detailed description (taking out any guess work on your behalf) tonight, problem is my wife is nagging about packing up for out tour to France tomorrow. Hopefully I manage to get something together before I leave...

Ewaggle.com over here are now selling Mg-35's for only $89.00 + shipping... :eek: I don't see that price this afternoon... Were you perchance looking at the MG-25 price by mistake?

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.


I did an smbmount of my home dir into /net/home. I then did -

mount -t iso9660 -o loop,ro /net/home/bootdisk/bootcd.iso /iso

and it worked just fine.

Perhaps playing an ISO is memory hungry? ftpd and telnetd take an extra 750MB between them, and then there's an extra shell. Remember, this is uClinux, so no MMU, so any loaded program needs the full memory size - it can't fault in as required.

Perhaps someone who is struggling to play ISOs can try using telnet to kill ftpd (and then even perhaps telnetd!) and see if ISOs work again.

Ian
P.S. I don't have an DVD ISOs to test video/menus!

Can someone explain what gives with all the various shells?

I've always just used the busybox shell on embedded stuff, but there again, I'm new to uClinux. I'm not sure how BB on uClinux handles daemonising in a memory efficient way.

Ian

I've always just used the busybox shell on embedded stuff, but there again, I'm new to uClinux.
IanI only got busybox on my Dreambox and thats enough for that box (doing a lot more than my MG-35)...

:eek: I don't see that price this afternoon... Were you perchance looking at the MG-25 price by mistake?

Nope:-

Ebay auction number is :190019482815

$89.99 is not the buy it now price , but I reckon if you bid correcty you would get one at that price..

Looking at past auctions the lowest one has gone for is $96.00

Looks like they may be clearing stock - from reading past posts the MG-350HD FOB (landed price for Distributors) is around $135.00 , so I guess Anywhere are paying around $65-75.00 FOB for the MG-35 atm,as they then have to sell onto places like Ewaggle , no one makes huge amounts on these things..

I will try to put together some detailed description (taking out any guess work on your behalf) tonight, problem is my wife is nagging about packing up for out tour to France tomorrow. Hopefully I manage to get something together before I leave...I have attached a PDF-file pointing out the graphical elements I am interested in (what color they show up in when using the spectrum palette). I have to hit the bunk now since I have a plane to catch tomorrow morning (have to get up at 4 a clock! :eek: ). Se you all in a week...

I have attached a PDF-file pointing out the graphical elements I am interested in (what color they show up in when using the spectrum palette). I have to hit the bunk now since I have a plane to catch tomorrow morning (have to get up at 4 a clock! :eek: ). Se you all in a week...

Take care and have a great holiday , I spent two weeks down there in 1986 and was superb,make sure you take a day trip to Monaco - well worth it..

Look forward to seeing you back....

I have attached a PDF-file pointing out the graphical elements I am interested in (what color they show up in when using the spectrum palette).

#1 Red
#2 Purple
#3 Green
#4 Green
#5 Red
#6 Purple
#7 Red
#8 Purple
#9 Green
#10 Sea Green

Shaky pics hopefully attached.

By the way, with the spectrum palette loaded, the graphics at power up/down still look normal. I guess these use a different palette.

Ian

I only got busybox on my Dreambox and thats enough for that box (doing a lot more than my MG-35)...

After some over-night thought, I guess my real question isn't the one I asked.

I'm pretty familiar with MMU Linux and have read a fair bit about how uClinux differs. But I'm still not sure about the best approach regards using daemons such as telnetd with BusyBox.

If I launch telnetd, I guess that BB does a vfork and then execs BB again to run the telnetd applet. Will uClinux share the code pages involved (which are loaded from a cramfs) or am I best minimising memory usage by building a separate BB executable that contains only the telnetd applet?

Ditto for the shell that telnetd will launch - build into a single copy of BB or have a separate executable?

Currently, our telnetd and ftpd in Shell-144 use separate executables. In fact, the whole of the official release seems short on soft links and we haven't made things better.

For "cat" a soft link is definitely the way to go.

But I'm not so sure regards deamons. I've risked being noob flamed and have asked this question on the BusyBox list.

Ian

Currently, our telnetd and ftpd in Shell-144 use separate executables.

Gulp, in fact, our "telnetd" is actually a pretty fully-featured BusyBox executable!

------------------------------------------------
BusyBox v1.00-pre3 (2003.11.09-23:26+0000) multi-call binary

Usage: busybox [function] [arguments]...
or: [function] [arguments]...

BusyBox is a multi-call binary that combines many common Unix
utilities into a single executable. Most people will create a
link to busybox for each function they wish to use, and BusyBox
will act like whatever it was invoked as.

Currently defined functions:
[, busybox, cat, cp, dmesg, echo, false, free, insmod, kill, lash,
ls, lsmod, mkdir, mount, mv, ps, rm, rmdir, rmmod, sh, telnetd,
test, true, umount
------------------------------------------------

Here is what is in our actual busybox, which is v0.61.pre

Currently defined functions:
busybox, cat, cp, ifconfig, insmod, ls, lsmod, mount, ping, rmmod,
route, umount

Here is what is in busyb, which is v1.00-rc2

Currently defined functions:
[, awk, basename, busybox, cat, chmod, clear, cmp, cp, cut, date,
df, dirname, dmesg, du, echo, egrep, env, expr, false, fgrep,
find, fold, free, grep, hdparm, head, ifconfig, insmod, kill,
killall, lash, length, ln, ls, lsmod, mkdir, more, mount, mv,
netstat, pidof, ping, printf, ps, pwd, realpath, renice, reset,
rm, rmdir, route, sed, seq, sh, sleep, sort, tail, tee, test,
top, touch, tr, true, umount, uname, uniq, uptime, usleep, vi,
wc, wget, xargs, yes


Having all the separate BusyBox binaries around seems to make no sense - we should just have soft-links to a single binary. Using v1.00-pre3 doesn't seem to make sense either - why not the actual v1.00 or (even better?) v1.20, which I'm already happily building.

So, should I build a single BusyBox with everything in that we need? Any suggestions for what is/isn't required?

Also, the ftpd seems to be pure-ftpd. This is rather large!

How about this one instead?
http://betaftpd.sourceforge.net/index.html

Well could do with pb back as I'm sure he's researched this a little when putting Shell-144 together and seems far more up to speed with the various shells.

Ian

We seem to have eleven copies of BusyBox in the original firmware!

I checked whether this was due to the cramFS unpack/repack by making a version with the soft links. Nope, it all survived.

Whoever made the original image doesn't have a clue!

We should build a new BusyBox with everything we need (including telnetd) and soft link everything.

Ian

Oh, and init and sh are both identical copies of sash.

Anyone know why sash is even needed? Can we just use the busybox shell?

If we soft link /bin/init to /bin/busybox and tell busybox to build in init, then busybox will run /etc/init.d/rcS, which we can just use instead of /etc/sashrc

Or do we think the MediaGate executables/GUI needs some sash functionality that busybox can provide?

Ian

Having all the separate BusyBox binaries around seems to make no sense - we should just have soft-links to a single binary. Using v1.00-pre3 doesn't seem to make sense either - why not the actual v1.00 or (even better?) v1.20, which I'm already happily building.

So, should I build a single BusyBox with everything in that we need?
From my limited understanding having one (larger, all encompassing) copy of busybox with links to the various command names it emulates saves space in the cramfs.

However, every concurrently executing copy of it must occupy ram in its entirety as the entire image is read in when invoked. So... multiple, smaller, more focused copies of busybox will use less ram, but use more space in the cramfs.

As long as enough ram is available to invoke all the commands we use when playing media, it does not matter. We've already had reports of ISO playback being broken in the telnet/ftp versions built by pb. I suspect the MG-35 might not have enough ram to playback those files when the ftpd and telnetd programs are already in memory.

From what I've read, a series of smaller, non-linked processes are better if they all need to be running concurrently. Telnetd and ftpd are probably better if not links to full copies of busybox. Odds are they would then use less ram.

Joe L.

However, every concurrently executing copy of it must occupy ram in its entirety as the entire image is read in when invoked. So... multiple, smaller, more focused copies of busybox will use less ram, but use more space in the cramfs.


That's the way it seems to be, for uClinx anyway.

So, we probably need a separate version of BusyBox for -
init (as it never exits)
telnetd (though I actually suspect BusyBox does something smart in this regard)
lash (invoked from telnetd)

And then one honking big BusyBox for everything else.

We can also get a small ftpd, perhaps the one I mentioned earlier.

Ian

J.L.

never considered the ram situation, makes sense. Can easily be check by just telneting in and checking ram useage after different busybox calls.
I believe ramfree is what it is called , but obviously must be compiled into busybox.

As for another deamon I see being potentially useful could be something like Hypertext Transfer Protocol deamon, but I think we can leave that out till we make better progress. Having Hypertext Transfer Protocol deamon could be useful in the sense that it is useful in XBMC. This way you could use any device that had a webbrowser as the remote to the unit.Think pda. This may be better than the current remote. Definately better if the unit has a hard drive and you want to hide the unit away to remove the noise.

On a similar note has anyone found a compatible external ir reciever for the unit??

I used Hypertext Transfer Protocol deamon as post script yelled at me

As for another deamon I see being potentially useful could be something like Hypertext Transfer Protocol deamon, but I think we can leave that out till we make better progress.

BusyBox has a httpd applet and it even supports CGI. This is what I was guessing we'd use for controlling extra config that people might want.

Ian

As long as enough ram is available to invoke all the commands we use when playing media, it does not matter. We've already had reports of ISO playback being broken in the telnet/ftp versions built by pb. I suspect the MG-35 might not have enough ram to playback those files when the ftpd and telnetd programs are already in memory.
Joe L.

Maybe you could try "top" comand (or via busybox) while ftpd and/or telnetd are loaded. The RSS column shows the total amount of physical memory used by the process, so we can see if it uses the same amount of memory as other busybox processes.

J.L.
never considered the ram situation, makes sense. Can easily be check by just telneting in and checking ram useage after different busybox calls.
I believe ramfree is what it is called , but obviously must be compiled into busybox.
This article http://www.linuxjournal.com/article/7221 has a good description of the memory management used in uClinux.

It is equally important not to "fragment" memory, as the memory for a given process must be contigious. It mentions a /proc/mem_map that shows current memory usage. Anybody ever looked to see if it exists in the MG-35?
On a similar note has anyone found a compatible external ir reciever for the unit??I too am interested in this. It would allow remote mounting of the MG-35 for my bedroom installation.

Joe L.

Maybe you could try "top" comand (or via busybox) while ftpd and/or telnetd are loaded. The RSS column shows the total amount of physical memory used by the process, so we can see if it uses the same amount of memory as other busybox processes.

The RRS column is all zero for the busybox I have here (the one in busyb)

But remember that our telnetd applet is currently in a build of busybox with a whole slew of other stuff in there. This can shrink very easily.

I have a 6 stage plan, and I'll make builds and test as I go -
1) Soft link everything in /bin and /sbin that is BusyBox to BusyBox
2) Build a "fat" BusyBox with all the apps we're likely to need
3) Build a separate BusyBox with just telnetd
4) Try lash for the telnet shell and see what pb meant about some executables not working.
5) Try using BusyBox as init and move the contents of /etc/sashrc to /etc/init.d/rcS
6) See if our memory situation is better with this init as the only app in another BusyBox build

Hopefully, the BusyBox guys will soon answer my questions regards separate applets versus a unified build in the context of uClinux.

Ian

Maybe you could try "top" comand (or via busybox) while ftpd and/or telnetd are loaded. The RSS column shows the total amount of physical memory used by the process, so we can see if it uses the same amount of memory as other busybox processes.Again, from what I understand a program must fit entirely in memory when invoked since there is no "demand paging" available. It cannot read only the pages of code that are "attempted" to be executed. The entire executable is read into memory, not just the parts being executed.

Every image of the same busybox executable must be the same size in ram (soft linked, hard linked, or not), with one possible exception. malloc'd memory affiliated with an instance of a program. Any given process can allocate memory from the free memory pool, but it is effectively "shared" and accessible from any process running. Poorly written programs can easily overwrite other programs in memory. A single process can use up all the available memory or fragment it to where no other process can be invoked.

Joe L.

This article http://www.linuxjournal.com/article/7221 has a good description of the memory management used in uClinux.


Yup, read that one a few times over the last few weeks. :-)


It mentions a /proc/mem_map that shows current memory usage. Anybody ever looked to see if it exists in the MG-35?


Yup, it's in busyb

I've skipped the big map at the top.

init Mem: 104448 Slack: 1623 Shared: 0
dvdplayer.bin Mem: 3472672 Slack: 2909 Shared: 0
telnetd Mem: 411776 Slack: 3565 Shared: 0
ftpd Mem: 354304 Slack: 898 Shared: 0
sh Mem: 141824 Slack: 1600 Shared: 0
cat Mem: 415872 Slack: 1339 Shared: 0
Total Mem: 4900896 Slack: 11934 Shared: 0

Active: 3, inactive: 0, free: 1899
Free pages: 1899 (7596kB), %0 frag, %0 slack
Free blks: 8 min=1 max=1850 avg=237
Used blks: 9 min=1 max=702 avg=201

Ian

Yeah I know busybox has the h.t.t.p.d. in it, just won't really have to mess with it till later.




Busybox is intended to be a compact swiss army knife type of thing. I totally understand the need to run multiple busybox's but I imagine that since there are so many busybox versions in the install size advantage of busybox is probably lost by all the redudant functions.

A hard task maybe to just install individual programs for everything. Obviously you still need to find slimdown version of each function/program you want.

Is it possibly to break apart busybox and take the versions of there functions. So you just take the code for say : top, cat, of whatever else you want. This should free up some ram when things run as only things absolutely needed are ran.

Is it possibly to break apart busybox and take the versions of there functions. So you just take the code for say : top, cat, of whatever else you want. This should free up some ram when things run as only things absolutely needed are ran.

Things like "top" and "cat" don't really matter as they don't run for long. Just run them from a single BB executable.

It's things like init and daemons where we (might) want to get clever.

Generally speaking, BB is pretty lean and mean - there's no need to pull code out. Just use "make menuconfig" and build just what you need.

So saying, I just failed to build BB with just telnetd. uClinux/NOMMU/build issues.

Ian

yeah was wondering if building busy box with just one function worked or not. It has been awhile since I compiled busybox, and have never tried just one function.

I really never learned about how memory issues are handled on a hardware leave. I just know the basics that another instance of busybox is called.

I know cat and top are just a quick little execution but I was wondering if calling even them a simple little execution during current video play back may cause the player to crash or some other error.

I really never learned about how memory issues are handled on a hardware leave. I just know the basics that another instance of busybox is called.


As a result of being involved in a Linux port to a totally new chip, I know far more about this than I'd really like to!


I know cat and top are just a quick little execution but I was wondering if calling even them a simple little execution during current video play back may cause the player to crash or some other error.

I've been doing some pretty gnarly stuff while the box has been playing video. I was even trying some new kernel modules while my Daughter watched some stuff. And I was at work and she was at home!

Ian

Hi, guys!

I updated the wiki using bits and pieces from this forum (up to and including page 42). Please take a look. At least .update and romfs formats need some rewriting, since I found a few (evolving) versions of the information, all collected there. gatgetmind and pbarette are probably the best to know what's there :-)

Also, some bits of info are duplicated in FAQ vs Firmware vs Hardware vs Development pages. My idea is to keep in Faq only the user stuff. I will rethink them again when I'll have the time, for now I only wanted to put together all that we found, in a more usable form .

Hi, guys!

I updated the wiki using bits and pieces from this forum (up to and including page 42). .

@icabrindus

Great work , many Thanks , I know I and many others, are very grateful for your contribution and hard work on this one..

http://www.airlinktek.com/english/atboard.php?param=e_sw

1.45 Im prolly slow but got an email from them today saying its been up since 4th of August (english that is)

My idea is to keep in Faq only the user stuff.

Yes, makes sense, keep up the good work.

Ian

Hmmm, it seems that BusyBox is regularly broken such that daemons such as telnetd don't work on uClinux.

A quick peer at the code in both BusyBox 1.0 and 1.2 suggests that it's broken such that it could never work. I think networking/telnetd.c needs hacking to ifdef on __uclinux__ and use vfork_daemon_rexec in a similar way to klogd (the -n option flags that this time it's for real!)

But it will be easier to get the BusyBox sources from the KiSS guys if anyone is in touch.

This thread discusses it but the patch file doesn't seem to be available.
http://www.gooddvdstuff.com/kissdvd/viewtopic.php?t=1695

A BusyBox with only telnet seems to be about 53k

Ian

Hmmm, it's easier than that. I hadn't sussed the significance of the & on the end of the telnetd line in sashrc - it's the main BusyBox that's doing the vfork and execv to daemonise telnetd!

So, I managed to get my telnet running and only taking 80k versus 402K for the current telnetd. However, mine doesn't seem to exec the shell properly - I don't get a message and nothing new appears in ps when I connect.

Hmmm, no time to track this down.

Ian

Hmmm, I suddenly thought to check if the code in telnetd.c used vfork rather than fork. It sodding well didn't!

Some light hackery and our own telnetd based on BusyBox 1.2 is working. It's taking 86k rather than the 402k of the other version.

If I also build a stripped-down lash we should save even more.

I'm not impressed with the BusyBox code base. :-(

Ian

By the way, I have attached a ZIP containing the new telnetd and the new lash that it seems happy invoking.

The next job is to build a BB that can replace sash. And then get brave enough to build new firmware with all of this in it.

I wish pb was around the explain the issues he had with lash.

Ian

@gadgetmind

1. do you figured out if/how MG35 remaps the memory after the boot?

2. do you think it's possible to build a .upgrade based on stock 1.4.4 and adding only telnetd to it?

If you do that, I and maybe others could try to reflash our "production" MG35 and check some things by myself to add to the wiki. The more eyes, the easier to find more about the device.

Maybe this should be our first milestone: a firmware with minimal changes (to minimize the chance of breaking things), just to be able to login into the device and see what's inside. As we have seen with the ISO image playback, there are always unexpected things that slip through the cracks :)

@all

Don't you think it's time to move the discussion to yahoo groups or elsewhere? Having a single thread for all the hardware/firmware issues is not the best. Also, at least for me, checking the email is easier than checking the forum.

Hmmm, it's easier than that. I hadn't sussed the significance of the & on the end of the telnetd line in sashrc - it's the main BusyBox that's doing the vfork and execv to daemonise telnetd!


If I understand correctly, it's not a daemon, it's just a regular application running in the background. Correct?

guys,

i've chatting with a bunch of russian guys who have been busy hacking EM85xx media devices and have provided me/us with alot of good info.

i was wondering to really get the guys on side and perhaps even port their dvdplayer.bin program to the MG35 if we brought a mg35 for them to 'play' with using the last of the group money ???

they have provided details on the NVRAM (ie store settings), the display and how to use it and the IR module. i've uploaded these files to the yahoo groups area under Utilities

i think it would be worth while as they could advance the hacking of this unit by 2-6 months as they have done alot of it before ...

thoughts/recommendations ????

torquil

guys,

i've chatting with a bunch of russian guys who have been busy hacking EM85xx media devices and have provided me/us with alot of good info.

i

Was/is this their website? , does not seem to be working atm?


http://www.sigmaplayer.ru

hi i just got my second mg-35 the first one could not be seen by any of my pc's this one the same i was just wondering if i do something wrong?

install the software,register the device,etc i've tryed it can not be seen anebodee has any help/ideas i'm very dissapointed i was thinking to send it back and wayt for the mg-350hd............any help would be greately apreciated..........thx

1. do you figured out if/how MG35 remaps the memory after the boot?


I think it's done early in the kernel boot. Why?


2. do you think it's possible to build a .upgrade based on stock 1.4.4 and adding only telnetd to it?


Rather than also adding FTP? Sure, dead easy. But you could also telnet to your Shell-144 firmware, use ps to get the PID of FTPD, kill that PID, and then test ISO functionality. This would suggest whether it's the memory issue that's affecting ISO playback or something else.

I must rip a DVD and have a play!


Maybe this should be our first milestone: a firmware with minimal changes (to minimize the chance of breaking things), just to be able to login into the device and see what's inside.


Well, we kind of have this, but it also runs FTPD. That can be fixed by just editing sashrc and rebuilding the image.

Ian

If I understand correctly, it's not a daemon, it's just a regular application running in the background. Correct?

Yup, spot on, and I wish I'd sussed that earlier! However, 1) telnetd was attempting to daemonise using a non-existent function call, 2) telnetd needs to fork to run the shell and this code wasn't using vfork.

However, the final changes were simple. It was just the working out what to change!

Ian

the forum is at http://forum.sigma-player.org.ru/index.php

i was wondering to really get the guys on side and perhaps even port their dvdplayer.bin program to the MG35 if we brought a mg35 for them to 'play' with using the last of the group money ???


My worry would be whether they would have the time and inclination. Any way to judge this in advance?


they have provided details on the NVRAM (ie store settings), the display and how to use it and the IR module. i've uploaded these files to the yahoo groups area under Utilities


Ah great, NVRAM would be very handy. I'll take a look.

Ian

Maybe this should be our first milestone: a firmware with minimal changes (to minimize the chance of breaking things), just to be able to login into the device and see what's inside.


Here is the root level README of an image I was working on last night. I couldn't test it as my tea arrived. :)

---------------------------------------------------------------------
Gadgetmind Build Shell-144e
Based on pb's Shell-144

Init and SH are still sash
telnetd is also unchanged
BusyBox is a new build with more functions and soft links in /bin and /sbin
busyb has been removed
The launch of FTPD has been commented out in /etc/sashrc

Plans:
The next stage is to use the BusyBox telnetd and get it to launch lash
After this, the current init and sh can be removed and replaced with links to BusyBox
/etc/init.d/rcS has been created in anticiptation of this - please check.

BusyBox:
Currently defined functions:
[, [[, busybox, cat, cp, dd, dmesg, echo, false, hexdump, ifconfig,
insmod, kill, ln, ls, lsmod, mkdir, mknod, mount, mv, ping, ps,
rm, rmdir, rmmod, route, sleep, test, top, true, umount

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

I'll make and check this tonight. If I release it, will someone else be able to test ISO playing?

Ian

guys,

i've chatting with a bunch of russian guys who have been busy hacking EM85xx media devices and have provided me/us with alot of good info.

i was wondering to really get the guys on side and perhaps even port their dvdplayer.bin program to the MG35 if we brought a mg35 for them to 'play' with using the last of the group money ???


torquil

In principle this sounds a good idea - but I dont think we have the resources at this moment..

As of today we have $70.87 USD in the fund , I would have thought sending a MG-35 to RU would cost $99 + $45.00 or so shipping..

For the moment , I think we need to hold on to the $70.00 we have , shold Ian have problems with the JTAG stuff and have to revert back to using a socket for the flash chips - Also, would be nice to keep a few $ in case anyone else "steps up" that needs a serial lead to aid development..

so I am not saying NO by any means , I myself, just dont think its prudent to "clear out" all the funds just at this moment...

Does anyone know what mounts /proc, /hosts and /net?

The mount lines are commented out in sashrc

Does sash handle mounting /proc automatically if non-interactive?
If not, what is currently mounting it?

I've got a very strong suspicion that my shiny new "all BusyBox" firmware isn't going to have a /proc !!!

Ian

Gadgetmind Build Shell-144e
Based on pb's Shell-144


This one worked. I'll throw it on Yahoo is anyone who uses ISOs will volunteer to test it.

I also made versions F and G

F used BusyBox telnet and BusyBox lash. It worked but lash seems to be rather broken - it fails to correctly pass stdin and command line to children. Nothing that needs input seems to work - maybe this is what pb was commenting on?

I have now backed-off F to use BusyBox telnet but still launch sash.

Version G was the one that used BusyBox init, but if I can't replace sash, we might as well use it for init.

I tried building msh and this took the box out when invoked. Should shells really be this hard?

Ian

@ gatgetmind

Regarding the JTAG connector, did you notice there is an area on the right edge of the processor, also marked "D" (just above TP40)?

This one worked. I'll throw it on Yahoo is anyone who uses ISOs will volunteer to test it.

Ian

Ian , as long as you have tested via GUI flashing I will test the ISO bit if you up it the Yahoo group... I use ISO alot due to kids scratching my originals..

@ gatgetmind

Regarding, the JTAG connector, did you notice there is also an area on the right edge of the processor, also marked "D" (just above TP40)?

Yup, we've discussed it before, and (last time I looked!) it was on the wiki.

I'll be wiring to it when I get the time.

Ian

Ian , as long as you have tested via GUI flashing I will test the ISO bit if you up it the Yahoo group... I use ISO alot due to kids scratching my originals..

OK, I have a new version F to test and then I'll make both E and F available on Yahoo. The only difference is that F uses a BusyBox telnetd. Neither runs ftpd.

Probably tomorrow as I need to retest both just to be 100% sure.

Ian

OK, I have a new version F to test and then I'll make both E and F available on Yahoo. The only difference is that F uses a BusyBox telnetd. Neither runs ftpd.

Probably tomorrow as I need to retest both just to be 100% sure.

Ian

Ok , I understand, presume I can now delete the "original" pb shell ?(the one without FTP) I will of cource keep it at the Rapidshare archive..

Whats the latest on The JTAG stuff? , I know you have been busy with this rebuilding , just wondered what you have planned , ref your previous "JTAG" post...

Yup, we've discussed it before, and (last time I looked!) it was on the wiki.


OK, now I finally understand what RHS means :-)

Hi all,

Just a few quick comments as I'm still in the states on business.

First, there are 2 versions of my custom firmware:
#1: Shell-144
#2: PBShell-v1-144

Version #1 was the first attempt to get telnet and ftp working on the MG35. Telnet works, but FTP doesn't. #1 also adds a separate busybox executable that I called "busyb" which increases the size of the firmware image. This firmware version was removed from the yahoo groups files section when I uploaded #2.

Version #2 has several changes. First, there is only 1 copy of busybox and "busyb" has been removed. Almost all busybox functions got replaced with symbolic links. Also, working FTP support was added via the pure-ftpd executable. This version is the current version on the yahoo group. The telnet shell is sash and lash doesn't have a symlink, but can be invoked using "/bin/busybox lash" at which point it functions correctly.

I tried creating a new firmware image that uses "lash" as the default telnet shell, but it didn't work out so well. I can't remember exactly what went wrong, but many executables didn't run correctly. It was probably due to command line parameters as Ian stated, but I don't have my box with me, so I can't be certain. I do know that "mount" was broken, among others, when using lash. However, if telnetd invokes sash, then you manually run lash after login, it works fine and provides a nicer interface for telnet.

Ian... The original firmware does not contain multiple copies of busybox. Instead, the cramfs image uses hard links instead of symlinks. Viewing or extracting the cramfs image with cramfsck doesn't show this very well since the inodes tend to be lost. However, if you mount the image on a linux box, you can see quite clearly that the inodes for the busybox utils are the same. Personally, I think that hardlinks are annoying to keep track of, so I symlinked them all in my firmware v#2.

You should probably download and play with that copy since it looks like you are still using my original, bloated version.

It's possible that the kernel mounts the /proc just as it does the /dev directory. However, /hosts and /net may be done by dvdplayer.bin. Note that dvdplayer.bin is responsible for insmodding khwl.o and fipmodule.o as well as the NDAS modules if NDAS is activated. I'm guessing that NDAS activation/deactivation is also stored in the NVRAM config. That should be easy to find.

With nearly 16MB of RAM to play with, it sounds odd that the ~400k of telnetd would be enough of a memory loss that ISO's refuse to mount. I have a feeling that there's something else going on, but I'm not sure what that is. Possibly the "mount" command in PBShell isn't working in quite the same way as the original firmware. If someone could check ISO functionality between Shell-144 and PBShell, that would also help.

I check commands by running a continuous "ps" loop while executing stuff via the GUI. If you have a script capable telnet program, you can set it to run ps every time it sees the prompt. Then, when you execute stuff via the GUI you can go back to the telnet logs and see the command line that was executed from dvdplayer.bin. Perhaps someone could run a ps loop and try to play an ISO. Then we can see the command line that is executed to mount and play it, and perhaps get an idea about why it is broken.

Finally, the "D" section of the PCB is a bit of a stretch. I hope that you can find a JTAG interface, but if you look closely, you will also see that there is an "E" section as well. There may be an "A", "B" and "C" section, but I can't remember at the moment. It looked to me as though these "Named" sections were just created because there wasn't enough room to silk screen the TP, R, C or L names at the actual solder pads. So these were then grouped together and assigned a group letter so the component names could be printed where there was available space on the board. So while it's possible that "D" is a "debug" section, it is probably just named "D" by coincedence.

pb

re; the russians ... yep, i understand the reasons. just thought to ask as they can help us get along way quickly. perhaps if all goes well we can revisit this in a few weeks and see what people think ....

fyi, these are also the people that gave pb help with the firmware so without them we'd be not very far ....

Is there any convention to specify addresses on ARM? E.g. 0x40000 is better seen as 0004-0000 (I think gatgetmind uses this one) or 0004:0000 (a la i386).

Is there any convention to specify addresses on ARM? E.g. 0x40000 is better seen as 0004-0000 (I think gatgetmind uses this one) or 0004:0000 (a la i386).

I'm not aware of any convention. But as soon as you get beyond four zeros in a row, you really start to need some kind of divider!

Ian

First, there are 2 versions of my custom firmware:
#1: Shell-144
#2: PBShell-v1-144


Bum, I missed this hence my replication of some of what you'd already done. I'll pull the new one down before going any further. However, I am pleased to now be able to spit out custom BusyBox builds, even if lash is somewhat broken. If we do decide that lash is the way to go, I can probably fix it.


Version #2 has several changes. First, there is only 1 copy of busybox and "busyb" has been removed. Almost all busybox functions got replaced with symbolic links. Also, working FTP support was added via the pure-ftpd executable. This version is the current version on the yahoo group. The telnet shell is sash and lash doesn't have a symlink, but can be invoked using "/bin/busybox lash" at which point it functions correctly.


Where did this build of BusyBox come from? My lash when built from source wasn't very impressive and telnetd took some kicking.


Ian... The original firmware does not contain multiple copies of busybox. Instead, the cramfs image uses hard links instead of symlinks. Viewing or extracting the cramfs image with cramfsck doesn't show this very well since the inodes tend to be lost. However, if you mount the image on a linux box, you can see quite clearly that the inodes for the busybox utils are the same. Personally, I think that hardlinks are annoying to keep track of, so I symlinked them all in my firmware v#2.


Hmmm, I specifically looked for hard links, but I guess I got it wrong. Yes, symlinks are much nicer.


It's possible that the kernel mounts the /proc just as it does the /dev directory. However, /hosts and /net may be done by dvdplayer.bin.


Yes, I now think that this is exactly what happens. And as another information point, note that the default environment (including path) is invented by sash when it detects that there isn't one.


With nearly 16MB of RAM to play with, it sounds odd that the ~400k of telnetd would be enough of a memory loss that ISO's refuse to mount. I have a feeling that there's something else going on, but I'm not sure what that is.


Yes, you're probably right. I need to grab an ISO to play with and also look to see what you changed regards mount. It was just a link to BusyBox in Shell-144


Finally, the "D" section of the PCB is a bit of a stretch. I hope that you can find a JTAG interface, but if you look closely, you will also see that there is an "E" section as well.

This seems to be the only one that's just tap points, but you may well be right on this too. But I hope not. :)

Ian

Whats the latest on The JTAG stuff? , I know you have been busy with this rebuilding , just wondered what you have planned , ref your previous "JTAG" post...

I'm currently getting another Linux box setup with openOCD, this time a box with a parallel port! <blush> I then need to drag this down to the office.

I'm getting a bit demoralised regards JTAG for a few reasons -
1) Do we actually need it now? I've done maybe 50 GUI relflashes without any problems, and even when I've made a big mess, recovery via serial works well.
2) A fair bit of surgery will be required to JTAG enable a box. How many people will be prepared to do this?
3) Might I be better figuring out which flash chip is high and which is low, and then trying to create some firmware without a boot section? If I can crash-test-dummy this, then the risk of toasting a box during GUI reflash could be greatly diminished. (I need to know which flash is which so that I can remove them and reprogram them if required.)
4) This is vaguely related to (3), but perhaps holding the processor reset and using an in-circuit TSOP flash programming clip might be a better/easier approach?

I guess I'm really at the stage where there are a fair few paths ahead and I'm trying to decide which one to take.

Ian

Is there any convention to specify addresses on ARM? E.g. 0x40000 is better seen as 0004-0000 (I think gatgetmind uses this one) or 0004:0000 (a la i386).
ARM6 and later processor cores support a linear 32 bit address space, so it should be represented by 32-bit word (0x00000000). There are no segment selectors (like in x86), so no need in xxxx:xxxx convention.
However, 24 bits is enough for the code (instruction) addresses (0x000000).

ARM6 and later processor cores support a linear 32 bit address space, so it should be represented by 32-bit word (0x00000000). There are no segment selectors (like in x86), so no need in xxxx:xxxx convention.
However, 24 bits is enough for the code (instruction) addresses (0x000000).

Greetings!

I still shudder at the memory of segment selectors. I used to do a lot of x86 assembler programming back when there were four segments and all just 64kB. Nasty!

I only threw a dash in on some addresses in the wiki to avoid a confusing sea of zeros. A space is maybe better, or just put up with having to use the cursor to count.

Ian

Version #2 has several changes. First, there is only 1 copy of busybox


I think it's better to have a separate BusyBox with just telnetd in it. I have built one if you want it. I attached it in message 1383. Ignore my lash - it's pants.

I know it's only 256kB, but you then get the same again for your shell.

I'd be very interested in getting the BusyBox sources that you're using. Mine needed mucho telnetd hacking.

If your version is closer to uClinux friendly, then I might be able to suss what's wrong with lash and patch it.

Ian

I think it's better to have a separate BusyBox with just telnetd in it. I have built one if you want it. I attached it in message 1383. Ignore my lash - it's pants.


Hmmm, I've done another build that contains my lash but where telnetd launches sash. Guess what? It works just like yours! It connects using sash, you type "lash", and then have all the lash goodness with no problems. So, it looks like lash was also broken in BusyBox 1.0pre3 :(

It's up to you, but if you grab the telnetd and lash from the zip I posted earlier, then memory usage goes down.

I also notice that your BusyBox is rather large. Do you really need tar, gunzip and zcat? I suggest we decide just those things we want/need and reduce memory footprint. I also think separate BusyBox builds for telnetd and lash make sense, but I accept that the memory savings may not be worth it. Though it's dead easy to do.

BTW, a quick way to check whether it's mount that's causing ISO problems is to make a build with the original BusyBox dropped in as /bin/mount. teddystacker is currently testing another build I made and if this doesn't fix ISOs then I'll try this.

Ian

. teddystacker is currently testing another build I made and if this doesn't fix ISOs then I'll try this.

Ian

Err... Is he? , I would, if I knew where it had been uploaded? , as I dont see it at the Yahoo group?,am I missing something here , or did you just forget to upload it?

Err... Is he? , I would, if I knew where it had been uploaded? , as I dont see it at the Yahoo group?,am I missing something here , or did you just forget to upload it?

I sent email to your hotmail address.

I didn't want to put this version on Yahoo unless it's better regards ISOs (which seems unlikely!)

Ian

umm , not received it there (checked all spam boxes also) , I think the file size would exceed the max that hotmail allows in a single message - bet you will get it back,as soon as their Q sorts it out.

Can you upload right now to the yahoo group? (put in the root of the files section) I will then d/l and then delete it from the group , to avoid confusion until i have tested it..

umm , not received it there (checked all spam boxes also) , I think the file size would exceed the max that hotmail allows in a single message - bet you will get it back,as soon as their Q sorts it out.

Can you upload right now to the yahoo group? (put in the root of the files section) I will then d/l and then delete it from the group , to avoid confusion until i have tested it..

I have just resent the email, let me know how you get on.

Over lunch, I built a new version that I'm now pretty happy with regards neatness and telnetd/shell functionality. No ftpd but there isn't much point in this until we get a rw filing system IMO

My next priorities are JTAG (or whatever) and also sussing how to read and write the config data in the flash. Once we get flash config, people can play with new ideas without needing to relfash.

Ian

Ok, got it , will test as soon as I can get my dear 14 yo daughter off the MG :-)

I'm getting a bit demoralised regards JTAG for a few reasons -
1) Do we actually need it now? I've done maybe 50 GUI relflashes without any problems, and even when I've made a big mess, recovery via serial works well.
2) A fair bit of surgery will be required to JTAG enable a box. How many people will be prepared to do this?



Ummm. Did not realise this was the case,and you are indeed correct , VERY few would want to mod their MG-35 in the way you suggest it would be needed..

So what are your thoughts as to how Al Tech handle a "totally" Bricked MG-35? - You think they would go to the trouble of soldering pins on etc to re flash it? - I was thinking that out of all the 1000's of MG-35's they must have sold in the last year , they must have had quite a few totally bricked ones or I wonder if they just tell be "thats too bad - buy another"

Do you think the only way that the loader could become corrupt during a flash is loss of power or maybe a duff hard disk sector,as its reading in the file? - what happened to PB the first time is kinda strange and worrying at the same time...

I can see you point and I guess its only you guys that would know if its all worth the effort and wgich path to take atm..

Once we get flash config, people can play with new ideas without needing to relfash.


Hmmm, I suspect that dvdplayer.bin hits the flash chips directly to handle config read and write.

We can do the same but bad things will happen if we access the flash at the same time as dvdplayer.bin

The only other complexity comes if the config area is full and in need or an erase, but we can just bomb out for this case. And if we don't need erase, then we probably don't even need to know what kind of flash chip it is.

Ian

So what are your thoughts as to how Al Tech handle a "totally" Bricked MG-35?


Either -
1) Chuck it into landfill
2) Remove the flash chips and fit new ones
3) Use an in-circuit programming clip.


Do you think the only way that the loader could become corrupt during a flash is loss of power or maybe a duff hard disk sector,as its reading in the file? - what happened to PB the first time is kinda strange and worrying at the same time...


They read the whole file to checksum it so bad sectors should be detected. They may also pull it into ram. The real danger time is between erase and the bios reprogram. If an upgrade without a BOOT works then things are much safer.

Ian

Either -
1) Chuck it into landfill
2) Remove the flash chips and fit new ones
3) Use an in-circuit programming clip.
In order to repair a totally bricked MG-35 Al-Tech would first need to determine if it is a hardware or software failure. A unit that did not boot could just as easily have a faulty chip, or solder connection, or a bad power supply. They would need to weigh the time needed to diagnose a faulty board against their cost of popping in a new board. Unless labor costs are VERY low it would cost more to diagnose a bad board vs. replace it.

I'd expect them to try to power up the unit with their own power supply, and if it fails to boot it goes into a big bin destined for recycling. Odds are very low they do any kind of chip level repair. Eventually, if they have an automated test station they might be able to perform a board level diagnostic test, but it is likely that anything other than firmware reflash would not be economical to repair.

Expensive chips might eventually be harvested from the bin of bad boards, but odds are defective boards are just sold for scrap.

Joe L.

.

Expensive chips might eventually be harvested from the bin of bad boards, but odds are defective boards are just sold for scrap.

Joe L.

Thanks for yout thoughts Joe, so do we think the flash chips are pre-programmed and then at production placed in the mb already programmed? , or programmed via serial?

Thanks for yout thoughts Joe, so do we think the flash chips are pre-programmed and then at production placed in the mb already programmed? , or programmed via serial?

To flash via serial i/f, you need to have the bootloader active. So you cannot start with blank chips.

Vasile

Thanks for yout thoughts Joe, so do we think the flash chips are pre-programmed and then at production placed in the mb already programmed? , or programmed via serial?

The flash chips and CPLD have paint dots to let the manufacturer track which are programmed and with what. I believe everything is programmed before being fitted to the board.

Ian

sussing how to read and write the config data in the flash

I have quickly written a cheesy utility that reads the config map from the flash and uses this to work out where the current 1000 byte config block is. It seems to work OK but currently just prints out the addresses.

I can do some experiments at the weekend to try and write to unused flash areas and if this all works maybe pass on the crufty bits to let someone more experienced with C make a config read/write utility.

uClinux makes this stuff a breeze - direct access to memory!

[loads of earlier woffle about being unsure about the exact start of config deleted - going mad as I'd already determined this using a different method]

Ian

Ok, Got rid of the kids at the ice skating rink ... so..

Tested 1.4.4F that Ian sent me today , this DOES NOT play Iso's , as Ian Suspected..

Tested 1.4.4F that Ian sent me today , this DOES NOT play Iso's , as Ian Suspected..

OK, thanks for that. If pb doesn't get onto it first, I'll make a DVD ISO this weekend and do some more experiments.

Ian

OK, thanks for that. If pb doesn't get onto it first, I'll make a DVD ISO this weekend and do some more experiments.

Ian

Best tool to use for ISO creation is "DVD Decryptor" , if you dont have it , I will gladly throw it up at Rapidshare for you...

I'll give my rough NV config read code a quick whirl at work tomorrow lunchtime. I'll get it to write out the 1000 bytes of config to the current directory with an incrementing number showing which config it is. This will work well if you do a smbmount in rw mode.

What's needed is someone to systematically change GUI config settings, run the mg35config utility via telnet, note what you changed and which config was written, and then work out the config structure.

Of course, we might not be interested in every setting, but those we suss will be able to be changed via a web interface.

I suggest we also plan out some additional data to stick on the end. We should be able to then get tgault's remounter to mount the HD or a given SMB share before running a configuration script.

I'll semi-commit to working out how to write the flash if others are willing to lend a hand with the application and reverse engineering.

Ian

Best tool to use for ISO creation is "DVD Decryptor" , if you dont have it , I will gladly throw it up at Rapidshare for you...

I've got it, but haven't used it since migrating that XP install to new hardware. It might need the odd kick ...

Ian

you are a linux person so you may want to try dvdbackup.

I have a debian based system and a quick apt-cache search dvdbackup shows it not sure if you have debian but it works well. Just worth a try. As I know it can be a pain dragging out a windows machine. Anyway there are lot of simple iso backup tools for linux doubt you will have to get a windows machine out.

a more advance program is k9copy

you are a linux person so you may want to try dvdbackup.
I have a debian based system and a quick apt-cache search dvdbackup shows it

Yup, Ubuntu Dapper/Breezy on most machines. But most of these don't have optical media. I'll sort something.

Ian

Yeah I have dapper here. Works fairly well for most things although I prefer the xubuntu variant. I do not need everything to be flashy. Xfce looks nice without being a memory hog. After a reboot memory usage is around 90mb, ram is cheap anymore but why waste it.

Yeah if you have to go to a windows machine for an optical drive anyway not a big deal to just use it. Obviously can use samba to get the files from win then just use mkisofs on linux, but really no reason to do so.

Being that you seem to be production oriented, and have assembly expirence I figure you maybe a person with just a core linux system maybe with X but maybe not and if X have something simple like fluxbox.

Well I guess enough off topic for now. Get back to work :) Really suprised with all the time you have given this process, being you have a family. I appreciate it very much.

What's needed is someone to systematically change GUI config settings, run the mg35config utility via telnet, note what you changed and which config was written, and then work out the config structure.


I can do that, but first I need a firmware version which allows me to telnet without affecting the functionality of the device. Otherwise I would be a dead man :-)

What do you think about repackaging the official firmware, just adding a few commands in the sashrc file, after calling dvdplayer.bin? E.g. mount the harddrive and try to run /dev/hda/firmware/telnetd? If it cannot mount the harddrive or find telnetd, it will work exactly as original, so Family+Wife will never notice anything. This way, we can hack as we want, without reflashing. Just rename telnetd via USB or NDAS, and everything is back to normal for the rest of the family.

Vasile

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 ...


On my Freecom, only xvid files encoded with BVOP set to 2 give playback problems.
I usually re-encode them with xvid and DXN HT PAL profile.

What do you think about repackaging the official firmware, just adding a few commands in the sashrc file, after calling dvdplayer.bin? E.g. mount the harddrive and try to run /dev/hda/firmware/telnetd?

That's an option it might need some extra sleeps to let dvdplayer.bin get the HD mounted to /cdrom. I'll have a go at the weekend - I won't have time until then and I'll need an ISO so I can do some testing.

I was kind of hoping that someone else might have tracked the ISO issue by now. :)

However, I should finish the config dumper this lunchtime and upload it to yahoo. It will need telnet access to the MG35 and also a samba share mounting (to allow writing of config images) But hey, you can always flash back to standard firmware after you've finished playing. :-)

On first glance, it looks like we have a heady 16 bytes free on the end of the config but I'm not sure what's going on at the start of the file.

But I'm hoping someone else will run with this. I'll include source in my mg35config zip file.

Ian

On first glance, it looks like we have a heady 16 bytes free on the end of the config but I'm not sure what's going on at the start of the file.


Of course, we could run our own separate but similar scheme at the end of the flash. But subverting the existing mechanism appeals to me more. :)

Anyway, mg35config is now on Yahoo. Stick this proggy on a read-write samba share, run it from the telnet shell, and it will spit out a numbered config-xxx.bin file. Change the config via the setup GUI, run mg35config again, and you'll get another file.

Assuming your notes are good regards what you changed before creating each file, reverse engineering the config format with a hex editor should be quite easy. There are also config areas for the boot rom. We can map these using the serial console. What we really need is to find some space for our own additions.

Ian

On my Freecom, only xvid files encoded with BVOP set to 2 give playback problems.
I usually re-encode them with xvid and DXN HT PAL profile.

@Znad , thanks for that bit of info , couple of questions..

1)Do you know any tool that allows you to load a movie file in and lets you know if the file is encoded "BVOP 2" , I use "video Inspector" but this does not give you that type of info..

2)What tool are you using for the Re-encode?

Thanks in advance...

The flash chips seem to be in word mode - DQ8-14 certainly seem to be tracked out.

So, the "secret knock" addresses are 0x555 and 0x2AA. As there are two chips, these will need boubling to 0x554 and 0x1555. A quick peek in up upgrader with a hex editor (and remembering little endian) finds both of these values close to each other. So, upgrader hits the flash directly

I can't find anything similar in dvdplayer.bin - do we think it uses upgrader for config writing? I guess I need to use the ps loop trick to find it running while using setup.

Ian

The flash chips seem to be in word mode - DQ8-14 certainly seem to be tracked out.

So, the "secret knock" addresses are 0x555 and 0x2AA. As there are two chips, these will need boubling to 0x554 and 0x1555. A quick peek in up upgrader with a hex editor (and remembering little endian) finds both of these values close to each other. So, upgrader hits the flash directly

I can't find anything similar in dvdplayer.bin - do we think it uses upgrader for config writing? I guess I need to use the ps loop trick to find it running while using setup.

IanOr...
perhaps, after telneting in, mount an SMB share over the existing "upgrader.bin" and substitute your own shell script version for it that saves its arguments in a file somewhere. Then change the config via the MG-35 screen and see if it attempts to use the substitute "upgrader"
(You may need a "compiled" substitute upgrader.bin, depending on how it is invoked instead of a shell script) In any case, if the config does not get written to the flash when your substitute "upgrader" is in place, it will let you know for sure it is involved.

Joe L.

Or...
perhaps, after telneting in, mount an SMB share over the existing "upgrader.bin"


That's pretty much what I did for nbtscan and it worked well. The procedure is now documented on the wiki.


and substitute your own shell script version for it that saves its arguments in a file somewhere. Then change the config via the MG-35 screen and see if it attempts to use the substitute "upgrader"


I'm sure it will, but I'm pretty such that upgrader returns output, as it goes. I'm guessing two way redirection of stdin and stdout, but maybe there are also signals involved.


(You may need a "compiled" substitute upgrader.bin, depending on how it is invoked instead of a shell script)


I'm pretty sure that will be required. I can write this, but not as quickly as someone already up-to-speed with C and Linux vfork/etc. coding.


In any case, if the config does not get written to the flash when your substitute "upgrader" is in place, it will let you know for sure it is involved.


That's a pretty sensible 1st thing to try.

Ian

Following on from your bright idea of replacing updater, I added my own twist of just removing it and seeing what happened.

I already had a MG-35 /bin on my home share, so I did -

mkdir /hosts/home
smbmount //192.168.1.65/home /hosts/home rw
rm /hosts/home/MG-35/bin/updater
mount -o bind /hosts/home/MG-35/bin /bin

I then checked /bin to make sure that updater wasn't there.

The MG-35 setup was very happy to change the configuration and my mg35config program showed the config count going up each time. (I also noticed that my home box has recently wrapped the config count)

I then tried telling my (own, personal, home!) MG-35 to upgrade itself and it hung while displaying the warning to not remove power. I guess this is when it tried to call updater. (Don't worry, the box is OK!)

This strongly suggests that dvdplayer.bin just boogies on the bits directly to write the config rather than going via updater. I guess we do the same - it shouldn't be hard to write. I'll maybe have a go at the raw write_rom_word this weekend.

Ian
edit and P.S. - For "updater" read "upgrader" throughout the above message!

This strongly suggests that dvdplayer.bin just boogies on the bits directly to write the config rather than going via updater. I guess we do the same - it shouldn't be hard to write. I'll maybe have a go at the raw write_rom_word this weekend.

IanIt also very strongly suggests ;) that upgrader.bin is NOT involved when changing the configuration via the MG-35 setup screens.
You sure confirmed that upgrader.bin is involved when processing a ".upgrade" file though :D.

Glad I could help, even if it was only an idea of something to try.

Good luck this weekend.

Joe L.

1)Do you know any tool that allows you to load a movie file in and lets you know if the file is encoded "BVOP 2" , I use "video Inspector" but this does not give you that type of info..

2)What tool are you using for the Re-encode?





1) I use MPEG4MODIFIER. Just load the file and click "Video info", it shows very detailed informations. You can even remove "packed bitstream" from xvid without re-encoding.
It needs NET 1.1 installed.

2) VIRTUALDUBMOD. I usually "fast recompress" the video using xvid, with single pass and DXN HT PAL profile. The mediaplayer doesn't seem to have problems with particular preload and interleaving, so use "direct stream copy" for audio.

It also very strongly suggests ;) that upgrader.bin is NOT involved when changing the configuration via the MG-35 setup screens.


Yeah, that's what I meant but I said "updater" for some reason.


You sure confirmed that upgrader.bin is involved when processing a ".upgrade" file though :D.


Well, I had to give it a go. :)


Good luck this weekend.


Flash writing is actually pretty easy as long as you're doing 1->0. The hard bit is sussing the geometry so you handle erase regions correctly, but I'm not going to do that!

Ian

Hi!

I just found this about KiSS played, I thought maybe it could be useful for the graphics. Hope it's not old news.

The DP-500 implementation of KML has a pixel resolution and aspect ratio identical to NTSC DVD content (720 x 480 pixels @ 4:3 Pixel aspect (4/3)/(720/480) =~ 0.889 ; 16:9 Pixel aspect (16/9)/(720/480) =~ 1.185 ). Both PAL and NTSC systems use the same pixel resolution on this platform; in PAL mode the video buffers are hardware scaled from NTSC resolution to fit the screen (480 becomes 576 visible scanlines)

....

The whole of the screen area can be controlled, including the overscan area. For these products, pixel coordinates begins at 0,0 (top left) and ends at 719,479 (bottom right). Overscan is implemented differently on every TV set, so you have to use very conservative allowances for the content area of the screen

....

The KiSS EM85xx hardware has two video buffers; one for overlay graphics (the OSD � On Screen Display buffer) and one for video/background art (YUV, or video buffer). The OSD buffer consists of a 720x480 pixel 8-bit bitmap spanning the entire scan area of the display. Each pixel may have one of 256 colors. Each of the 256 colors are index-mapped to a set of corresponding RGB 8-bit values and a 4-bit alpha (opacity) value, which is used to control OSD layer pixel transparency (zero alpha allows unobscured see-thru to the video layer beneath). A �blank� OSD buffer is simply filled with color zero, which has 0% alpha opacity, making it effectively invisible.



The default OSD 8-bit palette has all primary and secondary colors with intensity and saturation gradients, as well as a mix of generally useful hues and gradients. Many of the colors exist in semi-transparent versions, and Photoshop color map files and OSD graphics processing macros are available for content developers. OEMs may design their own color palettes. Colors may also be specified as hex triplets (#RRGGBB, web/x-windows style) which are then mapped by the client to the closest matching color index value.

You can see the document at http://dev.kiss-technology.com/kml/kml_doc_03.html

Hi everyone....
I bought a MG-35 yesterday and have not even taken it out of the box yet... but thought I'd google it and see what I could find in the way of mods... and I have to say... you've come a long way......

One comment I would like to make tho... is that it seems rather confusing to have a thread/wiki/file server ect on different sites....

As I would like to help but have absolutely no idea what I would be doing ==> Linux Virgin <==, can I offer you a home to put all of these things in one place??

I can host all of these for you in one place at no cost on my server if you wish.

Just for curiosity, does anyone know how to access the Hynix SDRAM? It's 4 MB and according to what I saw on some diagrams, it is probably used as video memory (both normal image and overlay). At 720*420 resolution, considering 24 bit/pixel (8 bit/colour), we have around 1 MB for the image. Double it for the overlay buffer and add 4bits/pixel for the alpha channel, and we still have only 720*480*(3+3+0.5)=2246400 bytes, meaning 2.14 MB. Do I miss something?

If not, can we use the rest?

@ gatgetmind

Can you please post the output of "cat /proc/mtd" ? Thanks!

Can you please post the output of "cat /proc/mtd" ? Thanks!

Yeah, that's dead easy, it doesn't exist!

The firmware does not currently use MTD and instead uses the very old, very messy, and generally nasty BLKMEM. Take a look at drivers/block/blkmem.c but not on a full stomach!

What's interesting is that the .config files I have seen set kernel blkmem flags to tell it the base of the dword+kernel+cramfs in flash (and incidentally also tend to set incorrect lengths!) but I can't see what in the existing blkmem code would then do an indirection off the pointer to find the start of the arena and thus the cramfs. But they do have an option set to search memory for the cramFS - look for the probe stuff towards the end of the source file.

Ian

it is probably used as video memory (both normal image and overlay)

It will be used for more than that. There seem to be background graphics, OSD graphics (and overlay in front of video) and then the video itself.

A lot of the memory will be used by the MPEG decoder for storing frames and other data that it needs for the decompression. Remember that most video codecs compress by looking backwards (and sometimes forwards) in "time" to find similar data.

Ian

OK, here is where I think I'll go next (back to J.L.'s original suggestion)

We replace upgrader with a script that echos its command line parameters to a file in /hosts and then sleeps for a minute or so.

Via the GUI, we get dvdplayer.bin to kick off an upgrade (which won't work as there is no real upgrader) and cat the options via a telnet session. Hopefully, the command line will be instructions to upgrader for it to perform an erase. I can then turn off the MG-35 before anything gets upset.

We then make a .upgrade file without a BOOT section and run the test again. If upgrader is called with options that don't seek to erase the start of the flash, then I'll have enough confidence to try one for real.

BTW, anyone have a feel for if upgrader is used for the actual programming or just the erase? It seems odd that, 1) There is no progress bar during erase, 2) dvdplayer.bin needs upgrader for the write if it can write flash itself (which it clearly can as it writes the config data)

The real disaster would be dvdplayer writing a different firmware over non-erased flash!

Ian

The command line to upgrader basically passes the entire job over to it.

-f file:///cdrom/Shell-144f.upgrade

Ian

Hmmm, a scan of the strings in upgrader suggests that -
1) It probably can handle just erasing the romfs and not the boot area.
2) It uses lots of GPL code.
3) It uses flex (fast lexical analyzer generator) for some reason!

If someone can create a .upgrade file with no boot section, then I might try calling upgrader directly and seeing what it says.

I can lift the write pins on my flash chips first!

Ian

I just called upgrader from the command line. It did erase the whole chip but had already determined the length of the boot, config (which I guess it loads and then reburns) and romfs. I called it with a normal file and it was successful. Whew!

It does have messages showing just the boot and romfs being erased, which bodes well. Sadly, the trick of lifting chip legs won't work as I've realised this will stop ID and CFI being read out.

However, I can call upgrader from the command line with a ROFS only file, probe the ROM afterwards to check that the boot is still intact, and if it isn't reflash with a good image.

However, upgrader does check the current firmware first. It says it has found firmware 20MX (well, it prints the hex) so maybe with no boot it might refuse to work. :(

Ian

Hmmm, a scan of the strings in upgrader suggests that -
1) It probably can handle just erasing the romfs and not the boot area.It would be nice if true. Further tests will tell.
2) It uses lots of GPL code.Perhaps, when confronted with proof, they will release source for upgrader.bin. (I have been told I am an optimist)
3) It uses flex (fast lexical analyzer generator) for some reason!flex is a parser/tokenizer, able to match strings and invoke functions as appropriate. This is WAY overkill if only being used to match section headers ("BOOT","ROMFS", etc) in the .upgrade image. With only a small number of sections, a series of string compares would have done the job with way less code bloat.
If someone can create a .upgrade file with no boot section, then I might try calling upgrader directly and seeing what it says.

I can lift the write pins on my flash chips first!

IanDisabling the ability to write to the flash is a great idea. I'd wire a switch and an appropriate pull-up/pull-down resistor to make this series of tests less painful. (I seem to remember a data sheet that showed a graph of number-of-remaining-pins vs. number of times a pin is flexed. Don't want to lose a pin or two in the process. We have enough ways to brick a MG-35 without adding another)

Joe L.

Hi Ian,

I lifted both the pure-ftpd server and the telnetd containing busybox from one of the modded KiSS firmwares. I haven't yet attempted to build my own executables from source.

However, upgrader does check the current firmware first. It says it has found firmware 20MX (well, it prints the hex) so maybe with no boot it might refuse to work. :(

This shouldn't be a problem. Remember that a ".upgrade" image contains three headers. First is the firmware header [UPGIMX02] which determines the intended device. Then comes the bootloader section [BOOT]. Finally, the [ROFS] section with the linux kernel and the cramfs image.

So your bootloader free firmware image should contain [UPGIMX02]...[ROFS]...

Basically, delete everything from [BOOT] up to the start of [ROFS]. You will then have the firmware header, version number and the ROFS section.

pb

According to this following excerpt from the flash memory datasheet, you should not simply "lift" the write protect pin. Interesting in that the flash memory has an internal method of protecting potential "boot" code at certain addresses within it. Don't know if this was used by Al Tech, and likely not, but it would have been nice. Perhaps it is how they get away with a full erase of the flash. (It is not actually erasing the config)

Joe L.


Write Protect (WP)
The WP/ACC pin has two useful functions. The one is that certain boot block is protected by the hardware method not to use VID.
The other is that program operation is accelerated to reduce the program time (Refer to Accelerated program Operation Paragraph).
When the WP/ACC pin is asserted at VIL, the device can not perform program and erase operation in the two "outermost" 8K byte
boot blocks independently of whether those blocks were protected or unprotected using the method described in "Block Group protection/
Unprotection".
The write protected blocks can only be read. This is useful method to preserve an important program data.
The two outermost 8K byte boot blocks are the two blocks containing the lowest addresses in a bottom-boot-configured device, or
the two blocks containing the highest addresses in a top-boot-congfigured device.
(K8D1716UT : BA37 and BA38, K8D1716UB : BA0 and BA1)
When the WP/ACC pin is asserted at VIH, the device reverts to whether the two outermost 8K byte boot blocks were last set to be
protected or unprotected. That is, block protection or unprotection for these two blocks depends on whether they were last protected
or unprotected using the method described in "Block Group protection/unprotection".
Recommend that the WP/ACC pin must not be in the state of floating or unconnected, or the device may be led to malfunction.


Joe L.

According to this following excerpt from the flash memory datasheet, you should not simply "lift" the write protect pin.


I was planning on lifting /WE on pin 11.


Interesting in that the flash memory has an internal method of protecting potential "boot" code at certain addresses within it. Don't know if this was used by Al Tech, and likely not, but it would have been nice. Perhaps it is how they get away with a full erase of the flash. (It is not actually erasing the config)


8kB wouldn't even cover the 64+B(ish) boot area never mind the config.

I think they just erase everything and then reprogram. Risky!

Ian

I haven't yet attempted to build my own executables from source.


Ah, right, that makes sense. Anyway, it's good to know that my source built stuff isn't worse than the KiSS stuff. Sort of!


Basically, delete everything from [BOOT] up to the start of [ROFS]. You will then have the firmware header, version number and the ROFS section.


Yes, but my worry is that upgrader will happily burn this in but first have erased the whole flash. I can spot that and run upgrader again via telnet, but the "checking current firmware" might not find a matching signature in the flash and will refuse to touch the .upgrade that would rescue the box.

Ian

It's a Friday, you guys didn't chip in for a development box for nothing, so I decided to stop being a wimp.

1) The MG-35 will happily upgrade from a .upgrade file with no boot section. It only erases the romfs area and the box is none the worse for wear afterwards. It was very pleasing to see it say "Erase romfs" rather than "Erase chip" - it took me at least five minutes after typing the upgrade command to press enter.

2) Running strings on upgrader suggests that there are *three* things that can be in the .upgrade file. BOOT, ROFS and COND. Other strings in the binary and output during a burn from telnet strongly suggest that COND is config data.

The format of the config data is probably -
ASCII "BOOT" (yes, this is what's in memory at 0x20000)
16 bytes of config map. Initialise to 0xFE and then 15 times 0xFF
52 bytes of padding
1000 bytes of config data - use my mg35config tool to get this.

However, I can't see any indication that upgrader will ever just erase the config region. I think a new config would need to go in at the same time as a new boot and rofs.

I have *no* idea why Al Tek ship .upgrade files with boot sections. Madness or do they know something that we don't know?

Ian

Here is what upgrader says when programming with noboot .upgrades. When using normal ones, it says "Erase chip" and boot gets programmed before romfs.

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

/> /bin/upgrader -f file:///cdrom/noboot.upgrade
flash.c [328] cfi_chip_setup: Regions 20002
flash.c [369] cfi_chip_setup: 0031.0032 mfr 00ec id 2275 Top bootsector

flash.c [372] cfi_chip_setup: Swapping erase regions for broken CFI table.

Flash 0 at address 0x00000000
ID : AMD/Fujitsu Standard
Size : 4096 KB
Regions : 2
0 : 0x003e0000 - 0x00004000 * 8
1 : 0x00000000 - 0x00020000 * 31
firmlib.c [29] find_firmware: 0x32304d58 found

main.c [83] ParseOptions: (null)
main.c [46] main: file:///cdrom/noboot.upgrade
main.c [114] ParseFilename: file:///cdrom/noboot.upgrade, file, /cdrom/noboot.upgrade

protolib.c [27] find_protocol: file protocol found

Check firmware
main.c [203] UpgradeFirmware: UPGI: 4
main.c [242] UpgradeFirmware: ROFS: 10
main.c [138] Checksum: checksum : ce730112
main.c [254] UpgradeFirmware: len: 3311625
main.c [266] UpgradeFirmware: conf: 20000. 20000
main.c [267] UpgradeFirmware: boot: 0. 20000
main.c [268] UpgradeFirmware: romfs: 40000. 3a0000
main.c [275] UpgradeFirmware: UPGI[O], COND[O], BOOT[X], ROFS[O] CRC[O]

firmware 1.4.4 -> 1.4.4
Erase romfs
main.c [374] WriteImage: Percent: 33116

Write romfs image 3311625 size to 40000
1%
2%
3%
[snip]
99%
100%
100%
done
------------------------------------------------------------------------------------

I just tried it a second time, this time using the GUI, and it was again totally happy. You get "Erasing Flash ROM" but after this it goes straight to the "Program" progress bar.

Ian

firmlib.c [29] find_firmware: 0x32304d58 found


Notice this bit? That's XM02 after hex to ascii and allowing for little endian. But this is *before* the .upgrade file has been read, so it's found that in the rom. I don't know where.

Ian

I was planning on lifting /WE on pin 11.



8kB wouldn't even cover the 64+B(ish) boot area never mind the config.

I think they just erase everything and then reprogram. Risky!

IanOops... you are right. I did not read far enough. The WP pin seems only to block those 8K regions from being written. Still, the switch/pullup/pulldown resistor idea might be useful on the WE pin,

Joe L.

I have *no* idea why Al Tek ship .upgrade files with boot sections. Madness or do they know something that we don't know?

IanOr, do we know something they don't know. :eek:

Perhaps they have taken development in-house using the Sigma code base as a starting point, but they don't know all the capabilities of upgrader.bin. It could be that a user-bricked unit to most people would be just as dead with or without the bootloader. (as far as we know, there are 2 people with a serial port on their MG-35 in the world outside of Korea, and we are not sure if there are any in Korea. :( )

In any case, great work... gutsy, but eventually someone needed to try it. You could have attempted to recover using the command line upgrader -f file command, so even without JTAG, you had some safety net if it failed, as long as you did not reboot the MG-35.

Joe L.

Ok,let me see if i get this right..

We can now produce firmware updates that dont include the bootloder , so this makes flashing much safer as the bootloder does not get erased in the flash process.So if the flash messes up,we can recover via serial knowing the bootloader always remains in tact?

this does not help us recover a "totally" (knackered bootloader) flash , this would stil have to be done via Jtag, if it exists..

did i get it right?

just a thought ref the Broken ISO function , is it possible that this has anything todo with PB removing /cdrom in his Pbshell firmware?

OK, here is some very early info. on what's in the config data.

Early reverse engineering of config data -
here be dragons
Offset 196 decimal - "CONF" - start of bootloader section?
Offset 208 decimal - IP address - 4 bytes.
Offset 212 decimal - net mask - 4 bytes
Offset 216 decimal - gateway - 4 bytes
Offset 220 decimal - server (tftp?) - 4 bytes
Offset 228 decimal - Name of domain - 24 bytes.
Offset 252 decimal - Name of loader.bin file - 64 bytes.
Offset 316 decimal - TFTP path to romfs - 64 bytes.
Offset 380 decimal - Name of linux.bin file - 64 bytes.
Offset 444 decimal - TFTP path to test kernel+romfs - 64 bytes.
Offset 508 decimal - Start of GUI config data?
here be dragons
Offset 844 decimal - "FINE"
152 times 0xFF

There seems to be lots of room for our own data. We could also subvert some or all of those four strings in the ROM - they are only used by the bootloader and only when doing tftp recovery. Those with serial cables can easily set those strings via that route.

Without a serial cable, we have two ways to write additional config (assuming we want to use this area)
1) Write it directly via some flash writing code.
2) Create a new .config and get upgrader to put this in while flashing in new firmware.

This weekend, I'll try changing something simple (power LED state?) and make sure that the config data doesn't have a checksum. I'm guessing not. If it doesn't, I'll try some direct flash writing.

I'm kind of guessing that being able to configure what the MG-35 does after boot regards running/installing extra bits via HD/samba mounts is quite high on the list of desireables?

I'm thinking that an nbtscan replacement that either does a smbmount (using a config string) or runs the real nbtscan would be rather nice.

We can now produce firmware updates that dont include the bootloder , so this makes flashing much safer as the bootloder does not get erased in the flash process.So if the flash messes up,we can recover via serial knowing the bootloader always remains in tact?


Yup.


this does not help us recover a "totally" (knackered bootloader) flash , this would stil have to be done via Jtag, if it exists..


Right again. We currently have no way of doing this and my gut feeing is that no low-surgery method exists. However, let's see what happens.


just a thought ref the Broken ISO function , is it possible that this has anything todo with PB removing /cdrom in his Pbshell firmware?

Dunno. it seems to have /cdrom and /iso to me.

I'm not sure how this weekend will work out timewise. If pb isn't back and working on this soon, I'll make an ISO and have a crack.

Ian

Just a quick thought about the GUI... from what I have seen, I am guessing that the GUI runs on java.

I have made Macromedia (Adobe) Flash Lite applications before for Phones and, if you make them without any bitmap images and restrict it all to vector based graphics, the file sizes have been rather small (usually <1mb for just a GUI). I am told that the Flash Player can be kept rather small as well when it's ported onto a device.

I don't know exactly how much memory is avaliable in the MG-35 for the GUI or if the processor would be able to handle it, but would it be worth looking into? I might even be able to dig out a copy of the Flash Player SDK....

I have found a case study on the adobe website of a Japaneese company that has intergrated into their IP-STB URL is below for the case study (video, is in Japaneese, but has some nice screenshots of the GUI in action.... they even built in games!!)

adobe com _SLASH_ mobile _SLASH_ customers _SLASH_ cs_video _SLASH_ nttdocomo _SLASH_

Obvoisly, the SG-35 will never be able to handle this type of GUI (pics and all) but it could be worth thinking about, cos with a flashplayer, I don't see why it wouldn't handle a XML feed similar to the news hedlines shown in the video.

Just a quick thought about the GUI... from what I have seen, I am guessing that the GUI runs on java.


I'm pretty sure it uses MicroWindows aka nano-x. The KiSS certainly does (part of their GPL release) and there are nano-x strings in dvdplayer.bin

Ian

This weekend, I'll try changing something simple (power LED state?) and make sure that the config data doesn't have a checksum. I'm guessing not.


The LED state is at offset 172 and there doesn't seem to be a checksum. I'm not at all sure now how this data is partitioned between the loader and the GUI. Maybe it isn't?

Ian

Hmmm, it might not be so easy to program the flash. Remember that some ram is remapped down at zero? The full frontal approach won't work. I wonder how dvdplayer.bin handles it?

There must be a shadow of the flash somewhere. I think I'm going to have to write peek and poke!

Ian

Hi all,

I'm back from my work trip, though I am still pretty busy.

I have fixed the ISO issue, though I'm still not sure what the exact problem is. I have a development firmware in which ISO's are broken. I removed the line in sashrc that starts the ftp server. I also took the MG-35 stock version of busybox, renamed it to mount and replaced the symlink at /bin/mount with that copy.

The result is that I have a firmware image that supports telnet, has the improved GUI from EmuMannen and still plays ISO files.

I have also updated MgCheck.exe to handle ".upgrade" files which do not contain a [BOOT] section. This new copy of MgCheck should now correctly handle MG-25, MG-35 and MG-350 firmware images with or without the bootloader.

It's late here, but sometime tomorrow I will upload these to the yahoo group.

Even if you don't want to help out with the development, the updated GUI is a lot nicer to look at. The only real issue is that the text options in the setup menu are not very easy to see because of contrast issues due to the font color.

@torquil,

You wanted some source code to some of my apps.. If you could PM me again with the apps and your email addr, I'll send them off to you.

pb

I removed the line in sashrc that starts the ftp server. I also took the MG-35 stock version of busybox, renamed it to mount and replaced the symlink at /bin/mount with that copy.

I'd go for the mount being the issue as I removed FTP in a version I sent to teddystacker and it didn't play ISOs.

We really need to try ISOs on one with a new mount and see what error the mount command is giving. I can maybe then find a patch so that we have a unified busybox again.

Or we could not bother as we're not exactly short of flash.

Ian

Hi all,

The new GUI firmware with working telnet and ISO playback has been uploaded to the yahoo group files area.

This firmware image has been created without a [BOOT] section, so it should be extremely safe to load on your MG-35's. I have tested this image on my personal device. It loads correctly and appears to work without issue.

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

I have also uploaded the new MgCheck software. This version calculates checksums and sizes for Mediagate firmware images. It can check and patch firmware images for the MG25, MG35 and the MG350. It will check firmware images with or without the [BOOT] section.

Please note that while the calculations should be correct for MG25 and MG350 firmware images, I don't have either of these devices.

The MG35 calculations and patching should be 100% correct. I use this program myself to check and patch my test images before loading on my device.

Of course, YMMV and it could turn your box into a smoldering brick. That scenario is, of course, highly unlikely. But it's not my fault if it does.

pb

That firmware doesn't work for me. You don't have a /net directory so nbtscan can't do its stuff. The end result is I can't play anything off the network or upgrade via the network.
Ian

pb, how difficult would it be for your checker to handle COND sections? I guess all you need to do is recognise the COND as being a valid section.

I'm musing with writing my own tool for building .upgrades. I'm guessing that Torquil is too busy to write something quickly and dragging the cramFS imgs to windows to generate the checksums is a bit of a pain.

I'm also wanting to experiment with .upgrades containing ONLY a COND section. I get bad feelings about what upgrader will do with these, but if they work then it's an easy route to changing the config.

I hunted for a shadow of the flash this morning but failed to find one. I guess either I missed it or upgrader (and dvdplayer) do some fancy footwork to get around the fact that theres 8kB of RAM stuck over the bottom of the flash.

Anyone got any bright insights?

[later]

Doh! Footnote 8 in the flash datasheet says, "8. A11 - A19 are also don’t care, except for the case of special notice. " so I can go ahead and try writing to the flash!

Ian

Hi Ian,

Oops.. I guess I forgot the net directory entirely. I play most all of my stuff off of the internal HD, so I totally forgot to check that.

I just uploaded a new version with the net dir added back in, so it should work fine now.

Right now, it would be difficult for my checker to handle [COND] sections. I wrote the original before we knew as much as we do now about the structure of the firmware images. As we learned more, I added features to the program to handle more conditions.

The reality is that my simple checksum/sizes calculator is now a bit of a mess since it has to deal with many different conditions that weren't originally anticipated. It also makes some assumptions about header lengths that it shouldn't be making.

I need to go through and rewrite the entire program so it handles the ".upgrade" images section by section in a more orderly fashion. If I do that, it should be able to handle a[COND] section, though I can't guarantee it.

As it currently stands, I have a fairly intimate knowledge of the section headers and how they operate. At the moment, I really know nothing about the [COND] section. Signature bytes, expected length, header fields, etc.

So if you could give me a primer on exactly what you plan to put into the ".upgrade" file for a [COND] section, then it would probably be a lot easier.

Also, I'm sorry you have to keep switching over to windows. I really can't write an OS portable utility since I basically know C# only. This limits my programming abilities to .NET apps.

pb

Hi again,

I have uploaded the current source code for MgCheck to the yahoo groups files area.

As I stated previously, the code is a bit messy due to the various conditions that must be handled. However, I have just gone through the code and added extensive commenting.

pb

Just wanted to pass along that I just flashed with this firmware...Everything appears to be working normally and the new menu graphics are very nice. I was able to telnet into it using Netterm into the Sash directory but because I'm not familiar with Linux I don't know how to access any of my existing directories using linux commands while telnetted...I am using NDAS to play my Music and MP3 files from a Ximeta Netdisk with a 320MB drive (Drive was originally in the MG-35 but I moved it to the Ximeta Netdisk a while back as the Netdisk has the NDAS processor and transfer times are much much faster to the Netdisk using NDAS vs. to the MG-35 using NDAS).
I upgraded to this new firmware across the network from my PC upstairs and all went well...And as far as I can see everything is working and the menu is much nicer...Now if I can just figure out how to use Telnet <G>...


Hi Ian,

I just uploaded a new version with the net dir added back in, so it should work fine now.

pb

Hi Davei1,

I'm confused. You said that you are accessing your files from a Ximeta Netdisk?

Does your Netdisk have SMB server support?
How does the MG-35 recognize the Netdisk?
What specific model of Netdisk do you have?
How is the MG-35 able to access the Netdisk without providing the read key?

Also, I'm glad that the firmware is working correctly for you.

pb

[EDIT]
Ah.. I just realized that you probably just shared the Ximeta disk after attaching it on your PC.. That makes more sense.

Pbarrette,

The Netdisk is a network drive...I connect to it by using the Ximeta NDAS application just like you do when you use an internal drive in the MG-35 and want to connect to it using NDAS...The Netdisk shows up as a local drive on whichever PC (my desktop or notebook) that I have the NDAS application running on (G drive)(Yes it is SHARED)...Then when I startup my MG-35 I connect to the Netdisk to play files by selecting whichever computer the Netdisk is showing up as a local drive (whichever one is running the NDAS application)...Then you just select whatever folders/files in the MG-35 menu)...
Now that you mention it it's probably impossible to use a combination of Telnet and NDAS by telnetting to the MG-35 and then somehow getting to the Netdisk network drive (using NDAS)...


Hi Davei1,

I'm confused. You said that you are accessing your files from a Ximeta Netdisk?

Does your Netdisk have SMB server support?
How does the MG-35 recognize the Netdisk?
What specific model of Netdisk do you have?
How is the MG-35 able to access the Netdisk without providing the read key?

Also, I'm glad that the firmware is working correctly for you.

pb

[EDIT]
Ah.. I just realized that you probably just shared the Ximeta disk after attaching it on your PC.. That makes more sense.

Sorry, I found this pretty late in the game... Do you have an FAQ for the new firmware? Bascially, I was wondering the following:

1. Can I still revert back to the official firmware if I don't like the changes?
2. With the new firmware, has playback support been changed/limited (I mainly need VOB or ISO and Xvid)
3. Do you have pics of the new menu system out yet? I just signed up for the Yahoo groups but didn't see them in the picture area...
4. Is browsing files still text based?
5. I have no coding skills but I am pretty familiar with paypal... if I get a MG-35, where do I donate :D

Thanks a bunch.
-Matt

When I type the mount command telnetted into the MG-35 this is what I see...

> mount
/dev/root on / type cramfs (ro)
none on /dev type devfs (rw)
proc on /proc type proc (rw,nosuid)
ramfs on /hosts type ramfs (rw,nosuid,nodev)
ramfs on /net type ramfs (rw,nosuid,nodev)
ramfs on /usb type ramfs (rw,nosuid,nodev)
none on /net/XPDESKTOP/NetDisk\040(G) type smbfs (ro)
ramfs on /hosts type ramfs (rw,nosuid,nodev)
ramfs on /usb type ramfs (rw,nosuid,nodev)
ramfs on /net type ramfs (rw,nosuid,nodev)
/>

So it does see the G network drive...Is it possible then to mount???


Now that you mention it it's probably impossible to use a combination of Telnet and NDAS by telnetting to the MG-35 and then somehow getting to the Netdisk network drive (using NDAS)...

Found one sorta flaw with the new graphics in the firmware...

If you are in PHOTOS...And you have the Thumbnail preview turned on...
The little graphic of the camera is right over top the thumbnail preview so
you can't see it...The little graphic of the camera should be moved so it's
not over the thumbnail preview...

Hi guys,

Let me do this in order:

@davei1,

You are connecting to your Netdisk from the MG-35 as though it were a standard SMB share. The MG-35 knows nothing about the NDAS of your Ximeta Netdisk.

When you browse the network files from the MG-35's GUI interface, it automatically mounts the various shares in the "/net" folder. So, based on the "mount" list you gave, I'm assuming that your computer name is "XPDESKTOP" and you have shared your Netdisk with a share-name of "Netdisk". You also have a folder in your Netdisk called "040(G)".

For each ComputerName the MG-35 creates a mount point in the "/net" directory. It then mounts the sharename into the computername mount point. By default, the MG-35 GUI mounts the shares as read-only, but you can mount SMB shares as read-write via the telnet session.

Unfortunately, each time you browse the network shares via the GUI, the MG-35 will re-mount the shares. This is why you have multiple, identical "/hosts", "/net" and "/usb" mounts. The MG-35 isn't smart enough to unmount these directories before remounting them.

Here's an EXACT, verbatim session from my box:

Sash command shell (version 1.1.1)
/> smbmount //192.168.1.100/video /mnt -o password username Guest rw
session request to 192.168.1.100 failed
/> mount
/dev/root on / type cramfs (ro)
none on /dev type devfs (rw)
proc on /proc type proc (rw,nosuid)
ramfs on /hosts type ramfs (rw,nosuid,nodev)
ramfs on /usb type ramfs (rw,nosuid,nodev)
/dev/discs/disc0/part1 on /cdrom type ntfs (ro,noatime,nodiratime,nosuid,nodev,u
id=0,gid=0,fmask=0177,dmask=077,nls=default,errors=continue, mft_zone_multiplier=
1)
none on /mnt type smbfs (rw)
/> cd /mnt
/mnt> ls
Movies TV Shows other
/mnt>


Note that the command line states "session request to 192.168.1.100 failed", but the command did complete successfully as a "mount" command shows the share as mounted and an "ls" shows the contents of my share.

I haven't yet figured out how to get the "smbmount" command to accept custom usernames or passwords. So the guest account must still be used until we figure this out. So in the above example, the "password username Guest" bit is EXACTLY as I type it. The command has not been changed to hide any personal username or password I may have.

As far as the new GUI goes.. It was created by EmuMannen and injected into the firmware by me. He is on vacation at the moment, so just compile a list of problems and we'll try to get him to fix them when he comes back.

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

@mpjohnst.

1) Yes. You can always revert back to the old firmware if you don't like the new one.

In fact, the latest firmware image should be MUCH safer to load than the stock firmware. Just be sure that your current firmware is at least 1.4.x as the bootloader for the 1.3.x series seems to be slightly different.

Since the NewGui firmware doesn't erase the bootloader, it should be possible to recover the device even in the case of a power outage during the firmware upgrade.

2) With the latest "NewGui-144a-eng" firmware, playback has not been changed or limited in any way.

Previous changes to the firmware broke ISO support, and one firmware I had up for a couple of hours accidentally broke network playback. This latest firmware should support all of the original file types and playback modes that the original, stock firmware supports. If anything is broken, please let me know so I can figure out what went wrong and how to fix it.

3) There are some test shots of the new GUI somewhere earlier in this thread, but there are no pictures up in the Yahoo groups area.

I should really get on that. Suffice it to say that the new GUI is in exactly the same format as the old GUI. The difference is that the new GUI has a nicer color scheme and the exact images displayed have been made to look a lot better. Functionality, however, is exactly the same as stock. So you could say that the new GUI is basically a new skin for the original GUI.

4) Yes. Browsing files is done exactly the same as the original firmware.

At some point, we hope to be able to completely replace the GUI with our own. At that point, we would hopefully have support for browsing by cover art. However, as stated earlier, the new GUI is really just a new skin.

5) It doesn't take much..

I only code in C#, which means that my programs are basically limited to Windows support utilities and I do not know how to write programs that will run on the MG-35. In addition, my linux skills are fairly limited, yet I think that I've still been able to contribute a lot of knowledge to the project. So what I'm saying is, every little bit helps.

If you do get an MG-35 and wish to contribute to the fund via PayPal, send teddystacker a PM and I'm sure he can give you the details.

pb

OK...Thanks Pbarrette...Thanks makes sense...

I am able to use the ls command to see the directories and folders on the mg-35 but not able to mount the netdisk like you say...The netdisk only shows up in the mount command listing when I access the netdisk with the mg-35 using the remote accessing it through the MG-35 interface...then it shows up in my telnet session...if I don't access it with the MG-35 first then it doesn't show up in the telnet session with the mount command (since I can't mount it that way)...

Here's a dumb question (if you care to answer)...Would it be possible to startup
an FTP server (if one could be small enough) on the MG-35? If so that would certainly make things easy for transfer (for those not proficient with linux commands (like me) )...

Excellent job thus far...

Hi Davei1,

You should be able to mount your remote shares with the following:
smbmount //X.X.X.X/sharename /mnt rw

Where "X.X.X.X" is the IP address of your PC and "sharename" is the name of the share. It will default to anonymous (guest) access. So make sure that you have the guest account enabled and the sharename is listed in the anonymous access security policy (if you use XP).

The sharename can't contain special characters like "$" that Windows uses for hidden shares.

The FTP server is present in the firmware, but has not been activated. To start the FTP server, use the following command.
/bin/pure-ftpd -H -D -M -z &

This should start the FTP server in the background. Since it will be a child of the telnet session, the FTP server will die once you disconnect from telnet.

pb

I've had my MG-35 for months now, and I have been checking this thread several times a day for at least the last month. I, too, know nothing about programming (unless BASIC on an Atari 800XL counts). I understand some about windows networking, but essentially nothing about linux or its variants in any way, shape, or form.

My questions are these (and feel free to talk to me like I'm in 3rd grade):

1) Once I've flashed to the new firmware, how do I start a telnet session with the MG-35 under Windows? (The unit currently has NDAS functionality on my network.)

2) After I start the FTP server via telnet as per pb's instructions in the earlier post, am I correct in assuming that I can connect to it from Windows with the command ftp://xxx.xxx.xxx.xxx and see the MG-35 and its internal HD in an Explorer window with RW functionality? Or is this all way too simple?

Thanks again to everyone for their continuing hard work!

The easiest app to use under windows to access the MG-35 would be something like filezilla, this should give you a nice graphical environment to use.

If you were to connect using the command ftp this wouldn't show up as a rw drive under explorer, only a ro. You could drag stuff off the MG-35 but not add to it.

Hmmm, it might not be so easy to program the flash. Remember that some ram is remapped down at zero? The full frontal approach won't work. I wonder how dvdplayer.bin handles it?
Ian

Hi, Ian

I installed the latest firmware and I can telnet into my MG35 now :)

1. You could be right about the shadow, because the kernel reports only 14MB in kmgs. The missing 2MB could be the shadow you are looking for?
2. did you notice in /proc/iomem that System memory tops to 01e7ffff?
3. take a look at /cat/mem_map. I don't know how to read that map, but could "R" be for ROM? so a part of ROM is remapped at 0x01000000?


Vasile

Hi, all!

For those of you who didn't install the new firmware by pbarettte, in the Wiki I added a page with the contents of most of the files in /proc. It's at http://mediagate.pbwiki.com/ProcMountPoint

Vasile

Tried all variations of below but nothing worked...

smbmount //192.168.1.5/netdisk /mnt rw

The IP number of the Netdisk is correct and the share name is NetDisk...I tried doing just the subfolders like smbmount //192.168.1.5/netdisk/music /mnt rw
but got the same response...

/> smbmount //192.168.1.5/netdisk /mnt rw
error connecting to 192.168.1.5:139 (Invalid argument)
Connection to 192.168.1.5 failed
SMB connection failed
pid 96: failed 256

On the FTP server that starts up just fine per your instructions...I then tried to connect to it with WSFtp and it does connect but I don't know the Username/Password to login? (I looked for it in this forum and the Yahoo group but couldn't find it)...

Hi Davei1,

You should be able to mount your remote shares with the following:
smbmount //X.X.X.X/sharename /mnt rw

Where "X.X.X.X" is the IP address of your PC and "sharename" is the name of the share. It will default to anonymous (guest) access. So make sure that you have the guest account enabled and the sharename is listed in the anonymous access security policy (if you use XP).

The sharename can't contain special characters like "$" that Windows uses for hidden shares.

The FTP server is present in the firmware, but has not been activated. To start the FTP server, use the following command.
/bin/pure-ftpd -H -D -M -z &

This should start the FTP server in the background. Since it will be a child of the telnet session, the FTP server will die once you disconnect from telnet.

pb

The MG-35 is looking quite pretty now, Cheers to every one that has had a hand in getting to this stage. :D

As far as the new GUI goes.. It was created by EmuMannen and injected into the firmware by me. He is on vacation at the moment, so just compile a list of problems and we'll try to get him to fix them when he comes back.


It's already looking very good. However, my wife (ever the critic) did suggest that given all the work I was doing, perhaps the box should be handling more media rather than just looking better. I tried explaining how hard this was, but I'm not sure I got very far!


I do not know how to write programs that will run on the MG-35.


The easiest was is to write in C, test stuff on a an x86 Linux machine, and then cross compile. I had never done any of these things until we started this project and I'm happy to help anyone get up to speed with doing this stuff.

Or I'm happy to do custom builds of BusyBox, kernels, etc. as required.


In addition, my linux skills are fairly limited, yet I think that I've still been able to contribute a lot of knowledge to the project. So what I'm saying is, every little bit helps.


Absolutely! If everyone figures out a small bit of the puzzle it really speeds things up. You've figured out some pretty big bits!


Ian

Hi, Ian

I installed the latest firmware and I can telnet into my MG35 now :)

1. You could be right about the shadow, because the kernel reports only 14MB in kmgs. The missing 2MB could be the shadow you are looking for?
2. did you notice in /proc/iomem that System memory tops to 01e7ffff?
3. take a look at /cat/mem_map. I don't know how to read that map, but could "R" be for ROM? so a part of ROM is remapped at 0x01000000?


I'm guessing at R for Reserved. The top 512kB of memory is reserved for video memory and the bottom meg (ish) for the kernel.

But I'm still hazy on the exact details.

My peek program (which seems to work for ROM) doesn't show the ROM at 0x1000000.

Ian

Tried all variations of below but nothing worked...

smbmount //192.168.1.5/netdisk /mnt rw

The IP number of the Netdisk is correct and the share name is NetDisk...I tried doing just the subfolders like smbmount //192.168.1.5/netdisk/music /mnt rw
but got the same response...


Your command looks right. (BTW, subfolders won't work - if you want to mount a subfolder, you need to mount the main share and then use the bind option to mount - search for "bind" in this thread)

I haven't tried mounting a share to /mnt but it should work, (Maybe try "mkdir /hosts/mnt" and then mount to /hosts/mnt

But the most likely reason for it failing is that the mount command doesn't like your netdisk. Are you sure you have a share called netdisk on that IP address?

Ian

I have been having a look at the kernel supplied from Sigma. I was hoping that xfs was supported with out patching but this doesn't seam to be the case, and the ntfs driver is read only.

Ian can you fix the link to the config files on the developers page, at the moment it links to a picture of a file.

How hard would it be to set up a x86 box to compile a new kernel for the Mg-35.

Nick

Yes...My share is called "Netdisk" in Windows...
When I connect to the Netdisk with the MG-35 it shows as "/net/xpdesktop/netdisk"

No biggie though...Either I'm doing something wrong or it's my Netdisk...I'm
planning on putting the drive back in the MG-35 once I get a 750MB drive for the Netdisk (once they come down in price more)...


Your command looks right. (BTW, subfolders won't work - if you want to mount a subfolder, you need to mount the main share and then use the bind option to mount - search for "bind" in this thread)

I haven't tried mounting a share to /mnt but it should work, (Maybe try "mkdir /hosts/mnt" and then mount to /hosts/mnt

But the most likely reason for it failing is that the mount command doesn't like your netdisk. Are you sure you have a share called netdisk on that IP address?

Ian

Ian can you fix the link to the config files on the developers page, at the moment it links to a picture of a file.


OK, I'll check what went wrong and fix it.


How hard would it be to set up a x86 box to compile a new kernel for the Mg-35.


An x86 Linux box, dead easy. You just need the package called something like build essential, maybe auto tools, and then arm-elf-gcc that I linked to. Probably the best approach is to follow the directions for doing an x86 kernel "make menuconfig" "make dep" and "make" for your box and when that's working move on to the arm version with the Sigma/KiSS sources.

I have built a KiSS kernel and tried it on the MG-35. But Al Tek have some custom code in the kernel and their modules won't work without it.

Ian