iLiad Redistributing Reflash Image

Adam B. · 11-14-2008, 11:18 AM

I've talked to Karel at iRex about our custom firmware poject, and we have an unfortunate piece of news. We will not be able to include the Mobipocket reader, or software keyboard in our firmware release. The problem is that we cannot redistribute these proprietary programs not created by iRex.

While this is a setback, we have a few options. I've asked Karel, if a package can be requested from the IDS containing these files. This way we can distribute the firmware without the files, and have the iLiad connect to the IDS, and download them after the firmware reflash is complete.

The second option may be to run a "pre install" script. This copies the necessary files from internal memory, to the CF card or protected storage area. Then, the reflash is performed and files are automatically copied back after it's complete. We may be able to automate this process if we modify the reflash scripts, but those will have to be flashed before the app.image.

We want the process of installing the community image to be as seamless for the end user as possible. Idealy, it would be good to do it in one step without forcing the user to connect to IDS to get these components.

Thoughts, ideas, suggestions?

jharker · 11-14-2008, 11:28 AM

I like your idea of the "pre install" script the best, especially if we can backup the files to somewhere on the native filesystem. I think this would be the most seamless approach.

In the long run, I think we'll have to work on finding FOSS replacements for those two programs. The keyboard will not be too hard; I think there are already some options out there. Replacing Mobipocket will be harder.

Although... Mobipocket is a Java program, right? So theoretically we could upgrade the Java stuff when we upgrade the kernel, and leave the Mobipocket binary alone, and it would still work, right? So we may never have to worry about replacing Mobipocket, just about replacing the Java underneath it.

Good catch, Adam! I hadn't thought about this problem before.

Adam B. · 11-14-2008, 11:42 AM

Agreed, the keyboard is easy enough, although we will likely loose the handwriting recognition (which I've never really used all that often).

The problem with Mobipocket, is that it needs to be licensed from Mobipocket in order to read DRM'ed ebooks. We can attempt to talk to them, but I doubt it'll be fruitful. I suspect we're going to be stuck with Mobipocket's reader for the foreseeable future.

jharker · 11-14-2008, 12:43 PM

After looking over the boot files posted in the zImage thread, I realized that we may have other issues.

The current initrd and linuxrc script contain, and load, most of the kernel modules. These include buttons, battery, and delta, for which we have the source code. But they also include keystore and sysset (iRex, no source), and tffs (proprietary). Later in the boot process are the pcmcia and usb drivers, whose origins are unknown to me, but iRex only provides binaries for download.

The linuxrc script also calls "imagetodoc", which is a binary, not a shell script.

If and when we eventually update the kernel, some or all of these proprietary modules will need to be recompiled with the new kernel, right? At the very least we'll need the latest tffs, I think.

Am I missing something here?

Adam B. · 11-14-2008, 01:32 PM

Quote:

Originally Posted by jharker

After looking over the boot files posted in the zImage thread, I realized that we may have other issues.

The current initrd and linuxrc script contain, and load, most of the kernel modules. These include buttons, battery, and delta, for which we have the source code. But they also include keystore and sysset (iRex, no source), and tffs (proprietary). Later in the boot process are the pcmcia and usb drivers, whose origins are unknown to me, but iRex only provides binaries for download.

The linuxrc script also calls "imagetodoc", which is a binary, not a shell script.

If and when we eventually update the kernel, some or all of these proprietary modules will need to be recompiled with the new kernel, right? At the very least we'll need the latest tffs, I think.

Am I missing something here?

I'm not sure what keystore does...perhaps encryption with the IDS. Sysset sets hardware configuration parameters and system information. But other than IDS connections and IDS updates, it't not necessary. From what I'm told, there's a new tffs driver in the 2.6 kernel that should work.

Modifying imagetodoc won't be necessary to create custom reflash images, however, it may be an issue if we upgrade to a new kernel, we'll have to see.

hansel · 11-14-2008, 05:37 PM

Quote:

Originally Posted by Adam B.

Agreed, the keyboard is easy enough, although we will likely loose the handwriting recognition (which I've never really used all that often).

http://matchbox-project.org/sources/...ard-0.1.tar.gz compiles without problems. It even has a CTRL and ESC keys. Keys can be configured with xml-files.

It runs on the Iliad and can be used to enter text. Only (minor) issue is display refresh. Can be added, we can use the tricked libX11, or -even better- just wait for Antartica's xepdmgr (hint hint)
a.

I can feel the karma ;-)

Edit: homepage is http://matchbox-project.org/?p=1

jharker · 11-14-2008, 06:02 PM

Fan-fricken-tastic. Not only is that a perfect solution, it's a fast perfect solution. Really well done!

I'd toss you more karma, but I just gave you some and I'm not allowed to.

Antartica · 11-15-2008, 10:32 AM

Quote:

Originally Posted by hansel

It runs on the Iliad and can be used to enter text. Only (minor) issue is display refresh. Can be added, we can use the tricked libX11, or -even better- just wait for Antartica's xepdmgr (hint hint)

When we substitute displayMgr with xepdmgr this would not be a problem. But in the meantime, while we use displayMgr for the iliad OS and only xepdmgr on a app-by-app basis, how should we handle this?

Options:

1. Don't use this keyboard until we change displayMgr with xepdmgr

2. make xepdmgr to ignore the keyboard when launches a program, or to monitor only a command-line specified window (by class for example) -- this last option used for the keyboard

3. Introduce some code in xepdmgr so that if various instances are detected, one of the becomes master and the other waits for the master to die to regain the ability to update the screen.

A while ago I was thinking in the third approach but right now I'm not sure if it is worth the effort: (1) is the easiest X-).

hansel · 11-15-2008, 11:41 AM

4: Add some code to the matchbox-keyboard to optionally send refresh requests to displayMgr.

Antartica · 11-16-2008, 02:14 AM

Quote:

Originally Posted by hansel

4: Add some code to the matchbox-keyboard to optionally send refresh requests to displayMgr.

That would be almost as easy as (1)

My problem is that I don't know an elegant solution to the following scenario:

1. Viewer using xepdmgr as a launcher with the yet-to-be-implemented window exclude to avoid double refreshes to the keyboard
2. keyboard using xepdmgr also as a launcher

There would be clashes.

11-14-2008, 11:18 AM	#1
Adam B. Addicted to Porting Posts: 1,697 Karma: 7194 Join Date: Oct 2006 Location: Indianapolis, IN Device: iRex iLiad, Nokia 770, Samsung i760	Redistributing Reflash Image I've talked to Karel at iRex about our custom firmware poject, and we have an unfortunate piece of news. We will not be able to include the Mobipocket reader, or software keyboard in our firmware release. The problem is that we cannot redistribute these proprietary programs not created by iRex. While this is a setback, we have a few options. I've asked Karel, if a package can be requested from the IDS containing these files. This way we can distribute the firmware without the files, and have the iLiad connect to the IDS, and download them after the firmware reflash is complete. The second option may be to run a "pre install" script. This copies the necessary files from internal memory, to the CF card or protected storage area. Then, the reflash is performed and files are automatically copied back after it's complete. We may be able to automate this process if we modify the reflash scripts, but those will have to be flashed before the app.image. We want the process of installing the community image to be as seamless for the end user as possible. Idealy, it would be good to do it in one step without forcing the user to connect to IDS to get these components. Thoughts, ideas, suggestions?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Reflash 500 to 505 - is it possible	joblack	Sony Reader	1	03-12-2009 04:53 AM
Reflash Problem	jas_williams	iRex	1	11-05-2008 05:29 AM
A few problems after reflash, help appreciated	dso371	iRex	1	09-27-2008 04:23 AM
Reflash question	dso371	iRex	3	03-06-2008 05:28 PM
I need to reflash. Where can I get the image?	tesa	iRex	7	01-17-2008 12:08 PM

11-14-2008, 11:28 AM	#2
jharker Developer Posts: 345 Karma: 3473 Join Date: Apr 2007 Location: Brooklyn, NY, USA Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.	I like your idea of the "pre install" script the best, especially if we can backup the files to somewhere on the native filesystem. I think this would be the most seamless approach. In the long run, I think we'll have to work on finding FOSS replacements for those two programs. The keyboard will not be too hard; I think there are already some options out there. Replacing Mobipocket will be harder. Although... Mobipocket is a Java program, right? So theoretically we could upgrade the Java stuff when we upgrade the kernel, and leave the Mobipocket binary alone, and it would still work, right? So we may never have to worry about replacing Mobipocket, just about replacing the Java underneath it. Good catch, Adam! I hadn't thought about this problem before.

11-14-2008, 11:42 AM	#3
Adam B. Addicted to Porting Posts: 1,697 Karma: 7194 Join Date: Oct 2006 Location: Indianapolis, IN Device: iRex iLiad, Nokia 770, Samsung i760	Agreed, the keyboard is easy enough, although we will likely loose the handwriting recognition (which I've never really used all that often). The problem with Mobipocket, is that it needs to be licensed from Mobipocket in order to read DRM'ed ebooks. We can attempt to talk to them, but I doubt it'll be fruitful. I suspect we're going to be stuck with Mobipocket's reader for the foreseeable future.

11-14-2008, 12:43 PM	#4
jharker Developer Posts: 345 Karma: 3473 Join Date: Apr 2007 Location: Brooklyn, NY, USA Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.	After looking over the boot files posted in the zImage thread, I realized that we may have other issues. The current initrd and linuxrc script contain, and load, most of the kernel modules. These include buttons, battery, and delta, for which we have the source code. But they also include keystore and sysset (iRex, no source), and tffs (proprietary). Later in the boot process are the pcmcia and usb drivers, whose origins are unknown to me, but iRex only provides binaries for download. The linuxrc script also calls "imagetodoc", which is a binary, not a shell script. If and when we eventually update the kernel, some or all of these proprietary modules will need to be recompiled with the new kernel, right? At the very least we'll need the latest tffs, I think. Am I missing something here?

11-14-2008, 06:02 PM	#7
jharker Developer Posts: 345 Karma: 3473 Join Date: Apr 2007 Location: Brooklyn, NY, USA Device: iRex iLiad v1, Blackberry Tour, Kindle DX, iPad.	Fan-fricken-tastic. Not only is that a perfect solution, it's a fast perfect solution. Really well done! I'd toss you more karma, but I just gave you some and I'm not allowed to.

11-15-2008, 11:41 AM	#9
hansel JSR FFD2 Posts: 305 Karma: 1045 Join Date: Aug 2008 Location: Rotterdam, Netherlands, Europe, Sol 3 Device: iliad	4: Add some code to the matchbox-keyboard to optionally send refresh requests to displayMgr.