Hi.

This was in the programming forum before right here, however there was no reaction from the guys@empeg yet, so I will just go ahead and ask here if anyone has the information I would like to get:
I would like to create my own "upgrade" image (with ftp and telnet installed running while the player is not running and not running when the player is loaded). Furthermore it would really be nice to be able to create an image along with ones "third party" software once it could be released to the public.

Would the guys@empeg be willing to provide the tool(s) and files needed to create the image?

cu,
sven

This was in the programming forum before right here, however there was no reaction from the guys@empeg yet

Actually, there was a reaction from the guys@empeg. Roger said "We may release format specs for the .upgrade file at some point, however."

This leaves us two options:
1) Wait for them to release the specs.
2) Try to reverse-engineer the file format now.

If we went with option 2 and posted what we figured out so far, I'd bet the Empeg folks would give us corrections on it until we had it right.

Personally, I'd love to see the file format. Since it has a section that describes flash updates, we could create upgrade files which contained custom kernels or logos. We could go further than that, even, and include things like custom init scripts.

For instance, RJLov has created a way to select some options for his voladj kernel at bootup time (off/on/amount). The installation of this is tricky and involves uploading a new init script, a new selecter program, and a new kernel. Then you have to do some mucking around at the bash prompt before it will work. Because the bash prompt is required, it means you can only run the option selecter if you have the developer image installed, so you can't do it with the consumer image. But if we had the .upgrade file specs, we'd be able to create an .upgrade file which did all the dirty work for you and it would also work on the consumer image. I like this idea.

___________
Tony Fabris

Unfortunately, it's not this simple;

The disk portion of the upgrade file just un-gzips an image over the entire partition. To make an upgrade file with the player and ftp/telnet/etc on it would require you to be also distributing the empeg player binaries - something which we really don't want to get into as (apart from legal complications) it is a support nightmare - and people could even make malicious upgrade files which toasted your music partition, which would then be applied by people who really shouldn't be playing with a loaded bash prompt ;)

Currently, it's much safer to do the tarball thing.

Hugo

The disk portion of the upgrade file just un-gzips an image over the entire partition.

Oh. Darn. I was hoping you'd designed something more universal- a file format and protocol which allowed more granularity than that. Ah well. Easy come, easy go.

___________
Tony Fabris

The disk portion of the upgrade file just un-gzips an image over the entire partition.

Oh. Darn. I was hoping you'd designed something more universal- a file format and protocol which allowed more granularity than that. Ah well. Easy come, easy go.


Well damn, I guess that pretty much shoots down that idea, for now anyway.

________
Donato
MkII/Blue/40GB/080000565

Well, don't be so hasty. Knowing the .upgrade file format might still prove somewhat useful. Depending on what it will/won't do. If you can choose to do just a flash write in an upgrade file, then it would be a cool way of distributing logos and custom kernels. I know that it's possible to do just a partition replacement (because Mike once made the accident of distributing an upgrade that way), but I don't know if it works the other way around.

If one could know the bare minimum of what bytes are necessary to surround a piece of flash data and stuff into an upgrade file, then I would begin work on a logo editor. I'm kind of keen on this idea. It would allow you to both import images as well as pixel edit them right on the screen. Its output would be a .upgrade file that wrote the logo to memory location A000 in the flash. It would even launch the upgrade file for you if you wanted.

It'd only be for Windows, though, since that's all I know how to code for...

Honestly, I could do it right now and I probably will anyway, using the download.c source, but it'd be so cool to have the output be a .upgrade file if that's possible. (I'd still output a raw binary file so linux folks could copy it over and use download.c to send it.)

___________
Tony Fabris

Go ahead Tony. I would love such a program where one could edit on the screen
then just hit upload and the logo is the Empeg.

I manage to get the logos in there today, but I thinks it is abit messy.

TommyE

That post was abit messy too.

...the logo is on the empeg...

...I think...

TommyE

The design decisions behind the way the upgrade file works was to ease support issues, and to be able to bring a player "back from the dead" as such.

In the future, the upgrade file format could include tarfiles, etc, but this really isn't the way to ensure simple, clean upgrades for normal customers as it forces prerequisites...

Hugo

If you can choose to do just a flash write in an upgrade file, then it would be a cool way of distributing logos and custom kernels. I know that it's possible to do just a partition replacement (because Mike once made the accident of distributing an upgrade that way), but I don't know if it works the other way around.

The button fix was just a flash upgrade, because after I used it, all my files were still intact on the program partition. The next question is if the .upgrade files can write to the logo area.

Yes, they can uprgade any area of flash.

Hugo

Hi.

So from the (mostly valid) arguments I gathered in this thread, it would be real cool to have two things:

1. A documentation of the .upgrade file format that allows the creation of kernel/logo-only upgrades (custom kernels and/or custom logos). This should be fair enough (keeping support requests low for the guys@empeg while allowing the main thing we would need such an image for).


2. An API along with "plugin" specifications that allow installation of third party software on the empeg, with detailed limits as to what areas of the partition these extensions are written to, when they may be started, and how to integrate them with empeg (the player software).

I think the first is clear to everyone reading this (if not: ask). Let me explain the second a bit more:
I think there are basically two types of possible third party extensions to empeg:

1. Plugins for the player (probably input decoders, visuals, ...)


2. "Standalone" software that needs to be executed outside the player (like navigation software, httpd, ...)

For the first type, we need an API to interact with the player in certain ways (get input file, write output wave to D/A the audio output stream, ...), for the second we need an API to access certain parts of the hardware (like serial port (or future extension ports, see other thread about multiple extensions), wave format output, screen output etc). Both might need a way to exchange data during sync, so Palm desktop/hotsync alike conduits should be doable, which means we also need an API/protocol specification on the PC (including Mac) side of the sync.
Anyway, I must say that though documentation is available on how to output to the screen, output wave audio (actually 16bit raw), etc., I think we should implement an API for the empeg hardware that allows easier application development. Furthermore, we should find a way on what a software that is installed on the empeg might or might not do (like writing to disk, file/device locking,...).
As far as a more advanced development environment on the empeg is concerned, we will have to live with tarballs for now, I guess.

Now which forum does this belong in? technical, programming, wishlist? I will leave it here for now.

cu,
sven

Plugins, when the arrive, will not be delivered by upgrade files; the proper place for plugins is on the music partition, with the music.

This way, they can be easily managed by emplode, and can be loaded over all synchronise methods (usb, serial, ethernet) as opposed to just serial. Separate userland programs can also live there too.

As I said before, upgrade files *can't* write to partial partitions, or "update" partitions. They're simply not designed for it.

Hugo