Linux on Compaq EVO T20

On Tue, 11 Nov 2008, Frank Boehm wrote:

Hello,

> Did anyone notice, thanks to a newer grub4dos we can boot our linux kernel
> now directly from a ntfs partition.

as a proof of concept I put a working example online:
http://www.baldar.de/pub/Compaq_Evo_T20/bootp.bin_grub4dos.gz.md5
http://www.baldar.de/pub/Compaq_Evo_T20/bootp.bin_grub4dos.gz

this firmware will boot my usbstick image
I think this image will work for every Evo >= 16MB Flash
reduced the original size of my 64mb harddisk image

want to make your own changes?

if you are in a subdirectory of a working bundle-tools,
download my image, unpack and verify

bundle-tools/y_grub4dos > ../fwextract bootp.bin_grub4dos list
This seems to be a NetXfer image, skipping the NetXfer bootstrap.
Offset    Size      Checksum  SysFlg  BiosFlag  Time      Filename
0000012c  00040000  061b3e1a  010000  00010000  45eda342  ulc_code.ce
0004012c  00000014  fdf207f8  010000  00020000  45eda34c  k
00040140  00040000  8166c7a0  010000  00020000  45eda342  ulc_code.bin
00080140  00000005  cacae1ac  010000  00020000  45eda350  os.ver
00080148  0000338c  dc683537  010000  00020000  45ed20b8  poweron.bmp
000834d4  00d00000  4c63981f  010000  00020000  4919d749  filesys0.img


../fwextract bootp.bin_grub4dos extract
mkdir loop
losetup -f
losetup -o 512 /dev/loop0 filesys0.img
ntfs-3g /dev/loop0 loop

make your changes, lower timeout value in boot.ini and menu.lst, other kernel
note: there is no legacy usb keyboard emulation on the evo, 
only the default kernel will boot

umount loop
losetup -d /dev/loop0
../fwpack pre_bootp.bin ulc_code.ce k ulc_code.bin os.ver poweron.bmp filesys0.img && \
cat ../netxfer.bootstrap pre_bootp.bin > bootp.bin

have fun,
cu Frank

-- 
I love mankind ... It's people I hate.
                 -- Schulz

On Wed, 12 Nov 2008, Frank Boehm wrote:

> On Tue, 11 Nov 2008, Frank Boehm wrote:
>
> Hello,
>
>> Did anyone notice, thanks to a newer grub4dos we can boot our linux kernel
>> now directly from a ntfs partition.
>
> as a proof of concept I put a working example online:
> http://www.baldar.de/pub/Compaq_Evo_T20/bootp.bin_grub4dos.gz.md5
> http://www.baldar.de/pub/Compaq_Evo_T20/bootp.bin_grub4dos.gz
>
> this firmware will boot my usbstick image
> I think this image will work for every Evo >= 16MB Flash
> reduced the original size of my 64mb harddisk image
>
> want to make your own changes?
>
> if you are in a subdirectory of a working bundle-tools,
> download my image, unpack and verify

you don't even need bundletools any more,
just mount the ntfs partition direct, rest is the same

> ../fwextract bootp.bin_grub4dos extract
> mkdir loop
> losetup -f
> losetup -o 512 /dev/loop0 filesys0.img
> ntfs-3g /dev/loop0 loop

the offset for the start of the ntfs image inside of my 
bootp.bin_grub4dos firmware:

losetup -o 833748 /dev/loop0 bootp.bin

if you can find the start for the ntfs offset in an original firmware
you can make your own one


have fun,
cu Frank

-- 
Don't talk to me about gold plates - 
if you can see what the plate is made of the portions are too small.
  -- Nanny Ogg's Cookbook

Frank Boehm wrote:
> On Tue, 11 Nov 2008, Frank Boehm wrote:
>
> Hello,
>
>   
>> Did anyone notice, thanks to a newer grub4dos we can boot our linux kernel
>> now directly from a ntfs partition.
>>     
>
> as a proof of concept I put a working example online:
> http://www.baldar.de/pub/Compaq_Evo_T20/bootp.bin_grub4dos.gz.md5
> http://www.baldar.de/pub/Compaq_Evo_T20/bootp.bin_grub4dos.gz
>   
Could you also upload your testing DOS firmware/memdisk image please?

Important note about T20 HDD image:
I thought it has fixed CHS geometry but this is not true.
BIOS dynamically adjust CHS according to image (not sure
if it looks in partition or bootsector BPB).
So I made new image with CHS=140/16/32 and no problem.
Also NTFS partition type (07h) is not needed.
I use FAT16 and it can load NTLD+GRUB+Linux kernel as
well as your NTFS image. Maybe mkdosfs (or such tool)
is buggy, I formated and partitioned image under BOCHS.


But still no success with booting FreeDOS kernel :(,
crashing after INIDISK...

I got FreeDOS to run via RAM disk image boot up via DOS-GRUB *BUT* I
couldn't get keyboard to work, USB ONLY! And it appears that the init of
the USB devices is incomplete....

RayeR wrote:
> Important note about T20 HDD image:
> I thought it has fixed CHS geometry but this is not true.
> BIOS dynamically adjust CHS according to image (not sure
> if it looks in partition or bootsector BPB).
> So I made new image with CHS=140/16/32 and no problem.
> Also NTFS partition type (07h) is not needed.
> I use FAT16 and it can load NTLD+GRUB+Linux kernel as
> well as your NTFS image. Maybe mkdosfs (or such tool)
> is buggy, I formated and partitioned image under BOCHS.
>
>
> But still no success with booting FreeDOS kernel :(,
> crashing after INIDISK...
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> open-evot20-discuss mailing list
> open-evot20-discuss@...
> https://lists.sourceforge.net/lists/listinfo/open-evot20-discuss
>

And what ramdisk? I also tried it via latest memdisk, it successfully loaded
hdd image to ram but then didn't boot it. I know about usb kb problem,
maybe author of dosusb could help with it. I have only some dos usb
mouse drivers and mass storage drivers.

Michael Joyner wrote:
> I got FreeDOS to run via RAM disk image boot up via DOS-GRUB *BUT* I
> couldn't get keyboard to work, USB ONLY! And it appears that the init of
> the USB devices is incomplete....
>

I had to set the boot options to a specific unremembered combination about
it not doing something with HD probes or something.

On Sat, Nov 29, 2008 at 8:08 PM, RayeR <rayer@...> wrote:

> And what ramdisk? I also tried it via latest memdisk, it successfully
> loaded
> hdd image to ram but then didn't boot it. I know about usb kb problem,
> maybe author of dosusb could help with it. I have only some dos usb
> mouse drivers and mass storage drivers.
>
> Michael Joyner wrote:
> > I got FreeDOS to run via RAM disk image boot up via DOS-GRUB *BUT* I
> > couldn't get keyboard to work, USB ONLY! And it appears that the init of
> > the USB devices is incomplete....
> >
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> open-evot20-discuss mailing list
> open-evot20-discuss@...
> https://lists.sourceforge.net/lists/listinfo/open-evot20-discuss
>

Yesterday night I spent with messing with FD kerner 2038cvs sources,
I enabled debug output to see whats happening, I fixed some bugs
in printing and total sectors calculation and the most important I had
to hardcode nUnits = 3 in initdisk.c because it accidentally rised to 551 -
I have no idea why but then it works!

http://rayer.ic.cz/350d/fdboot.gif

I'm in contact with Eric Auer so I hope he give me some explanation
and fix it much better.
So now comes up the solving of user input problem, some USB HID driver
or to try different interface+driver.

Michael Joyner wrote:
> I had to set the boot options to a specific unremembered combination 
> about it not doing something with HD probes or something.
>
> On Sat, Nov 29, 2008 at 8:08 PM, RayeR <rayer@... 
> <mailto:rayer@...>> wrote:
>
>     And what ramdisk? I also tried it via latest memdisk, it
>     successfully loaded
>     hdd image to ram but then didn't boot it. I know about usb kb problem,
>     maybe author of dosusb could help with it. I have only some dos usb
>     mouse drivers and mass storage drivers.
>
>     Michael Joyner wrote:
>     > I got FreeDOS to run via RAM disk image boot up via DOS-GRUB *BUT* I
>     > couldn't get keyboard to work, USB ONLY! And it appears that the
>     init of
>     > the USB devices is incomplete....
>     >
>
>
>     -------------------------------------------------------------------------
>     This SF.Net email is sponsored by the Moblin Your Move Developer's
>     challenge
>     Build the coolest Linux based applications with Moblin SDK & win
>     great prizes
>     Grand prize is a trip for two to an Open Source event anywhere in
>     the world
>     http://moblin-contest.org/redirect.php?banner_id=100&url=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     _______________________________________________
>     open-evot20-discuss mailing list
>     open-evot20-discuss@...
>     <mailto:open-evot20-discuss@...>
>     https://lists.sourceforge.net/lists/listinfo/open-evot20-discuss
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> open-evot20-discuss mailing list
> open-evot20-discuss@...
> https://lists.sourceforge.net/lists/listinfo/open-evot20-discuss
>

I made final patching of FD kernel, now it's fully working on T20.
(issue with nUnits was caused by compiler didn't initialized it).
So that sucking USB will be challenge.
I'll try to make simple english webpage on my homesite about T20
and uplad some files there...

RayeR wrote:
> Yesterday night I spent with messing with FD kerner 2038cvs sources,
> I enabled debug output to see whats happening, I fixed some bugs
> in printing and total sectors calculation and the most important I had
> to hardcode nUnits = 3 in initdisk.c because it accidentally rised to 
> 551 -
> I have no idea why but then it works!
>
> http://rayer.ic.cz/350d/fdboot.gif
>
> I'm in contact with Eric Auer so I hope he give me some explanation
> and fix it much better.
> So now comes up the solving of user input problem, some USB HID driver
> or to try different interface+driver.
>
> Michael Joyner wrote:
>> I had to set the boot options to a specific unremembered combination 
>> about it not doing something with HD probes or something.
>>
>> On Sat, Nov 29, 2008 at 8:08 PM, RayeR <rayer@... 
>> <mailto:rayer@...>> wrote:
>>
>>     And what ramdisk? I also tried it via latest memdisk, it
>>     successfully loaded
>>     hdd image to ram but then didn't boot it. I know about usb kb 
>> problem,
>>     maybe author of dosusb could help with it. I have only some dos usb
>>     mouse drivers and mass storage drivers.
>>
>>     Michael Joyner wrote:
>>     > I got FreeDOS to run via RAM disk image boot up via DOS-GRUB 
>> *BUT* I
>>     > couldn't get keyboard to work, USB ONLY! And it appears that the
>>     init of
>>     > the USB devices is incomplete....
>>     >
>>
>>
>>     
>> ------------------------------------------------------------------------- 
>>
>>     This SF.Net email is sponsored by the Moblin Your Move Developer's
>>     challenge
>>     Build the coolest Linux based applications with Moblin SDK & win
>>     great prizes
>>     Grand prize is a trip for two to an Open Source event anywhere in
>>     the world
>>     http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>>     _______________________________________________
>>     open-evot20-discuss mailing list
>>     open-evot20-discuss@...
>>     <mailto:open-evot20-discuss@...>
>>     https://lists.sourceforge.net/lists/listinfo/open-evot20-discuss
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win 
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the 
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> open-evot20-discuss mailing list
>> open-evot20-discuss@...
>> https://lists.sourceforge.net/lists/listinfo/open-evot20-discuss
>>   
>
>

When I exploring T20 BIOS I can see it contains many strings
which indicates that this machine should have some kind of interactive
SETUP or diagnostic program in ROM. But how ro run it?
Maybe some special key combination? Anybody knows?

See strings like this:
             ========== MST Menu - version  %x.%x 
==========                  _
                                                                              
_
 1. Display 'm' pattern    /A            G. Toggle speaker 
on/off             _
 2. Display color screen   /A/S          H. Gradient alignment pattern 
/A/S   _
 3. Gray-scale pattern     /A            I. Configuration screen       
/A     _
 4. Alignment pattern      /A/S          J. Display dither pattern     
/A     _
 5. Auto Alignment pattern /A            M. Test Audio Channel 
0              _
 6. Convergence pattern    /A/S          N. Test Audio Channel 
1              _
 7. Color Block pattern    /A/S          o. NIC test/CTRL O-10B 
Ex./O-100B Ex _
 8. Blank screen           /A            T. USB LoopBack 
Test                 _
 9. Locating Pattern       /A            U. Audio 
Test                        _
 0. 40% white screen       /A            W. Scroll 'H' 1024x768@...    
/A    _
 B. 640x480@...   'm' pattern           -. Screen Off/ =. Screen 
On          _
 C. 800x600@...   'm' pattern           Z. Turn Off Test Audio 
Channel       _
 D. 1024x768@...  'm' pattern           ?. Display Menu/ ESC to 
Exit         _
 E. 1280x1024@... 'm' pattern           R. RTC 
Test                          _
 F. 1024x768@...  'm' 
pattern                                                _
                                                                              
_
 /A: Press A for resolution /S: Press S for 
color                             _

http://rayer.ic.cz/350d/t20boot.avi

Yeah, it's booting and it's playing! Onboard sound seems to be 100% SB16 
compatible (some kind of SW emulation embedded in BIOS with HW support 
via legacy res. trapping to SMI). But the USB keyboard is the killer :(

On Wed, 3 Dec 2008, RayeR wrote:

> http://rayer.ic.cz/350d/t20boot.avi
>
> Yeah, it's booting and it's playing! Onboard sound seems to be 100% SB16
> compatible (some kind of SW emulation embedded in BIOS with HW support
> via legacy res. trapping to SMI). But the USB keyboard is the killer :(

congratulation, I have been booting my freedos via PXE and memdisk, 
but found the same showstopper; no dos usb keyboard support

there are a lot of rumours about an usb driver, but couldn't find a real
working download

found some technical documentation for usb hid keyboard support,
it is possible to write a driver in pascal, wrote some mouse and printer
drivers for dos in the past, found even some of my old source and dos irq
tables, but never started to implement it

main reason, don't have any use for dos nowadays
and this would be a crude hack, you can't write just a driver for one
usb device, you'll need a single "server" instance that is responsible for 
managing the bus, write a clear defined interface structure and need an
extra cooperative driver for any new device, most important HID keyboard and
mouse, in the fashion of the old INT $21
next will be a new mass storage driver (actualy 4 variations of them, 
cursed "standard"), work without end ...
would be a major achievement if it's working on Evo only, hell to implement
for the great variation of dos compatible hardware
and still don't have any use for dos nowadays

there should be someone, just not easy to find

cu Frank

-- 
no sig available

> congratulation, I have been booting my freedos via PXE and memdisk, 
> but found the same showstopper; no dos usb keyboard support
>   
Never worked for me with memdisk 3.72 but booting from flash is better :).

BTW I upgraded RAM with 256MB SD-RAM module so now have 292MB
plenty for linux experiments. Maybe boot time would speed-up using
compressed ramdisk on the USB flash (low USB speed). If I found some
working dos mass-storage driver I will then boot initrd and kernel
(only for debugging phase) from USB flash via loadlin without need to
reflash T20 fw again and again... What kernel should I rather use? 2.4.x 
or 2.6.x?
> there are a lot of rumours about an usb driver, but couldn't find a real
> working download
>
> found some technical documentation for usb hid keyboard support,
> it is possible to write a driver in pascal, wrote some mouse and printer
> drivers for dos in the past, found even some of my old source and dos irq
> tables, but never started to implement it
>   
I know. I googled a lot. I also asked Georg Potthast, author of DOSUSB for
help...
> main reason, don't have any use for dos nowadays
> and this would be a crude hack, you can't write just a driver for one
> usb device, you'll need a single "server" instance that is responsible for 
> managing the bus, write a clear defined interface structure and need an
> extra cooperative driver for any new device, most important HID keyboard and
> mouse, in the fashion of the old INT $21
> next will be a new mass storage driver (actualy 4 variations of them, 
> cursed "standard"), work without end ...
>   
I know this is not piece of cake. But belived someone there will be working
support for mass-storage devices? An now there are 4 or 5 working drivers
(some including fast USB 2.0). I hoped that HID is some kind of standard
so if you will implement it you'll got support for all keybs or all mices.
But I didn't go deep into USB.

I still hope that T20 has some level of USB support inside. Everytime you
press 'P' key the BIOS must recognize the USB keyboard and pressed key.
So once if this exist in BIOS it should work also under DOS but it is
some way disabled. A quotation from SB datasheet indicates there is some
kind of USB legacy kbd support:

"The CS5530A integrates a Universal Serial Bus (USB) controller
which supports two ports. The USB controller is
OpenHCI compliant, a standard developed by Compaq,
Microsoft, and National Semiconductor. The USB core consists
of three main interface blocks: the USB PCI interface
controller, the USB host controller, and the USB interface
controller. Legacy keyboard and mouse controllers are also
supported for DOS compatibility with those USB devices."

Then, in firmware of 64MB and higher T20 you can find a string:
USB: Legacy Enabled Disabled Absent
It's placed probably in some extension ROM not the system BIOS (256kB chip).
It's not in 48MB firmware I currently use. It seem's like higher models
has some hidded setup where you can enable it.
Because of 64MB image is simply too big I cannot try it.
The firmware has different structure that 48M version -
bundle-tools-0.7 cannot recognize 64MB firmware so I cannot unpack
and rebuild it to use smaller HDD image. Does anybody understand
this firmware format?

Another question about HW - I found there's a small 256B serial EEPROM
chip 93C46S. Does anybody know what is inside? CMOS config replacement?
or it maybe for ethernet chip.

Martin

RayeR wrote:

> 
> Another question about HW - I found there's a small 256B serial EEPROM
> chip 93C46S. Does anybody know what is inside? CMOS config replacement?
> or it maybe for ethernet chip.
> 
> Martin

Hi Martin,

Sorry I can't help you with the DOS and firmware questions, but I can 
tell you that U15, the 93C46S chip, is a serial EEPROM (128x8) for the 
eithernet controller U3, DP83815DUJB.

There is U20X which is the RTC, and it does have 128-bytes of CMOS RAM, 
however without a battery backup it cannot store CMOS settings.

    ....gary

> Hi Martin,
>
> Sorry I can't help you with the DOS and firmware questions, but I can 
> tell you that U15, the 93C46S chip, is a serial EEPROM (128x8) for the 
> eithernet controller U3, DP83815DUJB.
>   
Aha, I though that... so nothing interesting there.
> There is U20X which is the RTC, and it does have 128-bytes of CMOS RAM, 
> however without a battery backup it cannot store CMOS settings.
>   
T20 already has RTC but backup battery missing. I did a simple mod
that I glued CR2030 holder on board and connected wires to RTC.
2 resistors on bottom side are needed to be removed. Detailed description
can be googled. Also it is possible to replace SMD RTC chip by Dallas
DS12887A with embedded battery often found on older motherboards.
There are through-holes on PCB ready for it. But I rather have battery
replacement easy.

M.

On Wed, 3 Dec 2008, RayeR wrote:

> Never worked for me with memdisk 3.72 but booting from flash is better :).

always worked for etherboot, but there is a bug in grub4dos, if you want to
use it in a firmware

> BTW I upgraded RAM with 256MB SD-RAM module so now have 292MB

I have 128MB onboard and 256MB extra = 384MB all

most of the time I use my etherboot firmware to test a new kernel&initrd

will only create a new firmware if is everything is working

> plenty for linux experiments. Maybe boot time would speed-up using
> compressed ramdisk on the USB flash (low USB speed). If I found some
> working dos mass-storage driver I will then boot initrd and kernel
> (only for debugging phase) from USB flash via loadlin without need to
> reflash T20 fw again and again... What kernel should I rather use? 2.4.x
> or 2.6.x?

there are usb mass storage drivers for dos, but etherboot is much faster

doesn't matter which kernel, but if you don't need a new native wlan driver
of a newer 2.6 kernel or are using a recent linux distribution without support 
for 2.4 kernel, I'll recommend a 2.4 kernel

you can build a much smaller system with a 2.4 kernel and RAM and usb1 hdd
access are serious constraints

>                                I hoped that HID is some kind of standard
> so if you will implement it you'll got support for all keybs or all mices.
> But I didn't go deep into USB.

I didn't know of the new http://www.georgpotthast.de/usb
looked into the examples, he already has a working "server" managing the usb
bus, and looked at the interface, can use that

>             Legacy keyboard and mouse controllers are also
> supported for DOS compatibility with those USB devices."

> Then, in firmware of 64MB and higher T20 you can find a string:
> USB: Legacy Enabled Disabled Absent

> It's placed probably in some extension ROM not the system BIOS (256kB chip).

still believe if there is any native usb keyboard support, it's in the BIOS

it's a shame, that they didn't put any technical documentation online,
these devices are out of order for a long time

> Because of 64MB image is simply too big I cannot try it.
> The firmware has different structure that 48M version -
> bundle-tools-0.7 cannot recognize 64MB firmware so I cannot unpack
> and rebuild it to use smaller HDD image. Does anybody understand
> this firmware format?

no, creation of >=64MB firmwares with bundletools never worked for me,
always used an orginal firmware and mounted the internal hdd part via
loopback, never calculated a new checksum too, didn't seem to be checked
anywhere

cu Frank

-- 
People who have what they want are very fond of telling people who haven't
what they want that they don't want it.
                 -- Ogden Nash

I currently switched to gcc 3.4.6 and was able to compile kernel sources 
2.4.37.
I used attached config file which I have found for 2.4.31 kernel. There was
PnP enabled but it doesn't cause problem here.
But I have problem with missing /sda1 device, any disk was not probed
I can see USB OHCI was loaded (c00c000. irq 6),
hid-core loaded, mass-storage initialized
but no hdx or sdx...
I missed something...

Now I'm going to try your config 
http://www.baldar.de/pub/Compaq_Evo_T20/config-2.4.34.2-baldar.de

BTW in that version in grub4dos bootp image contains 20s delay
for detecting USB devices, this is your patch in kernel source or 
configured?

Oh I forgot update initrd for current kernel. But I'm in a trouble how 
to make it.
My PC runs Debian lenny with 2.6.22 kernel and there's only mkinitramfs
available - it says that 2.4.x kernel is too old and it cannot make initrd.
Older mkinitrd is not longer available for lenny. I tried force install 
it from
etch repository but it doesn't run - ended up with some libdl-blabla missing
function or so... Any other way how to build initrd for 2.4 kernel on 
new system?
Or do I need to install dedicated linux in VM for this?

RayeR wrote:
> I currently switched to gcc 3.4.6 and was able to compile kernel 
> sources 2.4.37.
> I used attached config file which I have found for 2.4.31 kernel. 
> There was
> PnP enabled but it doesn't cause problem here.
> But I have problem with missing /sda1 device, any disk was not probed
> I can see USB OHCI was loaded (c00c000. irq 6),
> hid-core loaded, mass-storage initialized
> but no hdx or sdx...
> I missed something...
>
> Now I'm going to try your config 
> http://www.baldar.de/pub/Compaq_Evo_T20/config-2.4.34.2-baldar.de
>
> BTW in that version in grub4dos bootp image contains 20s delay
> for detecting USB devices, this is your patch in kernel source or 
> configured?
>

On Sat, 6 Dec 2008, RayeR wrote:

> I missed something...
>
> Now I'm going to try your config 
> http://www.baldar.de/pub/Compaq_Evo_T20/config-2.4.34.2-baldar.de
>
> BTW in that version in grub4dos bootp image contains 20s delay
> for detecting USB devices, this is your patch in kernel source or configured?

no there wasn't an option for a delay, neither in kernel nor in
mkinitrd at that time.

The delay is introduced by me in my "hand crafted" initrd init script.
Some of my usb devices won't get recognized in time to boot from them.
Even 10 sec. weren't good enough for one stick at that time, so I used a
conservative strategy, todays flash is faster.

cu Frank

-- 
Original: "..Tell the other Rangers, the Ambassadors, everyone in this Army of
Light: `Babylon 5 stands with you`. Tell them - Tell them, that from this place
we will deliver notice to the parliaments of conquerers that a line has been
drawn against the darkness, and we will hold that line. No matter the cost."

On Sat, 6 Dec 2008, RayeR wrote:

> Oh I forgot update initrd for current kernel. But I'm in a trouble how
> to make it.
> My PC runs Debian lenny with 2.6.22 kernel and there's only mkinitramfs
> available - it says that 2.4.x kernel is too old and it cannot make initrd.
> Older mkinitrd is not longer available for lenny. I tried force install
> it from
> etch repository but it doesn't run - ended up with some libdl-blabla missing
> function or so... Any other way how to build initrd for 2.4 kernel on
> new system?
> Or do I need to install dedicated linux in VM for this?


of course not, we are in an unix environment, not within something
unspeakable

===== create a 2.4 initrd with a 2.6 mkinitrd =====

my usb stick images are using /dev/sda3 as a linux partition, might be
easier to try to reproduce the functionaly of my initrd with my kernel,
modules and image, when it's working switch to your own kernel&modules

you can start with mkinitramfs and a 2.6 kernel, start from scratch

mkinitrd -c -r /dev/sda3 -w 20 -f ext2 -s /boot/evo-initrd-tree/ -m all:the:used:kernel:modules

change to /boot/evo-initrd-tree check for missing device entrys in ./dev/
and replace the 2.6 kernel modules with the 2.4 modules
check the init script, the new modules have to be loaded instead of the 2.6
file names

check the used used space: du -h /boot/evo-initrd-tree/


   root@...: /root # mkinitrd -c -r /dev/sda3 -w 20 -f ext2 -s /boot/evo-initrd-tree/
   2985 blocks
   root@...: /root du -h /boot/evo-initrd-tree/
   4.0K    /boot/evo-initrd-tree/proc
   4.0K    /boot/evo-initrd-tree/sys
   4.0K    /boot/evo-initrd-tree/etc
   4.0K    /boot/evo-initrd-tree/sbin
   4.0K    /boot/evo-initrd-tree/dev
   1.5M    /boot/evo-initrd-tree/bin
   4.0K    /boot/evo-initrd-tree/lib/modules/2.6.27.6-smp-baldar.de
   8.0K    /boot/evo-initrd-tree/lib/modules
   12K     /boot/evo-initrd-tree/lib
   4.0K    /boot/evo-initrd-tree/mnt
   1.5M    /boot/evo-initrd-tree/

create a file large enough to include the contents of /boot/evo-initrd-tree
and format

   root@...: /root # dd if=/dev/zero of=/tmp/evoinitrd bs=1M count=3
   3+0 records in
   3+0 records out
   3145728 bytes (3.1 MB) copied, 0.0332572 s, 94.6 MB/s
   root@...: /root # mke2fs -m0 /tmp/evoinitrd
   mke2fs 1.40.8 (13-Mar-2008)
   /tmp/evoinitrd is not a block special device.
   Proceed anyway? (y,n) y
   Filesystem label=
   OS type: Linux
   Block size=1024 (log=0)
   Fragment size=1024 (log=0)
   384 inodes, 3072 blocks
   0 blocks (0.00%) reserved for the super user
   First data block=1
   Maximum filesystem blocks=3145728
   1 block group
   8192 blocks per group, 8192 fragments per group
   384 inodes per group

   Writing inode tables: done
   Writing superblocks and filesystem accounting information: done

   This filesystem will be automatically checked every 38 mounts or
   180 days, whichever comes first.  Use tune2fs -c or -i to override.

   root@...: /root # mkdir /mnt/loop
   root@...: /root # mount -t auto -o loop /tmp/evoinitrd /mnt/loop

   root@...: /root # cp -av /boot/evo-initrd-tree/* /mnt/loop
   root@...: /root # umount /mnt/loop
   root@...: /root # gzip -c9 /tmp/evoinitrd > /tmp/initrd

copy your new initrd to your firmware

cu Frank

PS: will update these infos here
     http://baldar.dyndns.org/dokuwiki/doku.php/compaq_evo_t20_thinclient/mkinitrd

-- 
Doyle, TCP/IP vol I (p141)
"A metric is a variable assigned to routes as a means of ranking them from
best to worst or from most preferred to least preferred"

Frank Boehm wrote:
> of course not, we are in an unix environment, not within something
> unspeakable
>
> ===== create a 2.4 initrd with a 2.6 mkinitrd =====
>
> my usb stick images are using /dev/sda3 as a linux partition, might be
> easier to try to reproduce the functionaly of my initrd with my kernel,
> modules and image, when it's working switch to your own kernel&modules
>   
Thanks, fortunatelly I remembered I had some spare HDD with older debian
install so I put it in hdd bay and compiled and made initrd. I used your 
config
without changes first. But when I put my kernel and initrd to T20 it 
failed to
boot. Even it didn't light up keyboard and didn't find sda device. Probably
modules was not loaded properly

http://rayer.ic.cz/350d/kpanic.gif

Then I decided to exploit your initrd. I unzipped&mounted it and then
I explore your init script. I can see you have hardcoded /dev/sda3 - why?
How can I change it to reflect root= kernel parameter? I'd like rather
pass root= from grub. Then I raplaced your *.o modules with compiled
mine of same name and updated busybox. I put it to T20 and wow it booted
from my USB flash debian etch which I had installed by debootstrap.
But after some minutes of doing NOTHING I got strange message flood
on console

http://rayer.ic.cz/350d/ioerror.gif

I had to do hard reset, then fsck was started checking FS and when it
reach about 40% it appeared again and fsck was unable to fix it.
I never booted to login then... I suspect this seems to be like
HW error a bad block on USB Flash, hm... some scandisk for linux?

M.

And one thing, what is needed to make sound working?
There's compiled generic SB16 module it should be compatible
with T20 SB emulation. Do I need install alsa for other apps
like mpg123, mplayer, xmms or OSS driver is enough?

M.

On Sun, 7 Dec 2008, RayeR wrote:

> Frank Boehm wrote:
>> 
> without changes first. But when I put my kernel and initrd to T20 it failed 
> to
> boot. Even it didn't light up keyboard and didn't find sda device. Probably
> modules was not loaded properly
>
> http://rayer.ic.cz/350d/kpanic.gif

which file system did you use for the initrd? this fs has to be include in
the kernel, couldn't be loaded as module

> Then I decided to exploit your initrd. I unzipped&mounted it and then
> I explore your init script. I can see you have hardcoded /dev/sda3 - why?

my usb stick image is able to boot on a normal pc, so I had to create a
first partition with fat, my 2nd partition is for swap, cause there are a
lot of evos around with limited memory, and even slow usb1 swap on a stick
might be better than nothing

> How can I change it to reflect root= kernel parameter? I'd like rather
> pass root= from grub. Then I raplaced your *.o modules with compiled

you can evaluate "cat /proc/cmdline" and look for the root parameter
provided from grub

use my defaults only if there aren't any

> mine of same name and updated busybox. I put it to T20 and wow it booted
> from my USB flash debian etch which I had installed by debootstrap.
> But after some minutes of doing NOTHING I got strange message flood
> on console
>
> http://rayer.ic.cz/350d/ioerror.gif

the evo hardware for usb doesn't seem to be that stable, I can see
once-twice a week strange usb reset errors in my log,

a system completely running in a ramdisk isn't affected, but when the root
fs is on usb1 hdd your system will stop

> I had to do hard reset, then fsck was started checking FS and when it
> reach about 40% it appeared again and fsck was unable to fix it.
> I never booted to login then... I suspect this seems to be like
> HW error a bad block on USB Flash, hm... some scandisk for linux?

e2fsck


cu Frank

-- 
Der Mensch auf der Strasse weiss so ungefähr, das Microsoft Programme
für den Computer baut und in den USofA dauernd vor Gericht steht, IBM
hat er schon mal irgendwo auf Büromaschinen gelesen. Bei Oracle denkt
er an Delphi und bei Sun an den letzten Urlaub. -- Gerhard Lenerz in dcoud

On Sun, 7 Dec 2008, RayeR wrote:

> And one thing, what is needed to make sound working?
> There's compiled generic SB16 module it should be compatible
> with T20 SB emulation. Do I need install alsa for other apps
> like mpg123, mplayer, xmms or OSS driver is enough?

my image is using oss sb module and nmixer, mp3blaster, xmms to 
change, play music

cu Frank

-- 
Who am I then? Tell me that first, and then, if I like being that person,
I'll come up: if not, I'll stay down here till I'm somebody else."
  -- Alice in Wonderland

On Sat, 6 Dec 2008, Frank Boehm wrote:

> On Sat, 6 Dec 2008, RayeR wrote:
>
> PS: will update these infos here
>     http://baldar.dyndns.org/dokuwiki/doku.php/compaq_evo_t20_thinclient/mkinitrd

----

be careful and watch the last lines of your init or linuxrc script
pivot_root is for initrd, and switch_root is for initramfs

please note, a 2.4 kernel initrd will hand over control with

   cd /mnt
   # bye now
   echo "/boot/initrd.gz:  exiting"
   pivot_root . initrd
   exit 0

whereas a 2.6 kernel initramfs

   /bin/sh
   unset ERR
   umount /proc
   umount /sys
   echo "${INITRD}:  exiting"
   exec switch_root /mnt /sbin/init $RUNLEVEL

a 2.6 kernel can still use an old style initrd and would have to use
pivot_root in this case,

there should be pivot_root and switch_root applets in busybox of a new
mkinitrd package

cu Frank

-- 
Who am I then? Tell me that first, and then, if I like being that person,
I'll come up: if not, I'll stay down here till I'm somebody else."
  -- Alice in Wonderland

On Sun, 7 Dec 2008, Frank Boehm wrote:

> On Sun, 7 Dec 2008, RayeR wrote:
>
> which file system did you use for the initrd? this fs has to be include in
> the kernel,

didn't look careful enough, cramfs filesystem

I cannot see kernel messages for detected usb devices, the stick has been
found? you are using the right root fs?

you can test this part of the boot process quite comfortable in a vm like
virtualbox or qemu, if kernel&initrd,usb image are working, switch to the evo.

I'm using most of the time qemu, sometimes virtualbox to test with a 2nd vm.

cu Frank

-- 
any married man knows that having a bored wife around
when you are doing something she has no interest in can ruin any day

> My current develpment of my mini slackware is 12.1 with a 2.6 kernel and
> cloop 2.6
Aha...
> root@...: /root # cat /proc/mtd dev:    size   erasesize  name
> mtd0: 00400000 00020000 "mtdram test device"
> mtd1: 000c0000 00001000 "NetSc520 boot kernel"
> mtd2: 00040000 00001000 "NetSc520 Low BIOS"
> mtd3: 00000000 00000000 "NetSc520 file system"
> mtd4: 00000000 00000000 "NetSc520 High BIOS"
> mtd5: 00800000 00002000 "NAND simulator partition 0"
> mtd6: 01000000 00010000 "OneNAND simulator partition"
But probably most important is base address where the NAND is mapped.
And how. I don't know if it is linear mapped or through some window.
To be accesible under DOS/BIOS it must work on some window
mapping like EMS but it may also be mapped linear at some top address.
Size and sector/page size wi know from datasheet.
> can you remember the url? 
On this blog:
http://winterm.gaast.net/main.php/news.html
he wrote:
" Also, I managed to write a driver to access the on-board NAND flash 
memory on some of the older devices. Thanks to the Linux MTD subsystem 
<http://www.linux-mtd.infradead.org/> this isn't really that hard. Great 
work, guys!"

ps. RTC is working! I probably forgot to update system clock from hw 
clock and then it was rewriten during shutdown.
When I set both hw and system clock then it remained set.

On Mon, 8 Dec 2008, rayer wrote:

>
>> mtd5: 00800000 00002000 "NAND simulator partition 0"

I don't think, that it is so easy

root@...: /root # hexdump mtd5.dd
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0100000
root@...: /root #

shouldn't be empty

> But probably most important is base address where the NAND is mapped.
> And how. I don't know if it is linear mapped or through some window.
> To be accesible under DOS/BIOS it must work on some window
> mapping like EMS but it may also be mapped linear at some top address.
> Size and sector/page size wi know from datasheet.

never read anything real, but didn't do a throughout search

>> can you remember the url? 
> On this blog:
> http://winterm.gaast.net/main.php/news.html
> he wrote:
> " Also, I managed to write a driver to access the on-board NAND flash memory 
> on some of the older devices. Thanks to the Linux MTD subsystem 
> <http://www.linux-mtd.infradead.org/> this isn't really that hard. Great 
> work, guys!"

but, still on his ToDo list?
http://winterm.gaast.net/main.php/todo.html

and he stopped working on this? didn't get any recent news from there for a
long time

> ps. RTC is working! I probably forgot to update system clock from hw clock 
> and then it was rewriten during shutdown.
> When I set both hw and system clock then it remained set.

grats, nice work


cu Frank

-- 
("The whole problem with the world is that fools and fanatics are always so
certain of themselves, and wiser people so full of doubts.")
"Das ist das Hauptproblem an der Welt: Daß die Dummen so sicher sind,  und
die Klugen so voller Zweifel." -- Bertrand Russel

Hi,
please could you help me with making sound and Xorg working?
1st I tried to load module kahlua express emulation, it was recognized
but mpg123 couldn't open /dev/dsp. Then I tried sb module, it was
also recognized but when start mpg123 playback I got strange message
flood on console like:
"too much work in interrupt on uart401 (0x330), uart jabbering?"
and I have to do hard reset :(
What modules are needed and in what order to load it to make it working?

I also cannot run Xorg. I use VESA driver and adjusted PCI address according
to lspci output (PCI:0:18:4). I tried also VGA server but even it didn't 
work. When I run X
the screen seems to switch to higher mode but I see only light color 
with some
garbage on screen for few seconsds then X server fall back to text mode
and end with error. I used Xorg 7.1.1 from etch (apt-get Xorg).

M.

On Tue, 9 Dec 2008, RayeR wrote:

> please could you help me with making sound and Xorg working?
> What modules are needed and in what order to load it to make it working?

my usb stick image 2.4 kernel

sound oss

/etc/modules.conf
---------------------------------- snip ------------------------------------
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0
---------------------------------- snip ------------------------------------

> I also cannot run Xorg. I use VESA driver and adjusted PCI address according

never had any problems with nsc or vesa driver (or vga)

> to lspci output (PCI:0:18:4). I tried also VGA server but even it didn't 
> work. When I run X
> the screen seems to switch to higher mode but I see only light color with 
> some
> garbage on screen for few seconsds then X server fall back to text mode
> and end with error. I used Xorg 7.1.1 from etch (apt-get Xorg).

can send you my working xorg.conf from slackware 12.1 X-7.1.x with vesa

but that's a pretty much default file, I didn't expect any problems here.

Do you have working modlines or at least correct values for horiz and vert
sync refresh if ddc is not working?

and check for DefaultColorDepth=16 cause higher values 24,32 aren't working

where is the X log file in debian? It's /var/log/Xorg.0.log for my new
slack.

the log is quite descriptive and bug hunting is much easier with these infos


cu Frank

-- 
Ferguson's Precept:
         A crisis is when you can't say "let's forget the whole thing."

Than you, Frank and Philip.

Sound is now working, it was needed to pass that parameters to SB 
module, defaults didn't worked.
Probably the MIDI emulation is not fully working and needs to be 
disabled by seting midiport to zero.

Philip, I tried your xconfig except I replaced 'nsc' by 'vesa' and it 
works. I'll further analyze what is
different to my default xconfig and what option caused I got garbaged 
screen. Surely it was not caused
by different resolution or bpp.

The reason why Xserver didn't start was that I have missing 
/dev/input/mouse.
Philip included mouse ignore flag in his xorg.conf so it started. Garbage on
screen is displayed normally for few seconds but this is not an issue.

RayeR wrote:
> The reason why Xserver didn't start was that I have missing 
> /dev/input/mouse.
> Philip included mouse ignore flag in his xorg.conf so it started. Garbage on
> screen is displayed normally for few seconds but this is not an issue.

I'm delighted that it works for you.

What screen resolution are you getting?

Do the framebuffer consoles 1-6 work well for you?

Philip Loewen wrote:
> I'm delighted that it works for you.
>
> What screen resolution are you getting?
>   
Mouse fixed. Now I tried both nsc and vesa driver. I have a problem
with nsc driver that it don't properly restore the textmode when I
shutdown xserver. It leaves set some strange frequency and LCD
monitor gets out of rage (CRT works but i see it's different).
I manually limit monitor to 60Hz and disable DDC but didn't help,
so this is why I use vesa (btw nsc seemed to be faster).

But I have also problem with both nsc/vesa that I cannot set higher
resolution than 1024x768/16bpp. Even if I leave one modeline
eg. "1280x1024" it will use 1024x768 anyway...
> Do the framebuffer consoles 1-6 work well for you?
>   
I don't tried to use FB yet, I read somewhere it cause some problems,
so I use classic 80x25.

BTW do you know open cubic player linux port? I't in standard debian
repository - nice player. I also made working DOSEMU but it's not
much fast. Dosbox was definitely so slow that you wait several
tens of second on just simple "dir" command, LOL...

M.

On Wed, 17 Dec 2008, RayeR wrote:

> Philip Loewen wrote:
>> I'm delighted that it works for you.
>>
>> What screen resolution are you getting?
>>
> But I have also problem with both nsc/vesa that I cannot set higher
> resolution than 1024x768/16bpp. Even if I leave one modeline
> eg. "1280x1024" it will use 1024x768 anyway...
>> Do the framebuffer consoles 1-6 work well for you?
>>
> I don't tried to use FB yet, I read somewhere it cause some problems,
> so I use classic 80x25.

good time to remember the search function of our mailing list,
does this one help?

[Open-evot20-discuss] High resolution text-mode/console on the Evo T20
http://sourceforge.net/mailarchive/forum.php?thread_name=466858ED.6080603%40muzso.hu&forum_name=open-evot20-discuss

an easyier solution for me, remove the offending native framebuffer module
mv /lib/modules/$(uname -r)/kernel/drivers/video/geode/gx1fb.ko /root/

don't have any problems with the normal framebuffer driver and console 
restore after X

we had another thread for bigger then 1024x768x16 resolutions, iirc you had
to had to force a bigger vga shared memory to use the higher resolutions, text
mode might be scrambled then, but X should be working

> BTW do you know open cubic player linux port? I't in standard debian
> repository - nice player. I also made working DOSEMU but it's not
> much fast. Dosbox was definitely so slow that you wait several
> tens of second on just simple "dir" command, LOL...

I'm using mp3blaster,mpd&ncmpc as a console player and xmms for X.

cu Frank

-- 
"The saddest aspect of life right now is that science gathers
knowledge faster than society gathers wisdom."
  -- Isaac Asimov

Hi,
> good time to remember the search function of our mailing list,
> does this one help?
>
> [Open-evot20-discuss] High resolution text-mode/console on the Evo T20
> http://sourceforge.net/mailarchive/forum.php?thread_name=466858ED.6080603%40muzso.hu&forum_name=open-evot20-discuss
>   
OK, I readed this thread but there he's talking that
gx1fb module is working properly only since the 2.6.21.1 kernels
If I remember 2.4 kernel doesn't have this option so i compiled
standard vesa fb:
CONFIG_FB_VESA=y
not tested yet.
> an easyier solution for me, remove the offending native framebuffer module
> mv /lib/modules/$(uname -r)/kernel/drivers/video/geode/gx1fb.ko /root/
>
> don't have any problems with the normal framebuffer driver and console 
> restore after X
>
> we had another thread for bigger then 1024x768x16 resolutions, iirc you had
> to had to force a bigger vga shared memory to use the higher resolutions, text
> mode might be scrambled then, but X should be working
>   
I will look. In this thread he didn't solved it and pointing that may be 
needed
to patch VGA BIOS. It's not bad idea, I can extract VGA BIOS from FW image
and run it in Bochs. Then I would need to find where is video memory size
stored. But what if it is not constant? Do we know that all T20 models have
same video memory size? If some higher mode will have different VGA BIOS
configured to bigger VRAM then i fould be piece of cake to patch other T20
models.
> I'm using mp3blaster,mpd&ncmpc as a console player and xmms for X.
>   
I tried mp3blaster but OCP looks much better and seems support more 
music formats.
I have also mpg123 and xmms installed. Please what mixer do you use? You
told it but I lost it. Is it debianized or do I need to compile it. In 
debian repository
I didn't find oss mixer but only mixers for alsa.

M.

RayeR wrote:
> I will look. In this thread he didn't solved it and pointing that may be 
> needed
> to patch VGA BIOS. It's not bad idea, I can extract VGA BIOS from FW image
> and run it in Bochs. Then I would need to find where is video memory size
> stored. But what if it is not constant? Do we know that all T20 models have
> same video memory size? If some higher mode will have different VGA BIOS
> configured to bigger VRAM then i fould be piece of cake to patch other T20
> models.
>   

Check the last 2-3 posts in this thread:
https://sourceforge.net/mailarchive/forum.php?thread_name=48157CF8.6010909%40tidepool.ca&forum_name=open-evot20-discuss

If the link does not get through correctly ... the first post of the 
thread was titled "Need some pointers please" and was posted on 21st 
April this year.
The first relevant post is titled "1280x1024@..." and was posted by 
Philip Loewen.

-- 
                                 Müller Zsolt
                  email: muzso@... | www: http://muzso.hu/

> Check the last 2-3 posts in this thread:
> https://sourceforge.net/mailarchive/forum.php?thread_name=48157CF8.6010909%40tidepool.ca&forum_name=open-evot20-discuss
>
> If the link does not get through correctly ... the first post of the 
> thread was titled "Need some pointers please" and was posted on 21st 
> April this year.
> The first relevant post is titled "1280x1024@..." and was posted by 
> Philip Loewen
Hm, if I understand well, there's some patch to grub which changes 
hardware registers to
map more VRAM and then X can run in 1280 but console gets blind :\
Many reading around, continue tomorrow...

BTW I extracted VGA BIOS from firmware and it contains a string
"Video Memory Size: 4.0MB   "
I loaded it in Bochs and run my VESATEST there. As you can see VRAM
size is zero but it maybe caused that VGA BIOS didn't run real hardware.
I will try to repeat it on my T20. Here are modes that I found:

Generated by Martin's VGA13/VESA driver test 1.41
Host CPU id: F20h, host OS: DOS

VESA VBE 2.0 Cyrix [0 kB]
Elpin Systems VGA BIOS
Cyrix GX
Version 2.07
OEM software revision 1.0
VBE/AF version 0.0
38 videomodes available on this card

 #0 = 100h - 640x400/8
 #1 = 101h - 640x480/8
 #2 = 102h - 800x600/4 (unsupported by VESADRV)
 #3 = 103h - 800x600/8
 #4 = 104h - 1024x768/4 (unsupported by VESADRV)
 #5 = 105h - 1024x768/8
 #6 = 106h - 1280x1024/4 (unsupported by VESADRV)
 #7 = 107h - 1280x1024/8
 #8 = 108h - 80x60/4 (unsupported by VESADRV)
 #9 = 109h - 132x25/4 (unsupported by VESADRV)
#10 = 10Ah - 132x43/4 (unsupported by VESADRV)
#11 = 10Bh - 132x50/4 (unsupported by VESADRV)
#12 = 10Ch - 132x60/4 (unsupported by VESADRV)
#13 = 10Dh - 320x200/15
#14 = 10Eh - 320x200/16
#15 = 110h - 640x480/15
#16 = 111h - 640x480/16
#17 = 113h - 800x600/15
#18 = 114h - 800x600/16
#19 = 116h - 1024x768/15
#20 = 117h - 1024x768/16
#21 = 11Ah - 1280x1024/16
#22 = 120h - 320x200/8
#23 = 121h - 320x240/8
#24 = 122h - 320x240/15
#25 = 123h - 320x240/16
#26 = 124h - 320x240/16
#27 = 125h - 400x300/8
#28 = 126h - 400x300/15
#29 = 127h - 400x300/16
#30 = 128h - 400x300/16
#31 = 129h - 512x384/8
#32 = 12Ah - 512x384/15
#33 = 12Bh - 512x384/16
#34 = 12Ch - 512x384/16
#35 = 12Dh - 640x400/15
#36 = 12Eh - 640x400/16
#37 = 12Fh - 640x400/16

RayeR wrote:
> Hm, if I understand well, there's some patch to grub which changes 
> hardware registers to map more VRAM and then X can run in 1280 but console gets blind :\
> Many reading around, continue tomorrow...

That's a decent summary of my experience. Right now I also 
get a half-working console, but with video garbage on the 
top 20% of the screen. I have uploaded my settings to a 
temporary web page that you will find after taking the three 
words
  philip
  tidepool
  ca
putting dots between and http:// on the front. (Sorry for 
the secret-agent approach, but I live in fear of robots.)

Mr Johannsen (sp?) said that the patched version of grub 
0.97 that I am using actually came after his primary 
project, which was a modified version of the etherboot 
network kernel loader. The thread you are reading contains 
references to that alternative material as well. I have 
never gone back and investigated it.

I got my T20 to work in a way that satisfies me simply by 
trusting what more expert people have done. It is clear that 
you know enough to make some major improvements. I hope you 
succeed, and share your results. Mode #21 in the list copied 
below is the one we all want, but making it happen is not 
too simple. (I have looked through the specifications for 
the CS5530 chip that supplies video, and it seems that Mode 
#21 is the best we can ever hope for. The Evo T20 will never 
drive one of those fancy new widescreen LCD monitors.)

Good luck!

> BTW I extracted VGA BIOS from firmware and it contains a string
> "Video Memory Size: 4.0MB   "
> I loaded it in Bochs and run my VESATEST there. As you can see VRAM
> size is zero but it maybe caused that VGA BIOS didn't run real hardware.
> I will try to repeat it on my T20. Here are modes that I found:
> 
> Generated by Martin's VGA13/VESA driver test 1.41
> Host CPU id: F20h, host OS: DOS
> 
> VESA VBE 2.0 Cyrix [0 kB]
> Elpin Systems VGA BIOS
> Cyrix GX
> Version 2.07
> OEM software revision 1.0
> VBE/AF version 0.0
> 38 videomodes available on this card
> 
>  #0 = 100h - 640x400/8
>  #1 = 101h - 640x480/8
>  #2 = 102h - 800x600/4 (unsupported by VESADRV)
>  #3 = 103h - 800x600/8
>  #4 = 104h - 1024x768/4 (unsupported by VESADRV)
>  #5 = 105h - 1024x768/8
>  #6 = 106h - 1280x1024/4 (unsupported by VESADRV)
>  #7 = 107h - 1280x1024/8
>  #8 = 108h - 80x60/4 (unsupported by VESADRV)
>  #9 = 109h - 132x25/4 (unsupported by VESADRV)
> #10 = 10Ah - 132x43/4 (unsupported by VESADRV)
> #11 = 10Bh - 132x50/4 (unsupported by VESADRV)
> #12 = 10Ch - 132x60/4 (unsupported by VESADRV)
> #13 = 10Dh - 320x200/15
> #14 = 10Eh - 320x200/16
> #15 = 110h - 640x480/15
> #16 = 111h - 640x480/16
> #17 = 113h - 800x600/15
> #18 = 114h - 800x600/16
> #19 = 116h - 1024x768/15
> #20 = 117h - 1024x768/16
> #21 = 11Ah - 1280x1024/16
> #22 = 120h - 320x200/8
> #23 = 121h - 320x240/8
> #24 = 122h - 320x240/15
> #25 = 123h - 320x240/16
> #26 = 124h - 320x240/16
> #27 = 125h - 400x300/8
> #28 = 126h - 400x300/15
> #29 = 127h - 400x300/16
> #30 = 128h - 400x300/16
> #31 = 129h - 512x384/8
> #32 = 12Ah - 512x384/15
> #33 = 12Bh - 512x384/16
> #34 = 12Ch - 512x384/16
> #35 = 12Dh - 640x400/15
> #36 = 12Eh - 640x400/16
> #37 = 12Fh - 640x400/16

Hi,
I did some experiments with VGA BIOS on T20. First I replaced VGA BIOS 
by version 4.13
from 128MB NTE firmware (same as for XPE firmwares) but it didn't work 
at all - I got blank
screen. The same for VGA BIOS from Wyse Winterm 35xx (T20 eq.). Then I 
googled for
other embedded miniboards based on GX1 and download some BIOS. I ripped 
out VGA BIOS
version 2.08 (my EVO has 2.07) I updated firmware and it boots OK but I 
got same amount of
reported VESA VRAM size (2,25MB).
Then I tried to disassemble VGA BIOS in IDA to figure out where VRAM 
size is set.
Result is here:
http://rayer.ic.cz/350d/t20/VGABIOS.HTM
http://rayer.ic.cz/350d/t20/VGABIOS.IDB
I went carefully through initialization routine but it doesn't touch any 
VGA PCI registers except
it checks PCI device ID. Then it do a lot of settings on VGA CRTC ports 
- this is not important.
So I guess that VRAM size is set somewhere else, probably in system BIOS 
(the 256kB FlashROM).

Müller Zsolt wrote:
> RayeR wrote:
>   
>> I will look. In this thread he didn't solved it and pointing that may be 
>> needed
>> to patch VGA BIOS. It's not bad idea, I can extract VGA BIOS from FW image
>> and run it in Bochs. Then I would need to find where is video memory size
>> stored. But what if it is not constant? Do we know that all T20 models have
>> same video memory size? If some higher mode will have different VGA BIOS
>> configured to bigger VRAM then i fould be piece of cake to patch other T20
>> models.
>>

On Mon, 29 Dec 2008, RayeR wrote:

> So I guess that VRAM size is set somewhere else, probably in system BIOS
> (the 256kB FlashROM).

well done, that is quite time consuming work, thank you

cu Frank

-- 
   * Warning: Dates in Calendar are closer than they appear.

Frank Boehm wrote:
> On Mon, 29 Dec 2008, RayeR wrote:
> 
>> So I guess that VRAM size is set somewhere else, probably in system BIOS
>> (the 256kB FlashROM).
> 
> well done, that is quite time consuming work, thank you

Over at http://www.coreboot.org there is a tool called 'flashrom' 
that will read and/or write the Evo T20 rom chip. I have a 
binary copy of the BIOS that I would gladly send to you, but 
maybe you would prefer to get this tool yourself.  - Philip

I know this tool. But the system BIOS is already included in firmware file
so it is easy to extract it. BIOS image begins with "MST ULC ver 11.49 WYSE"
string + leading 16 zero bytes.

It would be interesting if someone could take his EVO with original 
windows NTE,
reconfigure it to 1280x1024/16bpp and make a comparison of bios dump
before/after. Maybe it has some writable area like DMI/ESCD on PC.
But it would need a tool for windows (afaik there's flashrom win32 port).

Philip Loewen wrote:
> Frank Boehm wrote:
>   
>> On Mon, 29 Dec 2008, RayeR wrote:
>>
>>     
>>> So I guess that VRAM size is set somewhere else, probably in system BIOS
>>> (the 256kB FlashROM).
>>>       
>> well done, that is quite time consuming work, thank you
>>     
>
> Over at http://www.coreboot.org there is a tool called 'flashrom' 
> that will read and/or write the Evo T20 rom chip. I have a 
> binary copy of the BIOS that I would gladly send to you, but 
> maybe you would prefer to get this tool yourself.  - Philip
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> open-evot20-discuss mailing list
> open-evot20-discuss@...
> https://lists.sourceforge.net/lists/listinfo/open-evot20-discuss
>
>

I started to disassemble system BIOS, F0000-FFFFFh segment.
There seems to be much more writes to CPU and GR registers,
maybe also the FB size. I'm not finished but who wants to look here:

http://rayer.ic.cz/350d/t20/BIOS.HTM

for understanding you'll need AMD GX1 datasheet, freely available

Frank Boehm wrote:
> On Mon, 29 Dec 2008, RayeR wrote:
>
>   
>> So I guess that VRAM size is set somewhere else, probably in system BIOS
>> (the 256kB FlashROM).
>>     
>
> well done, that is quite time consuming work, thank you
>
> cu Frank
>
>

I continune with disassembly. today I revealed a routine that wites to 
GX_BASE+offset
registers. Then I went through all references and found 2 places where 
GRBA register
is changed. I looked closer to 1st place, you can find it under label 
SET_FB_SIZE
It's obvious that FB base is set according to current RAM top and 
hardcoded constant
which stands for 2,5MB. So now it would be possible to make a patch for 
bigger
size. Current dasm listing: http://rayer.ic.cz/350d/t20/BIOS.HTM

ps. Is there some linux utility which allows me to view physical memory?
I need to read MMIO registers.

ps2. As I told before that NCS driver, when exit Xorg to console, set 
some strange
frequency - I looked to OSD and really I got console in 140Hz (62,9kHz)!
It seems like CRTC is programed to 1024x768@... when start X but it leaves
unchanged when exit X....

RayeR wrote:
> I started to disassemble system BIOS, F0000-FFFFFh segment.
> There seems to be much more writes to CPU and GR registers,
> maybe also the FB size. I'm not finished but who wants to look here:
>
> http://rayer.ic.cz/350d/t20/BIOS.HTM
>
> for understanding you'll need AMD GX1 datasheet, freely available
>
> Frank Boehm wrote:
>   
>> On Mon, 29 Dec 2008, RayeR wrote:
>>
>>   
>>     
>>> So I guess that VRAM size is set somewhere else, probably in system BIOS
>>> (the 256kB FlashROM).
>>>     
>>>       
>> well done, that is quite time consuming work, thank you
>>
>> cu Frank
>>
>>   
>>     
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> open-evot20-discuss mailing list
> open-evot20-discuss@...
> https://lists.sourceforge.net/lists/listinfo/open-evot20-discuss
>
>

RayeR wrote:
> I continue with disassembly. .....
 >
> ps. Is there some linux utility which allows me to view physical memory?
> I need to read MMIO registers.


This is exciting work. Does the /dev/mem system give you 
enough functionality to deal directly with the Evo's memory? 
(Try "man mem" on your own machine, or read online at 
http://linux.die.net/man/4/mem.)

Oh yes, but I though something at higher/more user friendly level
(I have some small memory viewers for DOS e.g. seemem with
nice textmode GUI...) Nevermind, I found this sample code
http://free-electrons.com/pub/mirror/devmem2.c
and it do the job for me.

So I'm going to check MMIO registers (after patching FB size at F000:0105):

GX_BASE=0x40000000
BC_DRAM_TOP(0x40008000)=0x11D7FFFF=285,5MB (288-2,5MB)
hm this seems it doesn't reflect my change, RAM top should be lower.
MC_GBASE_ADD(0x40008414)=0x0000023B -
This field corresponds to address bits [29:19] of framebuffer so
we shift it 19 bits to left and get: 0x11D80000, this is just above RAM top.
This is as default. I don't know why the patch did not aplied, maybe
it is changed on another place of BIOS?

Philip Loewen wrote:
> This is exciting work. Does the /dev/mem system give you 
> enough functionality to deal directly with the Evo's memory? 
> (Try "man mem" on your own machine, or read online at 
> http://linux.die.net/man/4/mem.)
>

With help of devmem2 tool I found I have patched wrong BIOS code.
 From current memory listing I can see that F0000:FFFFF BIOS range is
loaded with last 64kB of ULC_CODE.BIN and not the ULC_CODE.CE
that I disassembled. This is big missunderstanding. Seems that ULC_CODE.CE
BIOS is only used as a fall-back for BIOS reflash but normally is used .BIN.

But now I know what I'm looking for so I hope I will reveal similar code
in ULC_CODE.BIN and patch it.

I'm not sure how much help I can provide here, as I'm not a software 
guy, but... here are a few comments & suggestions.

NTe (and CE?) models support a maximum resolution of 1280x1024x8-bit or 
1024x768x16-bit.

XPe models support a maximum resolution of 1600x1200x16-bit or 
1280x1024x24-bit.

Is it possible to compare the two BIOS's to discover what their 
differences are?

The BIOS chips on the two models are of different sizes.  The CE & NTe 
models are 256KB, while the XPe model is 512KB.

For the Wyse NTe model (unsure of the HP models), the file ulc_code.pk 
is added to the image by the UTC conversion program, img2utc.exe.

For the Wyse XPe & CE models, the above operation is not performed.

Hope this helps!

    ...gary


RayeR wrote:
> With help of devmem2 tool I found I have patched wrong BIOS code.
>  From current memory listing I can see that F0000:FFFFF BIOS range is
> loaded with last 64kB of ULC_CODE.BIN and not the ULC_CODE.CE
> that I disassembled. This is big missunderstanding. Seems that ULC_CODE.CE
> BIOS is only used as a fall-back for BIOS reflash but normally is used .BIN.
> 
> But now I know what I'm looking for so I hope I will reveal similar code
> in ULC_CODE.BIN and patch it.
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> open-evot20-discuss mailing list
> open-evot20-discuss@...
> https://lists.sourceforge.net/lists/listinfo/open-evot20-discuss
>

I just finished disassembling of F0000-FFFFFh range,
see updated listing:
http://rayer.ic.cz/350d/t20/BIOS.HTM

Important is label named: SET_FB_SIZE
There are 2 ways how FB size is set, I tried both and
found the right one - described ion comments

Now I got under linux following MMIO reg. dump:
40008000 (RAM top) = 11BFFFFFh (RAM total is 12000000h)
40008414 (FB base) = 00000238h
Well the values are lower than before and gives exactly 4MB for FB.

But VESA reports still 2,25MB - it is probably somewhere
hardcoded in VGA BIOS and I will have to return there to patch it.

Now I can hope that NCS Xorg driver is smarter and found
more videoram...
Wow it works! I can set 1280x1024/16bpp with NSC driver.
Unfortunatelly this crap set 140Hz refreshrate in textmode
when I switch back to console. I use Xorg 7.1.0 - this
is oficilly latest version for Debian Etch distro.
Can someone else confirm which version of Xorg/NSC works
without this problem? Can I use newer driver module in
older Xorg? I'd like to avoid recompiling Xorg or mixing
different distro libs...
> XPe models support a maximum resolution of 1600x1200x16-bit or 
> 1280x1024x24-bit.
>   
Good to know. Is it written somewhere in spec or your personal experience?
> Is it possible to compare the two BIOS's to discover what their 
> differences are?
>   
Yes, I downladed the FW (XPE 256/256) and extracted VGA BIOS. It is
"VGA BIOS - Version 4.13  Copyright (C) 1990-1995 Elpin Systems"
and is similar to other NTE 64/96/128 version. Except NTE 48 uses
"VGA BIOS - Version 2.07  Copyright (C) 1990-1995 Elpin Systems"
I already tried to replace my 2.07 BIOS with 4.13 BIOS from NTE but
I got just black screen :( So it probably depends on some functions
of system BIOS which differs/missing on NTE 48MB model
> The BIOS chips on the two models are of different sizes.  The CE & NTe 
> models are 256KB, while the XPe model is 512KB.
>   
BTW is known the structure of NTE 64MB and above (incl. XPE) firmwares?
I use bundle-tools for compiling/decompiling NTE 48MB FW on level
of particular modules (which is needed to cut down HDD image size)
but NTE 64MB and above doesn't have "BndL" signature and are different.

Martin

RayeR wrote:
> BTW is known the structure of NTE 64MB and above (incl. XPE) firmwares?
> I use bundle-tools for compiling/decompiling NTE 48MB FW on level
> of particular modules (which is needed to cut down HDD image size)
> but NTE 64MB and above doesn't have "BndL" signature and are different.

Hi Martin, 

 I just looked into the various images and so far all PartNo 2383xx models seem to use the same format. 

At least the 238364 and 238465 NTe models w/o PXE which use the U64CPQ163.bin or U93CPQ163.bin image do and they also still have the BndL signature. 

It seems that the PXE models use a different image setup. 

Could anyone which owns a PXE model pls report what messages appear on the screen during the netXfer process!!
I assume that netXfer is still used with those models.

Cheers,
Klaus

Hi Martin,

RayeR wrote:
 >>
>> XPe models support a maximum resolution of 1600x1200x16-bit or 
>> 1280x1024x24-bit.
>>   
> Good to know. Is it written somewhere in spec or your personal experience?

Both.

Here is a link to the Wyse data sheet for their XPe model, the WT9235LE, 
listing its properties:
http://www.wyse.com/products/winterm/9235LE/9235.pdf

and for the NTe model, WT8235LE:
http://www.wyse.com/service/discontd/winterm/wint8000/8235.pdf

I'm unable to currently locate the CE model WT3235LE data sheet on the 
Wyse web site.  They seem to have a lot of broken links.  However here 
is a copy I found on another web site:
http://www.vecmar.com/pdf/wyse/3235.pdf

These Wyse models are identical to the HP/Compaq models.  The pcb in the 
HP/Compaq units is made by Wyse.  The only differences are the case and 
software.

I don't know if this helps any, but WinXPe reports the following when 
running at 1280x1024x16-bit:
   Memory Range: 40800000 - 40FFFFFF
   Memory Range: 40010000 - 40010FFF
   Memory Range: 000A0000 - 000BFFFF
   I/O Range: 03B0 - 03BA
   I/O Range: 03C0 - 03DE


>> Is it possible to compare the two BIOS's to discover what their 
>> differences are?
>>   
> Yes, I downladed the FW (XPE 256/256) and extracted VGA BIOS. It is
> "VGA BIOS - Version 4.13  Copyright (C) 1990-1995 Elpin Systems"
> and is similar to other NTE 64/96/128 version.

Interesting, my Wyse NTe 64MB & 96MB images both use version 2.07.

The Wyse XPe 256MB image (W256B328.bin) uses version 4.13.

> Except NTE 48 uses
> "VGA BIOS - Version 2.07  Copyright (C) 1990-1995 Elpin Systems"
> I already tried to replace my 2.07 BIOS with 4.13 BIOS from NTE but
> I got just black screen :( So it probably depends on some functions
> of system BIOS which differs/missing on NTE 48MB model
>> The BIOS chips on the two models are of different sizes.  The CE & NTe 
>> models are 256KB, while the XPe model is 512KB.
>>   
> BTW is known the structure of NTE 64MB and above (incl. XPE) firmwares?
> I use bundle-tools for compiling/decompiling NTE 48MB FW on level
> of particular modules (which is needed to cut down HDD image size)
> but NTE 64MB and above doesn't have "BndL" signature and are different.
> 
> Martin

I'm in waaaaay over my head now....
I just used an old DOS tool (list.com) to examine two NTe images from 
Wyse and found the "BndL" string in both.  The images I looked at were:
   U64STD180.BIN  (64MB)
   U96STD180.BIN  (96MB)

Hope this helps.

     ....gary

> At least the 238364 and 238465 NTe models w/o PXE which use the U64CPQ163.bin or U93CPQ163.bin image do and they also still have the BndL signature. 
>
> It seems that the PXE models use a different image setup. 
>   
Aha, my downloaded FW for 64M and 128M NTE and 256M XPE
are all PXE versions and don't contain BndL...

> Here is a link to the Wyse data sheet for their XPe model, the WT9235LE, 
> listing its properties:
> http://www.wyse.com/products/winterm/9235LE/9235.pdf
>   
OK, I belive it. Now when I increased framebuffer size it is no longer
limitation for drivers which don't rely on BIOS. But to do a perfect job
I'd like to patch VESA BIOS function too to report and use 4MB.
> These Wyse models are identical to the HP/Compaq models.  The pcb in the 
> HP/Compaq units is made by Wyse.  The only differences are the case and 
> software.
>   
I know, I saw some photos of Winterm PCB. Wyse name is on some stickers
on my T20 board and also in BIOS. Compaq is just nice case :)
> I don't know if this helps any, but WinXPe reports the following when 
> running at 1280x1024x16-bit:
>    Memory Range: 40800000 - 40FFFFFF
>    Memory Range: 40010000 - 40010FFF
>    Memory Range: 000A0000 - 000BFFFF
>   
Interesting - it reports 8MB allocated for framebuffer so it may
hold up to 1600x1200/32bpp. Or maybe it utilize 2 pages stored
in FB but when it is in slow SDRAM it will have no speed effect...

But in Geode datasheets we can read:

"The CS5530A is capable of displaying graphics resolutions
up to 1600x1200 at color depths up to 24 bits per
pixel (bpp) while simultaneously overlaying a video window."

And for GX1 CPU: "Supports up to 1280x1024x16 bpp"
> Interesting, my Wyse NTe 64MB & 96MB images both use version 2.07.
>
> The Wyse XPe 256MB image (W256B328.bin) uses version 4.13.
>   
Hm, maybe this is another difference of PXE firmware.
I'm downloading others...

Martin

Klaus Klein wrote:
> RayeR wrote:
>> BTW is known the structure of NTE 64MB and above (incl. XPE) firmwares?
>> I use bundle-tools for compiling/decompiling NTE 48MB FW on level
>> of particular modules (which is needed to cut down HDD image size)
>> but NTE 64MB and above doesn't have "BndL" signature and are different.
> 
> Hi Martin, 
> 
> I just looked into the various images and so far all PartNo 2383xx models 
 > seem to use the same format.
> 
> At least the 238364 and 238465 NTe models w/o PXE which use the U64CPQ163.bin
 > or U93CPQ163.bin image do and they also still have the BndL signature.
> 
> It seems that the PXE models use a different image setup. 
> 
> Could anyone which owns a PXE model pls report what messages appear on the 
 > screen during the netXfer process!!
> I assume that netXfer is still used with those models.
> 
> Cheers,
> Klaus 

Hi Klaus,

None of my Wyse NTe models support PXE with their standard 64MB or 96MB 
images, but they do have BndL.

I just downloaded and examined the Wyse 128MB and 192MB NTe images, and 
they do look to support PXE
"BootManage PXE-2.0 PROM 1.0, NS83815 4.3, SDK 3.0/082 (OEM52)"
but I don't see BndL.

Karl has info on patching an image with support for PXE at:
http://www.mowson.org/karl/articles/t20-etherboot/

When I followed his directions and use my Wyse (or was it Compaq?) 
image, I then have a PXE boot unit with BndL.  However I'm not sure if 
this answers your question, as it is modified code.  And yes it is 
loaded with netxfer.

My XPe models do support PXE, but I don't see BndL in these images.  I 
can re-flash one of these units if it helps.

      .......gary

RayeR wrote:
> Hm, maybe this is another difference of PXE firmware.
> I'm downloading others...
> 
> Martin
> 

Here is a summary of the various Wyse firmwares I have:

file name	size	OS	PXE	VGAver	BndL

U64STD180.BIN	64	NTe	no	2.07	yes
U96STD180.BIN	96	NTe	no	2.07	yes
W128B216.BIN	128	NTe	yes	4.13	no
W192B216.BIN	192	NTe	yes	4.13	no
W256B328BIN	256	XPe	yes	4.13	no

     ....gary

gary wrote:
> Karl has info on patching an image with support for PXE at:
> http://www.mowson.org/karl/articles/t20-etherboot/
>   
If I understand well, Karl had used non-PXE FW and combined it with
own PXE ROM. He didn't modified original PXE FW.

Thanks for the summary. I see that all PXE models has 4.13 VGA BIOS
which separately doesn't work for me. I would need to reflash entire BIOS
with PXE FW but I have only 16MB of flash so it is not possible without
further modding of original PXE FW (simply truncate the file doesn't work).

Martin

I just downloaded 96M nonPXE version and I can confirm
it has BndL, so it was my misunderstandin...
I compared VGA BIOS but it is same as in 48M version.
Maybe I could try again the 2.08 version that I grabbed
from some industrial board...

gary wrote:
> Here is a summary of the various Wyse firmwares I have:
>
> file name	size	OS	PXE	VGAver	BndL
>
> U64STD180.BIN	64	NTe	no	2.07	yes
> U96STD180.BIN	96	NTe	no	2.07	yes
> W128B216.BIN	128	NTe	yes	4.13	no
> W192B216.BIN	192	NTe	yes	4.13	no
> W256B328BIN	256	XPe	yes	4.13	no
>

gary wrote:
> Here is a summary of the various Wyse firmwares I have:
> 
> file name	size	OS	PXE	VGAver	BndL
> 
> U64STD180.BIN	64	NTe	no	2.07	yes
> U96STD180.BIN	96	NTe	no	2.07	yes
> W128B216.BIN	128	NTe	yes	4.13	no
> W192B216.BIN	192	NTe	yes	4.13	no
> W256B328BIN	256	XPe	yes	4.13	no
> 
>      ....gary

It would be great to have a copy of this kind of thing on our wiki,
  http://open-evot20.sourceforge.net/wiki/
Unfortunately, I have just discovered that our wiki is not currently editable. I'm trying to fix this.

gary wrote:
> Hi Klaus,
> None of my Wyse NTe models support PXE with their standard 64MB or 96MB 
> images, but they do have BndL.

That confirms my statement. ;-)

> I just downloaded and examined the Wyse 128MB and 192MB NTe images, and 
> they do look to support PXE
> "BootManage PXE-2.0 PROM 1.0, NS83815 4.3, SDK 3.0/082 (OEM52)"
> but I don't see BndL.

Also correct. :-)

> Karl has info on patching an image with support for PXE at:
> http://www.mowson.org/karl/articles/t20-etherboot/

During my quest for a bootable ext2 partition I recompiled GRUB with the '--enable-ext2fs'* and '--support-diskless'* along with the '0x80' and 'gateA20' fix. 
I just realized that before GRUB requests the file witch it is told to, a TFTP request for a 'default' file is send. 
I would guess that GRUB tries to load the file for the PXE routine but I still have to confirm that.

> My XPe models do support PXE, but I don't see BndL in these images.  I 
> can re-flash one of these units if it helps.

That would be a greate help to get further with those PXE images. 
If you pls could let us know what you use to flash those units as well as what comes up on the screen during the flash process. 

Cheers,
Klaus

I tried again VGA BIOS ver 2.08 and also one 4.13 grabbed from
industrial boards but both still reports 2240kB. This boards
should have FB size selectable in BIOS [1/2/4MB] so it is not hardcoded
there but I don't know how it determine this value.

Martin

RayeR wrote:
> I just downloaded 96M nonPXE version and I can confirm
> it has BndL, so it was my misunderstandin...
> I compared VGA BIOS but it is same as in 48M version.
> Maybe I could try again the 2.08 version that I grabbed
> from some industrial board...
> 
> gary wrote:
>> Here is a summary of the various Wyse firmwares I have:
>>
>> file name	size	OS	PXE	VGAver	BndL
>>
>> U64STD180.BIN	64	NTe	no	2.07	yes
>> U96STD180.BIN	96	NTe	no	2.07	yes
>> W128B216.BIN	128	NTe	yes	4.13	no
>> W192B216.BIN	192	NTe	yes	4.13	no
>> W256B328BIN	256	XPe	yes	4.13	no
>>   

This is interesting... I just downloaded the 256MB image for the Wyse 
NTe model and it is quite different.  I can't find the usual references 
to PXE, the VGA BIOS version, or the BndL string!!

I though I'd try to load this version, but I think I'm out of luck.  I 
do have a 128MB SmartMedia flash card which I could use to increase the 
size of flash, but my NTe units only have 64MB soldered on the pcb.  So 
this would only get me to 192MB maximum.

I could try moving the BIOS chip from a NTe machine into an XPe machine, 
as I have one with 256MB of flash.  I'm not sure if this would work, or 
if I'd trash it.

    ...gary

Philip Loewen wrote:
> gary wrote:
>> Here is a summary of the various Wyse firmwares I have:
>>
>> file name	size	OS	PXE	VGAver	BndL
>>
>> U64STD180.BIN	64	NTe	no	2.07	yes
>> U96STD180.BIN	96	NTe	no	2.07	yes
>> W128B216.BIN	128	NTe	yes	4.13	no
>> W192B216.BIN	192	NTe	yes	4.13	no
>> W256B328BIN	256	XPe	yes	4.13	no
>>
>>      ....gary
> 
> It would be great to have a copy of this kind of thing on our wiki,
>   http://open-evot20.sourceforge.net/wiki/
> Unfortunately, I have just discovered that our wiki is not currently editable. I'm trying to fix this.


Philip,

A while back, Karl and I put together a parts list for three models: 
WT8235LE, T20-XPe, and T20-WinCE.  This might also be a useful addition 
to the wiki.  Would you like a copy of it?

      ....gary

Klaus Klein wrote:
> gary wrote:
>> My XPe models do support PXE, but I don't see BndL in these images.  I 
>> can re-flash one of these units if it helps.
> 
> That would be a greate help to get further with those PXE images. 
> If you pls could let us know what you use to flash those units as well as what comes up on the screen during the flash process. 
> 
> Cheers,
> Klaus


OK.  I need to take down my kitchen machine to swipe its monitor and 
reconfigure my notebook to run netxfer.  I hope to have you the info in 
a bit.

     ...gary

gary wrote:

> A while back, Karl and I put together a parts list for three models: 
> WT8235LE, T20-XPe, and T20-WinCE.  This might also be a useful addition 
> to the wiki.  Would you like a copy of it?

Of course! But there may be a delay in getting it onto the wiki while I figure out the best way to restore everybody's permission to edit. Thanks.

If my theory is right, then in 256kB chip you will have the same BIOS
on all models. It is a safe fallback for reflashing and in normal mode
the BIOS will be loaded from the NAND flash (big chips). But I'm not sure.
There are 2 different modules ulc_code.ce and ulc_code.bin in firmware 
image.
> I could try moving the BIOS chip from a NTe machine into an XPe machine, 
> as I have one with 256MB of flash.  I'm not sure if this would work, or 
> if I'd trash it.
>

I did more DASM of VGA BIOS, I traced VESA function 4F00h and found
that it reads video memory size from CRTC register 3Eh, see label

get_vram_size here:

http://rayer.ic.cz/350d/t20/VGABIOS.HTM
http://rayer.ic.cz/350d/t20/VGABIOS.IDB

I found in datasheet this is an extended vendor specific CRTC which
holds video memory size in 64kB blocks and is read only. I didn't found
any other references (nor read or writes) in VGA BIOS. So it seems
that it is set by internal chip logic regardless on framebuffer address.
I can try patch it to report more video memory but not sure it will be
enough...

RayeR wrote:
> I tried again VGA BIOS ver 2.08 and also one 4.13 grabbed from
> industrial boards but both still reports 2240kB. This boards
> should have FB size selectable in BIOS [1/2/4MB] so it is not hardcoded
> there but I don't know how it determine this value.
>
> Martin
>
> ------------------------------------------------------------------------------
> _______________________________________________
> open-evot20-discuss mailing list
> open-evot20-discuss@...
> https://lists.sourceforge.net/lists/listinfo/open-evot20-discuss
>
>

I've updated this summary of the Wyse firmware with several additions:

file name	size	OS	PXE	VGAver	BndL

U64STD180.BIN	64	NTe	no	2.07	yes
U96STD180.BIN	96	NTe	no	2.07	yes
W128B216.BIN	128	NTe	yes	4.13	no
W192B216.BIN	192	NTe	yes	4.13	no
W256B216.BIN	256	NTe	?	?	?

W128B247.BIN	128	XPe	yes	4.13	no
W256B328.BIN	256	XPe	yes	4.13	no
W256B329.BIN	256	XPe	yes	4.13	no

     ....gary

gary wrote:
> Klaus Klein wrote:
>> gary wrote:
>>> My XPe models do support PXE, but I don't see BndL in these images.  I 
>>> can re-flash one of these units if it helps.
>> That would be a greate help to get further with those PXE images. 
>> If you pls could let us know what you use to flash those units as well as what comes up on the screen during the flash process. 
>>
>> Cheers,
>> Klaus
> 
> 
> OK.  I need to take down my kitchen machine to swipe its monitor and 
> reconfigure my notebook to run netxfer.  I hope to have you the info in 
> a bit.
> 
>      ...gary


Well I've encountered a bit of a problem....

I started with a WT8235LE, an NTe machine with 96M flash & 128M RAM.  I 
added an extra 256M RAM for 384M total.

I find that I can flash it with the stock 96M firmware, and everything 
is OK.  However when I replace its 32M smartmedia card with either a 64M 
or 128M one, the flash fails!  I using the same 96M firmware in all cases.

Watching the screen, I find that in its original configuration it will 
erase all 3 flash devices (2 soldered on the pcb, and 1 in the socket). 
  After changing the smartmedia card, it only erases the first 2 flash 
devices!  Then it loads 2 images, not the normal 3, reboots, verifies 
only 2 flash devices, attempts to boot NTe, and crashes with a complaint 
about missing files.

It doesn't seem to be recognizing the larger device in its smartmedia 
socket for some reason.  Both of the devices I've tried came out of XPe 
models.

     .....gary

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Courier New, Courier, monospace">Well, I think I figured
out a little bit of what is happening, but I've
not been able to get past it.<br>
<br>
I seem to recall that the smartmedia cards don't have an onboard
controller.&nbsp; One of the failings of these, was that they often required
firmware upgrades in the devices which used them (primarily cameras),
in order to support the larger sizes.<br>
<br>
I believe my Wyse 8235LE (NTe) suffers from this same issue.<br>
<br>
I've noticed that when presented with a larger firmware than it has
flash space, it blindly carries on and loads what it can.&nbsp; I had hoped
that by loading a later firmware, I could at least get the BIOS to a
later version which would then recognize the larger flash devices.<br>
<br>
I think I see in the TFTP.DAT file some text which looks like it has
the ability to just upgrade the BIOS?<br>
</font>
<blockquote><font face="Courier New, Courier, monospace"><i>It has been
determined that the MST code on this unit
may be too old </i><i>to support reliable TFTP transfers.</i><br>
  <i>Press "Y" if you want to continue with the full upgrade.</i><br>
  <i>- OR - </i><br>
  <i>Press "N" if you want to upgrade just the MST code on this unit. </i><br>
  </font> </blockquote>
<font face="Courier New, Courier, monospace"><br>
Can someone please explain to me what the MST acronym is?&nbsp; ULC too?<br>
<br>
I find the following string in my 64M &amp; 96M Wyse images, which I am
able
to load successfully:<br>
</font>
<blockquote><font face="Courier New, Courier, monospace"><i>MST ULC ver
09.06 WYSE</i><br>
  </font></blockquote>
<font face="Courier New, Courier, monospace">While the larger 128M,
192M &amp; 256M Wyse images have:<br>
</font>
<blockquote><font face="Courier New, Courier, monospace"><i>MST ULC ver
11.49 WYSE</i><br>
  </font></blockquote>
<font face="Courier New, Courier, monospace">I'm assuming this is the
BIOS firmware version.&nbsp; Unfortunately, when I
try to load these later versions, I get the following errors:<br>
</font>
<blockquote><font face="Courier New, Courier, monospace">NETXFER 09.06
10067 10068 10069<br>
MAC address ...<br>
Contacting Server&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [4001](02)<br>
My IP 10.0.0.12, Server IP 10.0.0.1, GW IP 0.0.0.0<br>
Server Found&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [4001](01)<br>
Uploading bootp.bin&nbsp; [4002](02)<br>
Upload Successful&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [4002](01)<br>
  <br>
Preboot Transfer Agent v4.9 (atf)<br>
Transfer from 'archive/tftp/bootp.bin':<br>
&nbsp;&nbsp;&nbsp; '.\skeys\k.UTCNTEWyseClosedMask' to 'stream/sec/check'<br>
&nbsp;&nbsp;&nbsp; 100%<br>
&nbsp;&nbsp;&nbsp; 'ulc512.rom' to 'stream/nor/norflash'<br>
&nbsp;&nbsp;&nbsp; 100%<br>
&nbsp;&nbsp;&nbsp; '.\component\prepmsg.txt' to 'prep/nand/format.nand'<br>
Unable to OPEN DEVICE! (nand/format.nand)<br>
Stream ERROR!&nbsp; Unable to Bind Device! (nand/format.nand)<br>
Unable to Create Destination (prep/nand/format.nand)<br>
Transfer ERROR!&lt;abort&gt;<br>
  </font></blockquote>
<font face="Courier New, Courier, monospace"><br>
I also looked at a 64M HP/Compaq image, SP22500 (H064B218.BIN) and find
it also contains "MST ULC ver 11.49 WYSE".&nbsp; However, I'm unable to load
this firmware too.&nbsp; The error is similar to the above, but slightly
different.<br>
<br>
Any ideas as to what is occurring?<br>
<br>
&nbsp;&nbsp;&nbsp;
...gary<br>
<br>
</font>
<br>
gary wrote:
<blockquote cite="mid:49625772.5080800@..." type="cite">
  <pre wrap="">gary wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Klaus Klein wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">gary wrote:
      </pre>
      <blockquote type="cite">
        <pre wrap="">My XPe models do support PXE, but I don't see BndL in these images.  I 
can re-flash one of these units if it helps.
        </pre>
      </blockquote>
      <pre wrap="">That would be a greate help to get further with those PXE images. 
If you pls could let us know what you use to flash those units as well as what comes up on the screen during the flash process. 

Cheers,
Klaus
      </pre>
    </blockquote>
    <pre wrap="">OK.  I need to take down my kitchen machine to swipe its monitor and 
reconfigure my notebook to run netxfer.  I hope to have you the info in 
a bit.

     ...gary
    </pre>
  </blockquote>
  <pre wrap=""><!---->

Well I've encountered a bit of a problem....

I started with a WT8235LE, an NTe machine with 96M flash &amp; 128M RAM.  I 
added an extra 256M RAM for 384M total.

I find that I can flash it with the stock 96M firmware, and everything 
is OK.  However when I replace its 32M smartmedia card with either a 64M 
or 128M one, the flash fails!  I using the same 96M firmware in all cases.

Watching the screen, I find that in its original configuration it will 
erase all 3 flash devices (2 soldered on the pcb, and 1 in the socket). 
  After changing the smartmedia card, it only erases the first 2 flash 
devices!  Then it loads 2 images, not the normal 3, reboots, verifies 
only 2 flash devices, attempts to boot NTe, and crashes with a complaint 
about missing files.

It doesn't seem to be recognizing the larger device in its smartmedia 
socket for some reason.  Both of the devices I've tried came out of XPe 
models.

     .....gary
  </pre>
</blockquote>
</body>
</html>

Bingo!  Success!!!!!!!  :-))))

After the earlier failure, I decided to flash this unit back to its
standard firmware.  In doing so, I noticed that the first line had
changed from "NETXFER 09.06" to "NETXFER 11.49".  So apparently it did
do a BIOS update of some sort.  I had wrongly assumed that nothing had
happened as I did not see it erase or write the flash.

The configuration was a NTe Wyse 8235LE with 192 flash (64M soldered &
128M card) and 384M RAM.  The firmware used was a Wyse NTe image,
W192B216.BIN.

So here is what I see on the thin-client's screen.  It is dramatically
different than what I'm used to seeing when flashing one of these devices.

NETXFER 09.06 10067 10068 10069
MAC address ...
Contacting Server       [4001](02)
My IP 10.0.0.12, Server IP 10.0.0.1, GW IP 0.0.0.0
Server Found            [4001](01)
Uploading bootp.bin  [4002](02)
Upload Successful      [4002](01)

Preboot Transfer Agent v4.9 (atf)
Transfer from 'archive/tftp/bootp.bin':
     '.\skeys\k.UTCNTEWyseClosedMASK' to 'stream/sec/check'
     100%
     'ulc512.rom' to 'stream/nor/norflash'
     100%
     '.\component\prepmsg.txt' to 'prep/nand/format.nand'
     100%|Preparing nand device 0 58256 (32MB) for write
Device was initialized, erasing................................
Bad block count = 0. Constructing bad block table...
Rebuilding tables...
Preparing nand device 1 58256 (32MB) for write
Device was initialized, erasing................................
Bad block count = 0. Constructing bad block table...
Rebuilding tables...
Preparing nand device 2 58100 (128MB) for write
Device was initialized, erasing.................................................
..............................................................................
Bad block count = 1. Constructing bad block table...
Rebuilding tables...
Finished preparing device for write (0)                                    100%

     't20.raw' to 'stream/nand/diskimg.raw'
     100%
     'bios.bin' to 'fswyse/nand/bootp.bin'
     100%
     'version.inf' to 'fswyse/nand/version.inf'
     100%
     'component\transferend' to 'stream/con/message'
     100%
CONGRADULATIONS!   THE TRANSFER HAS COMPLETED PROPERLY, AND THE NEW SOFTWARE
COMPONENTS HAVE BEEN INSTALLED.

Your unit will automatically restart in a moment...


       .....gary


gary wrote:
> Well, I think I figured out a little bit of what is happening, but I've 
> not been able to get past it.
> 
> I seem to recall that the smartmedia cards don't have an onboard 
> controller.  One of the failings of these, was that they often required 
> firmware upgrades in the devices which used them (primarily cameras), in 
> order to support the larger sizes.
> 
> I believe my Wyse 8235LE (NTe) suffers from this same issue.
> 
> I've noticed that when presented with a larger firmware than it has 
> flash space, it blindly carries on and loads what it can.  I had hoped 
> that by loading a later firmware, I could at least get the BIOS to a 
> later version which would then recognize the larger flash devices.
> 
> I think I see in the TFTP.DAT file some text which looks like it has the 
> ability to just upgrade the BIOS?
> 
>     /It has been determined that the MST code on this unit may be too
>     old //to support reliable TFTP transfers./
>     /Press "Y" if you want to continue with the full upgrade./
>     /- OR - /
>     /Press "N" if you want to upgrade just the MST code on this unit. /
> 
> 
> Can someone please explain to me what the MST acronym is?  ULC too?
> 
> I find the following string in my 64M & 96M Wyse images, which I am able 
> to load successfully:
> 
>     /MST ULC ver 09.06 WYSE/
> 
> While the larger 128M, 192M & 256M Wyse images have:
> 
>     /MST ULC ver 11.49 WYSE/
> 
> I'm assuming this is the BIOS firmware version.  Unfortunately, when I 
> try to load these later versions, I get the following errors:
> 
>     NETXFER 09.06 10067 10068 10069
>     MAC address ...
>     Contacting Server       [4001](02)
>     My IP 10.0.0.12, Server IP 10.0.0.1, GW IP 0.0.0.0
>     Server Found            [4001](01)
>     Uploading bootp.bin  [4002](02)
>     Upload Successful      [4002](01)
> 
>     Preboot Transfer Agent v4.9 (atf)
>     Transfer from 'archive/tftp/bootp.bin':
>         '.\skeys\k.UTCNTEWyseClosedMask' to 'stream/sec/check'
>         100%
>         'ulc512.rom' to 'stream/nor/norflash'
>         100%
>         '.\component\prepmsg.txt' to 'prep/nand/format.nand'
>     Unable to OPEN DEVICE! (nand/format.nand)
>     Stream ERROR!  Unable to Bind Device! (nand/format.nand)
>     Unable to Create Destination (prep/nand/format.nand)
>     Transfer ERROR!<abort>
> 
> 
> I also looked at a 64M HP/Compaq image, SP22500 (H064B218.BIN) and find 
> it also contains "MST ULC ver 11.49 WYSE".  However, I'm unable to load 
> this firmware too.  The error is similar to the above, but slightly 
> different.
> 
> Any ideas as to what is occurring?
> 
>     ...gary
> 
> 
> gary wrote:
>> gary wrote:
>>   
>>> Klaus Klein wrote:
>>>     
>>>> gary wrote:
>>>>       
>>>>> My XPe models do support PXE, but I don't see BndL in these images.  I 
>>>>> can re-flash one of these units if it helps.
>>>>>         
>>>> That would be a greate help to get further with those PXE images. 
>>>> If you pls could let us know what you use to flash those units as well as what comes up on the screen during the flash process. 
>>>>
>>>> Cheers,
>>>> Klaus
>>>>       
>>> OK.  I need to take down my kitchen machine to swipe its monitor and 
>>> reconfigure my notebook to run netxfer.  I hope to have you the info in 
>>> a bit.
>>>
>>>      ...gary
>>>     
>>
>>
>> Well I've encountered a bit of a problem....
>>
>> I started with a WT8235LE, an NTe machine with 96M flash & 128M RAM.  I 
>> added an extra 256M RAM for 384M total.
>>
>> I find that I can flash it with the stock 96M firmware, and everything 
>> is OK.  However when I replace its 32M smartmedia card with either a 64M 
>> or 128M one, the flash fails!  I using the same 96M firmware in all cases.
>>
>> Watching the screen, I find that in its original configuration it will 
>> erase all 3 flash devices (2 soldered on the pcb, and 1 in the socket). 
>>   After changing the smartmedia card, it only erases the first 2 flash 
>> devices!  Then it loads 2 images, not the normal 3, reboots, verifies 
>> only 2 flash devices, attempts to boot NTe, and crashes with a complaint 
>> about missing files.
>>
>> It doesn't seem to be recognizing the larger device in its smartmedia 
>> socket for some reason.  Both of the devices I've tried came out of XPe 
>> models.
>>
>>      .....gary
>>   
>

Here are some screen shots of the upgraded system showing:

   PXE boot
   4M video memory (yes on a NTe)
   available video modes under NT

     ...gary


gary wrote:
> Bingo!  Success!!!!!!!  :-))))
> 
> After the earlier failure, I decided to flash this unit back to its
> standard firmware.  In doing so, I noticed that the first line had
> changed from "NETXFER 09.06" to "NETXFER 11.49".  So apparently it did
> do a BIOS update of some sort.  I had wrongly assumed that nothing had
> happened as I did not see it erase or write the flash.
> 
> The configuration was a NTe Wyse 8235LE with 192 flash (64M soldered &
> 128M card) and 384M RAM.  The firmware used was a Wyse NTe image,
> W192B216.BIN.
> 
> So here is what I see on the thin-client's screen.  It is dramatically
> different than what I'm used to seeing when flashing one of these devices.
> 
> NETXFER 09.06 10067 10068 10069
> MAC address ...
> Contacting Server       [4001](02)
> My IP 10.0.0.12, Server IP 10.0.0.1, GW IP 0.0.0.0
> Server Found            [4001](01)
> Uploading bootp.bin  [4002](02)
> Upload Successful      [4002](01)
> 
> Preboot Transfer Agent v4.9 (atf)
> Transfer from 'archive/tftp/bootp.bin':
>      '.\skeys\k.UTCNTEWyseClosedMASK' to 'stream/sec/check'
>      100%
>      'ulc512.rom' to 'stream/nor/norflash'
>      100%
>      '.\component\prepmsg.txt' to 'prep/nand/format.nand'
>      100%|Preparing nand device 0 58256 (32MB) for write
> Device was initialized, erasing................................
> Bad block count = 0. Constructing bad block table...
> Rebuilding tables...
> Preparing nand device 1 58256 (32MB) for write
> Device was initialized, erasing................................
> Bad block count = 0. Constructing bad block table...
> Rebuilding tables...
> Preparing nand device 2 58100 (128MB) for write
> Device was initialized, erasing.................................................
> ..............................................................................
> Bad block count = 1. Constructing bad block table...
> Rebuilding tables...
> Finished preparing device for write (0)                                    100%
> 
>      't20.raw' to 'stream/nand/diskimg.raw'
>      100%
>      'bios.bin' to 'fswyse/nand/bootp.bin'
>      100%
>      'version.inf' to 'fswyse/nand/version.inf'
>      100%
>      'component\transferend' to 'stream/con/message'
>      100%
> CONGRADULATIONS!   THE TRANSFER HAS COMPLETED PROPERLY, AND THE NEW SOFTWARE
> COMPONENTS HAVE BEEN INSTALLED.
> 
> Your unit will automatically restart in a moment...
> 
> 
>        .....gary

Wow, it has nice hardware summary table. On mu system I only see
tho color logo and then OS will boot. What does mean the "USB: Enabled"
Isn't it the wanted USB legacy support for keyboard?
But I have only 16MB flash so I cannot flash such big firmware. So we
need to know hot to modify PXE FW to change HDD image size.

Now some news from me. I confirmed by reading CRTC 3Eh that it reports
always 23h*64kB VRAM regardless on GX1 FB register. I have no idea
how it get it. But anyway I patched VESA code to not use this CRTC but
my constant 40h*64kB which means 4MB. Now all VESA info programs
see 4MB videomemory. Even Xorg vesa driver can set 1280x1024/16bpp
now but she screen is garbages. Initial Xorg grid image seems to be OK
and also my IceWM background color but I see vertical gray strip,
no launch bar, no gkrellm panel nor mouse :( only 1280x1024/8bpp worked.
So it seems need more modification than just increasing reported video 
memory.

Last I found debian backported Xorg 7.3 and updated Xorg system with nsc 
driver.
I can work in 1280x1024/16bpp (due to previous patch) but the issue with 
140Hz
textmode console after switch back from Xorg still occurs. Please what 
version
of Xorg has fully working nsc driver?


gary wrote:
> Here are some screen shots of the upgraded system showing:
>
>   PXE boot
>   4M video memory (yes on a NTe)
>   available video modes under NT

Hi Martin,

The hardware summary comes up right after the Wyse logo screen.

I think this screen is only in the later firmware versions, like 4.41. 
I don't see this in the 4.37 versions IIRC.

I loaded a large firmware image, just to see if it could be done and 
what it might contain, and I had the memory available to do so.  The 
smallest 4.41 version I see on the HP site is for a 64/64 unit - still 
too big for your flash.

I'm not sure what the "USB: Enabled" means.  My first thought was that 
since NT requires a patch to use USB devices like memory sticks, that 
maybe it had this ability - but I tried one, and no luck.  By the way, 
the patch for this is available at:
http://www.freewysemonkeys.com/modules.php?name=Downloads&d_op=viewdownloaddetails&lid=91&ttitle=NTe_USB.rar

The other interesting item on this screen is the reference to XpressROM. 
  I seem to recall that someone had mentioned this earlier.  It seems 
that this was National's BIOS for the Geode chipsets.  They also 
apparently offered free code and development tools!!!  A little 
searching with Google brought up a number of interesting links:

http://www.insydesw.com/solutions/ia/xprom_prodov_v20a.pdf

http://amd.insydetech.com/productcenter/amd/geodesite/index.cfm

http://amd.insydetech.com/productcenter/amd/geodesite/AMD%20XpressROM%20datasheet%20v3.pdf

http://amd.insydetech.com/productcenter/amd/geodesite/XpressROM_Users_guidev1_9.pdf

http://www.coreboot.org/pipermail/coreboot/2003-September/005270.html

http://www.coreboot.org/pipermail/coreboot/2006-January/013474.html

http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_9864^11363,00.html


      ....gary


RayeR wrote:
> Wow, it has nice hardware summary table. On mu system I only see
> tho color logo and then OS will boot. What does mean the "USB: Enabled"
> Isn't it the wanted USB legacy support for keyboard?
> But I have only 16MB flash so I cannot flash such big firmware. So we
> need to know hot to modify PXE FW to change HDD image size.
>

BTW NT uses special graphics driver so it can access 4MB when 
framebuffer base
address is set properly. It is equivalent to use nsc driver under linux 
with my patch.
But we don't know nothing if VESA BIOS is fixed. This is two diffwerent 
thing.
I don't know if there is a tool that can read VBE info under NT and not 
be affected
by graphics driver. But I can make a small tool that will read CRTC 
register 3Eh
to see how many videomemory will chip report to VESA BIOS. But it will 
not be
guaranted that it is not affected some way by windows driver.
> I think this screen is only in the later firmware versions, like 4.41. 
> I don't see this in the 4.37 versions IIRC.
>   
And it is only in wyse FW or in HP too?
> The smallest 4.41 version I see on the HP site is for a 64/64 unit - still 
> too big for your flash.
>   
Unfortunatelly yes. And I think that even the smartmedia card wouldn't 
help me because it will
be non-standard combination. I can flash any BIOS to the small chip via 
programmer but
BIOS probably must understand known onboard and SM card combination.
I would need that SMD NAND flash chips and solder them on board. It can 
be found
inside compact flash card about 64-128MB capacity I guess and it's too 
old...
Really nobody knows how to modify PXE firmwares?
> I'm not sure what the "USB: Enabled" means.  My first thought was that 
> since NT requires a patch to use USB devices like memory sticks, that 
> maybe it had this ability - but I tried one, and no luck.  By the way, 
> the patch for this is available at:
> http://www.freewysemonkeys.com/modules.php?name=Downloads&d_op=viewdownloaddetails&lid=91&ttitle=NTe_USB.rar
>   
This file is Inside Out USB stack drivers for windows NT. I used them on 
normal PC because NT 4.0
lacks USB support. But it have nothing to do with USB legacy support. 
USB legacy is provided as
BIOS service in real mode and will not work in 32bit environment so NT 
needs 32bit driver. But you
could try to modify boot.ini file in firmware to increase timeout value 
and then ty to press some keys
if it will response. I think F8 will let you choose safe boot etc...
> The other interesting item on this screen is the reference to XpressROM. 
>   
I guess this they provide some bare BIOS which is then customized. But 
when we don't have
hardware shcematic it will be very hard to make BIOS from a scratch. I 
know about
coreboot project but I think nobody succeed on EVO T20.

Martin

rayer wrote:
>> I think this screen is only in the later firmware versions, like 4.41. 
>> I don't see this in the 4.37 versions IIRC.
>>   
> And it is only in wyse FW or in HP too?

I'd assume that the HP models have this too.  I've noticed that the HP & 
Wyse models both use the same firmware version numbers, (and run on the 
same hardware of course) so I expect this to also be the same.

I can't be sure, as I don't think I can load the HP firmware on my Wyse 
models.  It seems to me that I had tried this once, and the flash 
process checks a security key, and exits.

>> The smallest 4.41 version I see on the HP site is for a 64/64 unit - still 
>> too big for your flash.
>>   
> Unfortunatelly yes. And I think that even the smartmedia card wouldn't 
> help me because it will
> be non-standard combination. I can flash any BIOS to the small chip via 
> programmer but
> BIOS probably must understand known onboard and SM card combination.
> I would need that SMD NAND flash chips and solder them on board. It can 
> be found
> inside compact flash card about 64-128MB capacity I guess and it's too 
> old...

My testing with the Wyse models found that firmware version 4.37 would 
not recognize the 32M & 64M smartmedia chips, but the 4.41 firmware 
version would.

It appears that firmware version 4.37 has a netxfer client version of 
9.06, while firmware version 4.37 has a netxfer client version of 11.49.

The flash chips used on the pcb (U8 & U9) are made by Toshiba and I 
suspect are the same silicon die as used in the smartmedia cards.  So if 
the firmware and netxfer do not recognize the larger chips, it would 
make no difference if they were soldered or socketed.

> Really nobody knows how to modify PXE firmwares?

I only barely know what PXE is!  ;-)  Firmware is not my forte'.  I look 
to guys like you for that sort of expertise!

      ......gary

> models.  It seems to me that I had tried this once, and the flash 
> process checks a security key, and exits.
>   
I met this problem too when I tried to flash back WinCE to my machine over
NTE firmware. I cannot retrurn but I don't want to :)
> It appears that firmware version 4.37 has a netxfer client version of 
> 9.06, while firmware version 4.37 has a netxfer client version of 11.49.
>
> The flash chips used on the pcb (U8 & U9) are made by Toshiba and I 
> suspect are the same silicon die as used in the smartmedia cards.  So if 
> the firmware and netxfer do not recognize the larger chips, it would 
> make no difference if they were soldered or socketed.
>   
Aha, so maybe with newer netxfer it will flash my model with smartmedia 
card.
But I cannot buy it anywhere...

M.

gary wrote:
  > My testing with the Wyse models found that firmware version 4.37 would
> not recognize the 32M & 64M smartmedia chips, but the 4.41 firmware 
> version would.

A typo.  The above should have been 64M & 128M smartmedia chips!

Sorry,

    ...gary

RayeR wrote:
> Aha, so maybe with newer netxfer it will flash my model with smartmedia 
> card.
> But I cannot buy it anywhere...


eBay has a lot of smartmedia cards.

I know 3.3V cards work in my machine, but I don't know if it also 
supports 5V ones.  There is a switch in the socket which is not 
activated by a 5V card - I don't know if this switch serves as a "card 
presence detect" or "5V card detect".

    ...gary

gary wrote:
> rayer wrote:
>> Really nobody knows how to modify PXE firmwares?
> I only barely know what PXE is!  ;-)  Firmware is not my forte'.  I look 
> to guys like you for that sort of expertise!

Hold your horses. ;-)

I'm almost there.

I spend quite some time in the last few weeks to go trough the structure of the 'new' PXe firmware.

The structure seems to be 'simple' enough to easily swap components and drive images. :-)

I just downloaded the 'non'-Compaq firmware files to verify my findings and so far it looks very promising. :-)

Now I just need to find a PXe machine to do the real things. :-)

Sami Olmari wrote:
> And please everyone, do not ask them, I do NOT have an warehosue full of  
> them so I won't send one for everyone, only to an guy that really can make  
> na diffirence.

Sami,

 can I take you up on your offer to donate one of your Evo T20 256/256 WinXP machines?

Rgds.,
Klaus

RayeR wrote:
> But I have only 16MB flash so I cannot flash such big firmware. So we
> need to know hot to modify PXE FW to change HDD image size.

Hi Martin, 

 I guess when you say you have only 16MB flash, that you poses a Evo T20 or a Wyse WT3230LE with Win CE.

Is that right?

If so, then I'm not sure you will ever have a PXe Firmware on your machine as those have a 512K BIOS and I think your machine has only a 256K chip installed. :-(

What is the latest firmware you could flash into your machine?

Rgds.,
Klaus

Klaus Klein wrote:
>  I guess when you say you have only 16MB flash, that you poses a Evo T20 or a Wyse WT3230LE with Win CE.
>   
I got EVO T20 from my friend who flashed there a hacked firmware with 
CE/Linux so I never seen WinCE running un this
machine and I cannot flash it back. Then I made customized firmware from 
48MB NTE nonPXE version where I
shrink HDD image via bundle-tools.
> If so, then I'm not sure you will ever have a PXe Firmware on your machine as those have a 512K BIOS and I think your machine has only a 256K chip installed. :-(
>   
No problem. I have some spare 512k chips and I can programm it in HW 
programmer.
But as I analyzed Wyse firmware BIOS it is 512kB BUT it composed of two 
SAME copies
of ulc_code.ce so 512k chip may be not needed at all.

Martin

rayer wrote:
> Klaus Klein wrote:
>> I guess when you say you have only 16MB flash, that you poses a Evo
>> T20 or a Wyse WT3230LE with Win CE.
> I got EVO T20 from my friend who flashed there a hacked firmware with 
> CE/Linux so I never seen WinCE running un this machine and I cannot 
> flash it back. 

Did you try?
What happend?

>> If so, then I'm not sure you will ever have a PXe Firmware on your
>> machine as those have a 512K BIOS and I think your machine has only
>> a 256K chip installed. :-(
> No problem. I have some spare 512k chips and I can programm it in HW 
> programmer.

That would be VERY interesting!!!

> But as I analyzed Wyse firmware BIOS it is 512kB BUT it composed of two 
> SAME copies of ulc_code.ce so 512k chip may be not needed at all.

Yes with the NTe firmware the BIOS was sent twice. 
Nevertheless, in the PXe firmware file is a section of 512K which is using slightly more than 256K (rest zero).
So I guess you'll need a 512K chip.
If you're interested, I'll see that I extract the 'ulc512.rom' and send it to you so you can play with your programmer.

Cheers,
Klaus

Klaus Klein wrote:
> 
> Now I just need to find a PXe machine to do the real things. :-)


You should be able to load the HP firmware version SP22500.  This is for 
a 64F/64R model, the firmware version is 4.41 B218A, the client netxfer 
is version 11.49, and it includes PXE.

     ...gary

So far, the only models I've found with 512KB BIOS chips have been the 
XPe models.  My NTe models only have 256KB BIOS chips.

My recent experiments with loading the new(er) 192MB firmware ver 4.41, 
was into a NTe model with a 256KB BIOS.  I was a little concerned at 
first, when I found this line in the firmware:
"ulc512.rom        MST ULC ver 11.49 WYSE"


Can someone explain the MST and ULC acronyms mean??

       .....gary


Klaus Klein wrote:
> rayer wrote:
>> Klaus Klein wrote:
>>> If so, then I'm not sure you will ever have a PXe Firmware on your
>>> machine as those have a 512K BIOS and I think your machine has only
>>> a 256K chip installed. :-(
>> No problem. I have some spare 512k chips and I can programm it in HW 
>> programmer.
> 
> That would be VERY interesting!!!
> 
>> But as I analyzed Wyse firmware BIOS it is 512kB BUT it composed of two 
>> SAME copies of ulc_code.ce so 512k chip may be not needed at all.
> 
> Yes with the NTe firmware the BIOS was sent twice. 
> Nevertheless, in the PXe firmware file is a section of 512K which is using slightly more than 256K (rest zero).
> So I guess you'll need a 512K chip.
> If you're interested, I'll see that I extract the 'ulc512.rom' and send it to you so you can play with your programmer.
> 
> Cheers,
> Klaus

> Did you try?
> What happend?
>   
As I said before I got security key error when loading CE FW.
> Yes with the NTe firmware the BIOS was sent twice. 
> Nevertheless, in the PXe firmware file is a section of 512K which is using slightly more than 256K (rest zero).
> So I guess you'll need a 512K chip.
> If you're interested, I'll see that I extract the 'ulc512.rom' and send it to you so you can play with your programmer.
>   
Hm...
I was extracted ulc512.ce and it was just 2 copies of the same. You are 
laking about ulc512.rom that I didn't found/extract/examined.
Can you upload it or tell me offset where to cut it?
I'm now confused about what file goes to BIOS chip. I belived that it is 
the ulc512.ce and is used as fallback and for programming
and instead in normla boot the ulc512.rom is loaded from NAND flash...

But still after the flash of BIOS I need to make 16MB shrinked image 
some way...
I would drop filesys1.img, filesys2.img and truncate filesys0.img. Put 
FAT partition there
with GRUB4DOS and Linux same as I use now.

Martin

gary wrote:
> Klaus Klein wrote:
>> Now I just need to find a PXe machine to do the real things. :-)
> You should be able to load the HP firmware version SP22500.  This is for 
> a 64F/64R model, the firmware version is 4.41 B218A, the client netxfer 
> is version 11.49, and it includes PXE.

To load on what? On a NTe (non-PXe) machine?

Rgds.,
Klaus

Klaus Klein wrote:
> gary wrote:
>> Klaus Klein wrote:
>>> Now I just need to find a PXe machine to do the real things. :-)
>> You should be able to load the HP firmware version SP22500.  This is for 
>> a 64F/64R model, the firmware version is 4.41 B218A, the client netxfer 
>> is version 11.49, and it includes PXE.
> 
> To load on what? On a NTe (non-PXe) machine?
> 
> Rgds.,
> Klaus

Yep!

Your model 238364-001 is a NTe, 64F/96R unit.  Even with only 64 RAM, 
you should be able to load the HP SP22500 firmware package.

http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&prodTypeId=12454&prodSeriesId=96470&prodNameId=100771&swEnvOID=1056&swLang=13&mode=2&taskId=135&swItem=PSG_I17641-100638

This is the same situation as when I loaded the newer PXE firmware on my 
older non-PXE model.  If the netxfer transfer fails the 1st time, just 
start it up again, and it should complete the second time.

     ...gary

gary wrote:
> Klaus Klein wrote:
>> Now I just need to find a PXe machine to do the real things. :-)
> You should be able to load the HP firmware version SP22500.  This is for 
> a 64F/64R model, the firmware version is 4.41 B218A, the client netxfer 
> is version 11.49, and it includes PXE.

To load on what? On a NTe (non-PXe) machine?

Rgds.,
Klaus

rayer wrote:
> Hm...
> I was extracted ulc512.ce and it was just 2 copies of the same. You are 
> laking about ulc512.rom that I didn't found/extract/examined.
> Can you upload it or tell me offset where to cut it?
> I'm now confused about what file goes to BIOS chip. I belived that it is 
> the ulc512.ce and is used as fallback and for programming
> and instead in normla boot the ulc512.rom is loaded from NAND flash...

Hmm...
I have to correct myself.
I extracted the ulc512.rom and it is indeed twice the same content of 256MB right behind each other.
So actually one half should nicely fit in the BIOS chip of a NTe machine.
(I'll play with that soon :-) )

My guess is that, to detect transmission errors, the first half is compared to the second half before flashing the BIOS.

If you still want the 256K, then just let me know. ;-)

Rgds.,
Klaus

gary wrote:
> Klaus Klein wrote:
>> gary wrote:
>>> Klaus Klein wrote:
>>>> Now I just need to find a PXe machine to do the real things. :-)
>>> You should be able to load the HP firmware version SP22500.  This is for 
>>> a 64F/64R model, the firmware version is 4.41 B218A, the client netxfer 
>>> is version 11.49, and it includes PXE.
>> To load on what? On a NTe (non-PXe) machine?
> Yep!
> Your model 238364-001 is a NTe, 64F/96R unit.  Even with only 64 RAM, 
> you should be able to load the HP SP22500 firmware package.
> 
> This is the same situation as when I loaded the newer PXE firmware on my 
> older non-PXE model.  If the netxfer transfer fails the 1st time, just 
> start it up again, and it should complete the second time.

Well, I'd be darned if that is all it takes. 8-)
Never dared to try it twice.

Will do THAT tonight!
(if it turns out to be a brick after that, I'll just send it to you. :-) )

Rgds.,
Klaus

> My guess is that, to detect transmission errors, the first half is compared to the second half before flashing the BIOS.
>   
I don't think it would be so sophisticated...
> If you still want the 256K, then just let me know. ;-)
>   
I already have it somewhere or it is easy to extract from any firmware.

Martin

Klaus Klein wrote:
> Well, I'd be darned if that is all it takes. 8-)
> Never dared to try it twice.
> 
> Will do THAT tonight!
> (if it turns out to be a brick after that, I'll just send it to you. :-) )
> 
> Rgds.,
> Klaus

If you power-up your machine, and hold the "p" down on the keyboard (no 
network cable or connection necessary), you should see a message like 
the following:

NETXFER 09.06 10067 10068 10069

I believe the 9.06 is the version number of the netxfer client.

If you should see:

NETXFER 11.49 10067 10068 10069

Then the netxfer client on the machine has been updated to 11.49.

However the older version of netxfer does recognize the 32M flash chips, 
which I expect are what you have soldered on your pcb.

So far, I've not managed to brick one of my units.  But then maybe I'm 
not trying hard enough!  :-)

     ...gary

gary wrote:
> Klaus Klein wrote:
>> Well, I'd be darned if that is all it takes. 8-)
>> Never dared to try it twice.
>>
>> Will do THAT tonight!
>> (if it turns out to be a brick after that, I'll just send it to you. :-) )
>>
>> Rgds.,
>> Klaus
> 
> If you power-up your machine, and hold the "p" down on the keyboard (no 
> network cable or connection necessary), you should see a message like 
> the following:
> NETXFER 09.06 10067 10068 10069

Correct

> I believe the 9.06 is the version number of the netxfer client.

Think so too.

> If you should see:
> 
> NETXFER 11.49 10067 10068 10069
> Then the netxfer client on the machine has been updated to 11.49.

That's what I wished fore. ;-)

> However the older version of netxfer does recognize the 32M flash chips, 
> which I expect are what you have soldered on your pcb.

Always did and still does!!!

I don't know what and how you did it, but I tried now a couple of times but still only get NetXfer 09.09 and the error message of the Preeboot Transfer Agent.

> This is the same situation as when I loaded the newer PXE firmware on my 
> older non-PXE model.  If the netxfer transfer fails the 1st time, just 
> start it up again, and it should complete the second time.

I just fail to understand how you did it. :-(

Cheers,
Klaus

Klaus Klein wrote:
> I don't know what and how you did it, but I tried now a couple of times but still only get NetXfer 09.09 and the error message of the Preeboot Transfer Agent.


So after it fails on loading firmware SP22500, and you restart it by 
cycling the power on the thin client, you do not see NETXFER 11.49?


>> This is the same situation as when I loaded the newer PXE firmware on my 
>> older non-PXE model.  If the netxfer transfer fails the 1st time, just 
>> start it up again, and it should complete the second time.
> 
> I just fail to understand how you did it. :-(

I'm beginning to wonder how I did it too!  ;-)  What sort of error 
message are you getting?

This was my error message the first time I tried it:

    NETXFER 09.06 10067 10068 10069
    MAC address ...
    Contacting Server       [4001](02)
    My IP 10.0.0.12, Server IP 10.0.0.1, GW IP 0.0.0.0
    Server Found            [4001](01)
    Uploading bootp.bin  [4002](02)
    Upload Successful      [4002](01)

    Preboot Transfer Agent v4.9 (atf)
    Transfer from 'archive/tftp/bootp.bin':
        '.\skeys\k.UTCNTEWyseClosedMask' to 'stream/sec/check'
        100%
        'ulc512.rom' to 'stream/nor/norflash'
        100%
        '.\component\prepmsg.txt' to 'prep/nand/format.nand'
    Unable to OPEN DEVICE! (nand/format.nand)
    Stream ERROR!  Unable to Bind Device! (nand/format.nand)
    Unable to Create Destination (prep/nand/format.nand)
    Transfer ERROR!<abort>

My interpretation (just guessing!!) of this is as follows:

The line: "'.\skeys\k.UTCNTEWyseClosedMask' to 'stream/sec/check'"
looks like a security check which it passed.

The line: "'ulc512.rom' to 'stream/nor/norflash'"
looks to be a file transfer, also ok.  (I was able to watch the % count 
up to 100%)

The line: "'.\component\prepmsg.txt' to 'prep/nand/format.nand'"
looks to be where it checks the format of the flash, and fails.

After the above failure, I then started it again, and noted that it now 
displayed NETXFER 11.49.  This then loaded the new file sucessfully.


I believe I tried some time ago to load the HP firmware SP22500 in my 
Wyse machine, and I got a security check error.

I just now tried to load a Wyse NTe firmware into my Wyse XPe machine, 
and it also failed the security check.

    .....gary

At last I have added the detailed parts lists that Gary and Karl worked to compile to our wiki.
Hoping to keep good habits alive, I made myself a backup copy of the whole wiki after adding
these edits. (This took one click on the wiki main page and consumed only 153K of disk space.)

I was helped in this job by the html-to-wiki converter (PMWiki dialect) at
   http://diberri.dyndns.org/wikipedia/html2wiki/index.html

The edited pages are linked as "details" from
   http://open-evot20.sourceforge.net/wiki/index.php?n=Hardware.Main
If corrections are required, don't be shy: just make them!

Regards, Philip


gary wrote:
> Philip Loewen wrote:
>> gary wrote:
>>
>>> A while back, Karl and I put together a parts list for three models: 
>>> WT8235LE, T20-XPe, and T20-WinCE.  This might also be a useful 
>>> addition to the wiki.  Would you like a copy of it?
>>
>> Of course! But there may be a delay in getting it onto the wiki while 
>> I figure out the best way to restore everybody's permission to edit. 
>> Thanks.
>>
> 
> Here ya go!  This is in an Excel spreadsheet with 4-tabs, one for each 
> model examined and one for notes.
> 
> I also have a lot of various pdf files with information from Wyse, but I 
> suspect these can not be placed in the wiki.
> 
>    ....gary