Tip: Affordable LCD terminal

Post by **Maertin** » Wed Jul 23, 2008 2:29 pm

if you are missing wbtwizrd.exe just rename btwizrd.exe in wbtwizrd.exe and presto. mine works like a charm.

Post by **Martin88** » Tue Sep 16, 2008 3:09 pm

Hello MindBender,
Thanks a lot for sharing your knowledge about how to upgrade the eClient!

I've tried quite a couple of days now getting Linux to boot. Following your describtion, my eClient still refuses to boot anything except for Windows CE. I prepared the original CompactFlash 32 mb card with the Grub bootloader and a x86 kernel. I therefore created a primary partition (/dev/sda1), formatted it as ext3 and installed the bootloader in the master boot record. The CompactFlash card actually boots with an older Via mainboard using a CF card reader! For the eClient I changed the bios settings to boot method 'BootSector' and 'Autoconfig LBA'. In this constellation the eClient doesn't even show the Grub menu.
I've played a long time using different bios options to no avail.

Could you please describe more specific how you prepared your CompactFlash card? Perhaps the card must be formatted as superfloppy? Did you use an ext3 or fat filesystem?

Best regards,
Martin

Post by **MindBender** » Tue Sep 16, 2008 10:06 pm

Hi Martin,

Just a quick response, as I am a bit too busy now to verify what might be going wrong.

The first thing that springs to mind is that I found my system not to boot from an Ext3 partition, even though I had properly build Grub. I does boot the Kernel from a FAT partition, but ONLY when the partition has been created by an old Win98 CD I had laying around. I know it sounds strange, but I confirmed it by trying back a forth. The BIOS may depend on legacy CHS parameters in the MBR or something. I created a partition table on the CF card and a FAT formatted primary partition holding the Kernel image and that worked. The RFS was held by a second primary partition on de CF card. I had OpenSuse 10.3 running, except for the frame-buffer. The fb worked fine with the installer Kernel, but not in the installed system

. Unfortunately my SO-DIMM is in use by my laptop server now, but new memory is ordered so it's not a dead project.

Please bear in mind that FAT16 and FAT32 partitions have a minimum size and that FAT12 is ill-advised on non-removable reasons for obvious alignment disadvantages.

You should also check your BIOS settings after your eClient fails to boot from your test card: I have found it to revert to Windows CE boot regulalry after a failed Grub boot.

Good luck and please post your findings. As soon as my new SO-DIMMs have arrived, I will try to reproduce your situation and check out the differences in Win98 fdisk/format and Linux fdisk/mkdosfs.

Post by **MindBender** » Sun Sep 21, 2008 4:45 pm

Today I'm trying to reinstate the OpenSuse eClient, but the first casualties of war have fallen: The SanDisk Extreme III CF card that I quicky borrowed from my camera and the IDE DVD drive died by my goof-up of a too high voltage. Due to the lack of cables on my computer power supply I was using my lab supplies and the cables weren't clearly colour coded. Ironically the cheap-ass test CF card I bought is still ok. But things could have been worse too: Fortunately the 8GiB 266-speed card I usually use for these experiments is still unharmed, and so it the last PC still capable of hosting my ISA National Instruments IEE-488 card. More later today.

Post by **MindBender** » Sun Sep 21, 2008 8:22 pm

If you download this image:
ftp://delien.eu/public/booting.img
and you write it to a 512MiB CF card with a computer running Linux using:
dd if=booting.img of=/dev/sda bs=512
(where '/dev/sda' is your CF card reader) you will have a card your eClient boots a Kernel from using Grub. Loads of things went wrong today and I didn't have time to do a proper install, so it won't find it's Root File System, but you will get a prompt and I think this will get you going.

You need to change two setting in your eClient's BIOS, accessable by pressing the 'Del' key a couple of times after power-up:
1. Change the Boot Method to 'Boot Sector'.
2. Change the PC Card Drive configuration to 'Type 3: Autoconfig, LBA'.
Both settings can be found under 'Basic CMOS configuration'.

Please post your progress!

Post by **Martin88** » Sun Sep 28, 2008 10:23 am

Sorry for my late response! I didn't have much spare time lately.
Thanks a lot for the boot image! I'll try it when my new 512MB card arrives.
Right now I'm limited to a 128MB card. Following your instructions regarding Win98 I'm confident that it will work this time. I'm trying to get the client to boot from a small boot partition first. That should be enough to mount the root file system via nfs.
Thanks again for your great support!

Post by **MindBender** » Sun Sep 28, 2008 11:38 am

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Originally posted by Martin88
 Following your instructions regarding Win98 I'm confident that it will work this time.<hr height="1" noshade id="quote"></blockquote id="quote">I'm sorry, but it won't. I've been experimenting for the last three days and I couldn't get Windows 98, Windows 2000 or Windows XP to work. I can get it installed, but when it's booting, at some time is looses access to its 'harddisk'.

A very useful asset in installing Windows on this platform is a CF to IDE adapter: It allows you to connect a CF card to the IDE interface of any computer it shouldn't cost your more than 8 Euro. Using this adapter, you can install Windows on the card using a regular computer at first. When the installer has copied all basic files and wants to restart for the first time, you switch off the computer and stick the card into the eClient. From there it will continue installing, if you have copied the installed directory from the CD (eg. win98 or i386) onto the card as well.

I tried all of this because I thought it would be easier to get Windows working on this device, but I have switched back to Linux again.

I will try to reduce my images a bit in size today, and I'll share the result with you so you can save yourself a lot of work. I have ordered another 8GB card because my other one is tied up in my TrixBox now, and this size offer me a little more liberty of installing complete distributions.

My major problems when installing Linux are lost interrupts on hdc. I have read a lot on the CS5530 driver, but none of the suggestions helped. But the installer Kernel works flawlessly, so I have seen it is possible for Linux to run on this platform. I'm curious to know the differences between the installer Kernel and the eventual Kernel, but I'm afraid I know too little about this matter: I'm more a bootloader/device driver guy. If you know more, any information will be appreciated.

Post by **MindBender** » Sun Sep 28, 2008 8:16 pm

Here's a disk image of a CF card with GRUB and an OpenSuse 10.3 installer kernel:
ftp://delien.eu/public/OpenSuse.img
It's 32MB in size, made from an original Eizo card so you should be able to write it to your card using:
dd if=OpenSuse.img of=/dev/sdc bs=512
Where /dev/sdc is, of course, the device of my card reader; Yours may be different. Set the boot method in your BIOS to 'Boot Sector' and your card to 'Autoconfig, LBA' and this card image will enable you to install OpenSuse 10.3 from the internet through text-mode menus. If you really want to follow the install procedure, which will eventually fail due to lost interrupts on HDA, you may want to flash this image to a larger CF card to leave some room for the RFS

.

If attach an USB CD-ROM drive with an OpenSuse 10.3 CD in it, the installer Kernel will find it and install from there. As a bonus it will give you the full 1024x768 graphic installer menus.

Now I'm trying to find out the difference between this installer Kernel, which works on the eClient perfectly, and the eventually installed Kernel, which gives the lost interrupts on HDA. Perhaps I have to compile my own Kernel, perhaps with generic IDE drivers, but in this case it would be helpful to know the configuration for the installer Kernel so I can use that as a starting point.

Post by **Martin88** » Mon Sep 29, 2008 10:01 am

Thanks for the 32MB image - it works fine! I'm glad to see Linux on the eClient finally.
I've actually had a CF to IDE adapter laying around but never tried an installation the way you described it. I'm curious what difference exists between the installer partition of the setup routine and a grub installation performed manually. The eClient seems to have a very delicate bios to notice the difference.
Following your recommendations I will stick to the installer kernel for now. Since I'm more familiar with Debian I might experiment with this distribution later. Kernels in Debian normally come with a separate file containing the kernel configuration. So it would be easy to build a kernel on the basis of their installer kernel.
I'm again quite busy at the moment. I will post any significant progress in case I succeed.

Post by **MindBender** » Mon Sep 29, 2008 12:15 pm

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Originally posted by Martin88
 Thanks for the 32MB image - it works fine! I'm glad to see Linux on the eClient finally.<hr height="1" noshade id="quote"></blockquote id="quote">Seeing something actually work (partially) is a good motivation to keep you going.<blockquote id="quote">quote:<hr height="1" noshade id="quote">I'm curious what difference exists between the installer partition of the setup routine and a grub installation performed manually.<hr height="1" noshade id="quote"></blockquote id="quote">I'm not really sure what you mean: Do you mean InitRD, or the actual partition on the CF Card? The partition on the CF Card a FAT16 formatted partition containing the Kernel, InitRD and GRUB. I am more curious about the differences in Kernels and InitRDs than the differences in partitions; I couldn't get anything working with any other format than FAT. I have tried Ext2, Ext3 and NTFS (for Windows), but nothing worked. But that doesn't matter very much because I have found a work-around:

Booting from a FAT16 and FAT32 works, but i chose the first one because FAT32 has a minimum size of about 260MB. Linux installers don't like to install on FAT formatted partitions, not even when it's only a small separate partition mounted at /boot. So I let the installer create a 32MB Ext3 formatted partition with /boot as a mounting point. After installation has completed, I backup the files, mark the partition to be of type 4 (using fdisk), reformat it FAT16 using (mkdosfs -F16), restore the files and reinstall GRUB.<blockquote id="quote">quote:<hr height="1" noshade id="quote">The eClient seems to have a very delicate bios to notice the difference.<hr height="1" noshade id="quote"></blockquote id="quote">That's putting it mildly

. This BIOS works well booting Windows CE, but other scenarios haven't been tested properly. It easily hangs if the configuration doesn't exactly match the hardware and in those cases it's impossible to enter the menu again. In these situations I usually unplug it for a minute or two and it will revert to its default setting from which the menu is accessible again. This usually indicates an empty CMOS battery, but I couldn't find one so it appears they have adjusted the default settings and left the battery out. Does yours show similar behavior? If so, we either have to find out where to connect a battery, alter the default settings or learn to live with it.<blockquote id="quote">quote:<hr height="1" noshade id="quote">Following your recommendations I will stick to the installer kernel for now.<hr height="1" noshade id="quote"></blockquote id="quote">Yes. The Kernel on the 32MB image is an installer Kernel and ditto InitRD. If you let it install OpenSuse, the installed Kernel will no longer work. Not even after reformatting the /boot partition in FAT16 format as described above. So there must be a difference, but I haven't been able to find it yet.<blockquote id="quote">quote:<hr height="1" noshade id="quote">Since I'm more familiar with Debian I might experiment with this distribution later. Kernels in Debian normally come with a separate file containing the kernel configuration. So it would be easy to build a kernel on the basis of their installer kernel.
I'm again quite busy at the moment. I will post any significant progress in case I succeed.<hr height="1" noshade id="quote"></blockquote id="quote">Please do; Any help will be highly appreciated. I don't have any preferences in Distro, as long as it works

Post by **TEN** » Sun Jan 25, 2009 8:11 pm

There are some explanations why updating/replacing the CF card (BTW, no less than 10 screws have to be removed to get at it) may fail.

The only appropriate file available from Eizo seems to be 630ln_276.zip
In it, take this path to another archive (unless you prefer Japanese over American English of course): 630ln_276/Web/USA\630ln276e.zip
Therein lies yet another subdirectory named 630ln276e, finally containing the files with the two longest names as fodder for uneizo.exe:

Code: Select all

ICA_LN_US_45942.bin
nk.bin
RDP_LN_US_0040.bin
readme.pdf

However, besides the bug of unclean termination already documented in this thread, uneizo.exe seems to garble the name of the first file it extracts by omitting the first letter, as can be seen below:

Code: Select all

D:\uneizo ..\RDP_LN_US_0040.bin
Found file: btwizrd.exe, length: 0x1F600
Found file: wbtprnwiz.dll, length: 0x12600
Found file: wbtprncpl.cpl, length: 0xA400
Found file: wbtcpl.cpl, length: 0x44E00
Found file: inetcpl.cpl, length: 0x6400
Found file: wbtsetup.exe, length: 0x1D600
Found file: tsconwiz.exe, length: 0xCC00
Found file: tsconman.exe, length: 0xBA00
Found file: taskman.exe, length: 0xC600
Found file: mstscax.dll, length: 0x80C00
Found file: mstsc.exe, length: 0x39A00
Found file: ssfloat.dll, length: 0x1600
Found file: rdp.inf, length: 0x292
Found file: RasDial.exe, length: 0x11400
Found file: 0040.reg, length: 0xD8
Found file: divide.exe, length: 0x12E00
Found file: FN-153xEvaApp.exe, length: 0x44200
Found file: RegEdit.exe, length: 0x6800
Error: Too long file name encountered

runtime error

In this case, the error won't prevent the system from booting and may easily be rectified by renaming that file to start with an extra "w", but one may not always be that lucky.

After renaming, the RDP setup wizard in all its click-thru EULA glory may still appear (nagging) repeatedly through the next few reboots but should finally disappear as all settings have been saved.

Unlike the older version, this updated RDP client works just fine (in 65k colors) with Windows XP Professional.

One more point to be aware of (especially where using passwords) is that you might need to change the keyboard layout to your locale as the update will have set it back to U.S. "QWERTY".

From the file names seen at the start of this message, it might be that e.g. what becomes 5942.reg in the ICA subdirectory is actually 45942.reg, but I haven't tried yet whether renaming this has any effect.

Having found all of these files, the next step is writing them to a CF card.
Easier said than done, the eClient 630L was unable to boot from 2 out of 2 alternative 32-64MB CF cards, leaving no choice but to overwrite the original Eizo-labelled one.

To err on the side of caution, a bit-level backup seems indicated and dd is the tool for the task, with http://www.chrysocome.net/dd allowing us to stay on Windows for something like (details depending on your card reader):

Code: Select all

dd if=\\.\k: of=d:\630l272e.img --size --progress
rawwrite dd for windows version 0.5.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by the GPL.  See copying.txt for details
32,030,720
62560+0 records in
62560+0 records out

For writing it back in the event everything goes wrong (or to clone the card - which has not worked with any of those I had available), one would inverse the if and of (input and output file - pretty much everything is a file under Unix where this comes from) and add a parameter of BS=1M or similar (the writing block size).

To try and figure out whether there is anything special about the type or organization of the card used by Eizo, state-of-the-art nanoscale photography [;)] has been used to decipher the smallprint on it:

One more thing in desperate need of being hacked ASAP is the web browser's User Agent string, as the WinCE machine will be mistaken for a mobile phone and shown only minimalist versions by major sites such as Google News - suggestions welcome.

Post by **MindBender** » Sun Jan 25, 2009 8:34 pm

It's good to finally see someone taking this a seriously as I did

. I am aware of the sloppyness in the uneizo tool, but it was kind'of a one-trick-pony: It did what it had to do for me, and since there won't be any more updates there's not much use in fine tuning it. Yes, other people need to use it as well becuase I cannot redistribute Eizo proprietary software, but that's the way it has to be.

Anyway; Thanks a lot for the bug report. It seems like an O.B. One. If you like, I can give you the source code, but don't expect too much of it. Check out the Eizo file with your favorite hex editor and I'm sure you're able to write your own Uneizo pretty quickly.

Even though I have though the same thing for a long time, I have to disagree with you on the CF-card: I can make any CF card work in my eClient. It's some time ago since I worked on this project, so I don't have everything clear right now, but I recall any card working fine after partitioning it using the Window 98 installer. I think it's related to the CHS parameter written in the MBR of the CF card. It is accessed like an LBA device, but somehow the CHS values seem to matter. I'm using GRUB to get it to boot Linux for a 8GiB CF card.

Another surprise is that the eClient is able to work with a 512MB DIMM. I haven't tried bigger ones becuase they are pretty hard to get these days.

Post by **TEN** » Sun Jan 25, 2009 9:07 pm

Thanks for the swift reply, and kudos for providing the tools to do the trick in the first place! [:)]

For me, even bit-by-bit copies of the original CF card to any other CF cards of an identical or larger size (albeit manufactured some 3 years later) would not work - according to your post of course they might after changing the settings in the somewhat hard to reach BIOS setup.

It's good News to hear you did get Linux to work (the thread had reflected this only up to the point of running the OpenSuse.img installer) - in particular with 512MB (some sort of SO-DIMM I presume), even Eee-era incarnations like Easy Peasy ("netbook Ubuntu") might be able to (be made) run - especially interesting for touchscreen versions and even attempts at starship erm... home improvement by the trekkily inclined. [:D]

Post by **TEN** » Mon Jan 26, 2009 12:45 am

While we're at it:
Does anyone know a WiFi/WLAN card to work in the eClients' PCMCIA slot?

Post by **MindBender** » Mon Jan 26, 2009 1:14 am

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Originally posted by TEN
For me, even bit-by-bit copies of the original CF card to any other CF cards of an identical or larger size (albeit manufactured some 3 years later) would not work - according to your post of course they might after changing the settings in the somewhat hard to reach BIOS setup.<hr height="1" noshade id="quote"></blockquote id="quote">
That's because some, mostly older, card do not support LBA mode. However, using the proper CHS parameters in the MBR or the card will make any card work. Of course parameters of one card are not per definition compatible with another card, not even if their sizes are identical.
<blockquote id="quote">quote:<hr height="1" noshade id="quote">It's good News to hear you did get Linux to work (the thread had reflected this only up to the point of running the OpenSuse.img installer) - in particular with 512MB (some sort of SO-DIMM I presume), even Eee-era incarnations like Easy Peasy ("netbook Ubuntu") might be able to (be made) run - especially interesting for touchscreen versions and even attempts at starship erm... home improvement by the trekkily inclined. [:D]
<hr height="1" noshade id="quote"></blockquote id="quote">
'Working' as in 'single user mode'. Somehow the IDE problems have disappeared, but I got X-problem for it in return

. Unfortunately I cannot give this project the attention it needs right now.