720degrees Linux for the Jornada 720

People reading this thread and planning to try 720degrees should be hereby advised that errors reported by ProgramSynthesiser are usually due to his active experimentation and development, unless otherwise specified.

The base files with the recommended kernel and modules are stable and do work without any problems for general use... minus X for now.

Edited by snickersmd 2006-02-26 4:28 PM

Yes, I am still trying to get X to compile. I disabled touchscreen as an experiment, it seems that that is where I am getting errors. If that is true, I'll have to figure something out.

EDIT: It continued after the touchscreen was disabled, and now I am getting errors with xcursorgen. It seems to be centered on the fact that my crosscompiler does not have /bin/sh. Lol, that could be a big problem with the crosscompiler.

Edited by ProgramSynthesiser 2006-02-26 5:19 PM

qmail is a full featured MTA, it does not need to connect to a SMTP server. As I said, I'm using it on my Pentium II based server. However, only source package is available at Debian repository. I believe that this is due to license issues, as there are not qmail binaries anywhere; so qmail will have always to be compiled from the same machine where it's going to run. I think that this way helps to get even more performace.

qmail is the MTA used by Yahoo!, Paypal and even MSN Hotmail used it once, when their Exchange servers overloaded and went down, then Microsoft was forced to run them with qmail some time xD

Hahah, that is excellent.

I will compile it and make a deb later, then. Just wait, I am going to port slackware's pkgtool here sometime...

Ok, now I have a real problem. If this base is upgraded to the newest files, when shutting down I get an "INIT: No more processes left in this runtime" error. Well that isn't good, because I cannot shut down properly!

Apparently I missed the submit button earlier, but I found a better source for kdrive.

EDIT: Ok, I saw another issue like this one on a bootstrapped Debian system. It said that the problem was that there were not any /dev/tty files, and creating those fixes it. Sure enough, I don't have any /dev/tty files. At least, not after the upgrade.

Ok, I just checked. Somehow the upgrade deleted them. I have no idea why, or what program did it. But I will restore them. I think we should bootstrap a base with the newest stuff, so this will not be a problem. Users are probably going to upgrade anyways.

EDIT2: Wait, they are there. Ok, this isn't too good.

Ok, this is the post I missed earlier:
Oh, and the source for the kdrive from xfree86's cvs was terrible. It was pointing to header files that did not exist! Essentially, it looks like they are missing files on the cvs, another reason why I do not like cvs. So, I went from their terrible cvs, to freedesktop.org's cvs. (This is all driving me to the brink of insanity)

So, I got their sources, which are kdrive-only! So, instead of dealing with cross compiling 298mb of code, I will copy this nice 15mb of code (2.5 compressed ) to my 720, and compile it on there. That way, it will probably work the first time. And if it doesn't, at least it won't take forever.

Sorry that this is getting long. I looked in the init scripts about the shutdown problem, and the rcS script is almost completely empty. That it probably a hint.

EDIT3: After copying all the init files, nothing improved. Actually, it was better before.

Ok, I have another idea. I will apt sysvinit and the init scripts. But I am not sure that this is related to the scripts anymore.

Edited by ProgramSynthesiser 2006-02-26 11:14 PM

I found instructions and a build script for compiling kdrive, and it was successful.

Now, I just need to find the blasted binaries that it stored...somewhere...

What I don't get yet is... why are we using the testing branch of Debian as default? Testing is being updated frequently with new package versions, and we may have some trouble if some of them are problematic with the Jornada. Wouldn't be more logical to use stable branch that is not anymore updated unless security issues?

Of course, every user can do a upgrade from stable to testing or even have them mixed. For example, at my server I use the stable branch, but I get certain packages from testing (packages that are not on stable or just that I need newer versions).

However and regardless of that, I have to say that 720degrees with testing branch is working like a charm on my Jornada... ^^

Changing topic, it looks like my JLime forum posts asking for help about rebooting to CE have no effect, not even Kristoffer replied, so I think that we will have to continue on our own way. I think that totally clearing the RAM just before the shutdown halting would do the trick, so it would simulate a power failure on the device and boot loader should show us the WinCE setup screen. Ok, we know what to do but... how to do that? We need a good Jornada 720 - ARM coder. Maybe that someone on the development forum can help us?

The person who did the suspend support isnt on the forum at the moment, we dont know where they went. I dont think we do reboot to CE though, i though it just put a restore program into memory, then switched off everything that can be switched off.

Some light into the darkness at the development forum. It looks like it's possible to do a hard reset with software. The example shown is using the WinCE API, but there must be some way to do it directly...

@Chazco: I see... well, let's then find some way around!

Edited by karloch 2006-02-27 2:05 PM

Ah, the quick reply box is convinient for lynx on my 720.
Yes, the testing branch is irritating me. It would be good if we could get apt to NOT configure itself to search for testing binaries by default. Even so, I would like to get to the bottom of this problem, as it will surely bother users in the future. As far as the whole compiling mess, I accidentally set it to compile in x86. So I will have to redo the compile later. Also, I realized something. The terrible XC branch seemed to be more configurable - I could enable touchscreen and such. This branch...I have no idea what is going on. Whatever it is, I will probably have to contact the maintainer for help compiling the stupid thing. For now, I am compiling twin for fun.

We aren't using testing as default. But I have noticed that base-config, when you use it to set up your apt sources.list, puts testing in the repository line instead of stable. I don't know why that is, since I never modified any config files pertaining to this. It is likely an overlooked setting, or a bug.

Now it's true that from time to time we'll run into a Debian ARM package that doesn't work on the Jornada, whether we use sarge, etch, or sid. Obviously, we can't have them change up a package just for our machines, so it's always going to be up to us. We need to be diligent about reporting packages as non-working so other people don't waste time with them, and maybe our team can come up with alternatives. For instance, Debian ARM's dillo 0.85-4 package doesn't work. dillo 0.83-1, from the same repository, does work. And if you really need 0.85, I've found a precompiled binary from the netbook guys that does work. Of course with PS and his microdrive, compiling our own is no longer a problem either.

Soon we'll set up a nice separate forum where we can designate a "package not working" list. While there is no other place that we discuss this, 720degrees testers can post their findings here.

[Double post removed]

Edited by snickersmd 2006-02-27 2:46 PM

I will edit the base-config to fix the problem. For now, I will install each package to be *upgraded* one by one, and shut down after each. As I do not need to reboot for the problem to occur, it should not take too long. Packages that obviously have nothing to do with it will be bypassed.

We probably will not need a bad packages forum.

EDIT: Oh, and I am still having wifi problems, especially when changing ssid's. This seems to be specific to dhclient, and I will replace it with pump. If the problems stop, we have our answer: to include both. For some reason, pump does not work with snickersmd. Personally, I think his router is stupid.

Well here is a great find that no one would get unless if they were following perl files.

In /var/lib/atp/lists, there is the package file from the bootstrap of the system. It is 12mb long, and useless. Yes, snickersmd, time to blush.

Edited by ProgramSynthesiser 2006-02-27 9:04 PM

I think it will be necessary, maybe not a whole forum, but probably a short list. Debian ARM is compiled for a large variety of ARM based machines, not just the Jornada, and there will inevitably be packages that we will not be able to pull from the repository.



If anyone else has had problems with WiFi and this distribution, I'd like to hear from them. I'd like to be able to assess if PS's issues are card related, config related, or distro related, and we'll need more "case reports" to come up with objective findings. Personally I have the following experience with WiFi on my Jornada:

I'm using an Orinoco Classic Gold card with firmware 8.73.

On the Matthis Image, Debian Sarge-testing with pcmcia-cs Woody-stable, pump worked well, automatically resolving dhcp requests as soon as the essid was supplied.

After fixing the Matthis Image to become Sarge-stable, along with pcmcia-cs, pump stopped working completely, and manually invoking pump to configure dhcp would fail. I then switched to dhclient, which worked but not automatically, I had to invoke it manually.

On the 720degrees Image, Sarge-stable pure, with pcmcia-cs Sarge stable, dhclient is supplied automatically by the debootstrap installation. It works but I do have to run it manually after changing essid's. I have not tested pump on this system.

It's important for us to tally WiFi configs that work and that don't work, so we can determine if there is actually a problem with dhclient, its config, pump or its config, or pcmcia-cs and its implementation on the Jornada. My personal theory is that there is something subtle with the pcmcia-cs implementation itself, independent of this distro, simply because I started having problems just after an upgrade and even before 720 degrees was released.

I will also want to retest pump on 720degrees since I haven't yet.

And yes, my router is quirky. It's a Linksys WRT54g version 3 running DD-WRT (Linux-based third party firmware) version 2.3.



Well that is a good catch. I searched the tarball manually with Ark and did try to remove all the unneeded leftover packages, but looks like I missed that. I'll have a look and adjust the release tarball accordingly.

Thanks to snickersmd, it has been pointed out that this is all a stupid error on my part. Even though I have experience with this happening on my distro earlier (yes, I did indeed forget that while troubleshooting), running apt-get upgrade can have major problems. The correct command is to run apt-get dist-upgrade. As far as the weird testing-by-default problem, I did go into the script that creates everything - or at least I think so. I looked through about 50 of them.

For now, if the user only wants stable, they will have to edit the config file by hand. If they are advanced enough to make that decision, they are advanced enough to change a word in a config file.

Perhaps a simple script could be made to replace the word testing/unstable with stable in the future.

EDIT: It could even be set to run after the apt-setup script. By the way, if anyone wants to bypass base-config and get right to setting up apt, that is the command to use.

EDIT2: Ah, it is a linksys.

Edited by ProgramSynthesiser 2006-02-27 10:46 PM