Hi John and others,  (resend)

I started working back in July on updating the Verdex(Pro) project to use the same git oe branch (overo-oe as Steve Sakoman suggested) up to kernel 2.6.30 and made some significant progress with the help of Terry Kemp back then and lately from a lot of playing around with it myself.   I have already resolved all the build issues, patches, tasks, and recipe changes etc.

My preliminary patches to use git and 2.6.30 on Verdex are now available .... I simply need a place to put them so that others can share...

Status ...
I did manage to get the FB, touchscreen, and ethernet (new official linux kernel smsc911x driver) all working (robostix,
and audio are removed for now and left as a future exercise for someone else (perhaps Mr Hylands?) to fix up the
patches/recipes).

Caveat ...
SD card is needed with Verdex Pro for the kernel update (it is too big and risky to shrink into the XM4 flash now).
I am assuming 2GB card, partitioned as 40MB FAT16 (for uboot uImage and script) and remainder as ext3 for the rootfs.
So .. we boot and run from the SD card (mine is a Transcend 2G microSD (SDHC is NOT supported!)).

With these changes and new git build environment (similar to overo),
both the verdex-pro specific console image and palmtop image that result will now work and provide considerably improved performance from 2.6.21 based kernel as well as the benefit of the Angstrom.2008 and OE upgrades.

However, I am still stuck on getting the libertas driver on the Netpro wireless-vx (Compact Flash module version) card working.  Anyone have experience with it?

Biggest breakthrough to get as far as I have was to fix the incorrect GPIO settings for the netpro-vx card (eg GPIO111 is NOT valid to set for this card since it is one of the CS lines for the SD card) that was due to some bug introduced in the revised gumstix.h header files that we inherited from the 2.6.24->26 patches.   Our investigation had identified the GPIO111 issue several months ago and  due  to the GPIO and MFP kernel function changes that enforce that the board specific GPIO alternate function input/output settings should be done up-front in the board specific init file it makes it much easier to track and fix this kind of thing now.

So, the newer kernel also has a better pcmcia infrastructure ...... and the old cfio portion of the old wifistix stuff is now obsolete.  The updated wifi strategy has been to incorporate the official Linux Kernel (2.6.30 and up) Marvell Libertas driver into the project rather than go back to the original old wifistix-modules code that was found in 2.6.21-2.6.26.
There were just too many changes in the kernel to make that old code work, and since overo and some other projects already used the libertas SD card version (instead of the CF) the chances of the libertas_cs working on Verdex-pro ***should*** be good.  But most other projects used libertas SD version not CF.

I followed the libertas (do a google search you will find it) instructions to generate the libertas-cs-helper.fw and libertas_cs.fw files and made bitbake changes to put them in the /lib/firmware folder in the rootfs.   (I have also tried to use the pre-generated latest binaries from git ... same symptom as below).

But alas, I am stuck.....

After bootup (to console prompt for example) ....

I can enable the power to the CF card via

echo GPIO set >> /proc/gpio/GPIO80

Then I can see the CF card identified correctly via

pccardctrl ident

so I think that the
patches for the PCMCIA (and GPIo setup) as well as the co-existence with smsc911x (newer driver for
ethernet which is working) are working more or less correctly in this case.

So the scenario is ....
.... leaving out the autoload of libertas-cs for now ...

Manually do the modprobe.conf changes (see the script from the old wifistix-modules code where this
was also done to bring up the CF card and initialize the old drivers)

pccardctrl eject
pccardctrl

Problem ....

When the udev modprobes the libertas_cs/libertas driver then the
libertas_cs_fw_helper and/or libertas_fw file loading crashes with a Kernel OOPS
cannot allocate virtual memory error

So far, I am not sure if it is due to some MMU conflict in the PXA270 tables or something else.
If anyone needs to see the logs, I will be happy to post them in a follow up....


I have all my patches available to send (or post somewhere if someone can give me a
host web server to upload them to (about 2MB in all, several new patches in user.collection recipes and
override of several task, and conf files).


Regards
Joseph Kortje (Toronto, Canada)
jpktech@rogers.com

John (or Terry Kemp),
Until we get a repositorty set up .... If you want me to send you the patches privately, let me know.
Anyone have a reliable repository/web host server I can send the files to  ????


PS: On first power up for a new image, there is a hang for several minutes on the locale generation and
then a crash/oops.  This doesn't seem to matter to the final image with goes OK to the console logon prompt (and then
I always reboot for clean environment) but I'm wondering  if anyone has a solution!  Does this happen on first boot of a new overo image as well????