Differences between version 15 and predecessor to the previous major change of CompaqEvoT20Notes.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 15 | Last edited on Sunday, June 18, 2006 9:16:45 pm | by MilanHauth | Revert |
| Older page: | version 14 | Last edited on Sunday, June 18, 2006 9:06:11 pm | by MilanHauth | Revert |
@@ -8,8 +8,10 @@
Some of these units support [PXE] booting. If you happen to have one, it is trivial to turn it into a linux thin client - just make use of a PXE netboot environment, such as PXES or diskless.
If you don't have a PXE boot model, or you wish to run linux locally, you could try [hacking the firmware|http://www.kazak.ws/evo/]
+
+''Google cache version of the document removed, since it's back online.''
!!General notes
! Video depth
@@ -19,217 +21,12 @@
Interestingly, if you allow the bootp to wait, it times out after an hour and tries to tftp /tftpboot/kernel on port 10069.
----
-From Google Cache:
-
-!!Linux on Compaq EVO T20 HOWTO
-Dag Sverre Seljebotn
-Evo T20 Hacking Team
-
-Copyright © 2004 by Dag Sverre Seljebotn
-Revision History
-Revision 0.3 11/08/2004 Revised by: DSS
-Revision 0.2 10/08/2004 Revised by: DSS
-Revision 0.1 09/08/2004 Revised by: DSS
-
-!Introduction
-
-I did it!
-
-I'm really happy now. I've still got problems with my NFS setup so I haven't run X yet, but if anything difficult pops up there I'll update the howto. This should get you well started.
-
-The version I have is 48/64, meaning 48 MB flash and 64 MB RAM. Changes for the other versions will probably be needed.
-
-Note to HP/Compaq/WYSE: If you don't like what I have done here just email me and I'll promptly take the page down.
-
-!Uploading firmware
-
-The first problem we're facing is that the BIOS won't boot from anything else than the soldered-on flash. Luckily there's a firmware update mechanism, "NETXFER". The EVO T20 tries to flash itself when you hold down the "P" key when applying power to it (a power outlet with a power switch is a must when working on this). "NETXFER" will appear on the screen, then it will try to connect with a BOOTP server.
-
-You can download the windows tool for updating the firmware from hp.com (combined BOOTP+TFTP server, it will need an ancient Java implementation running on the machine, search the web), or (very very much preferred), set up Linux to update the firmware:
-
-* Configure a BOOTP server to run at port 10067 and serve out an IP address and a filename (to the firmware file). Easiest is to use the stock ISC DHCP with something like:
-
- <verbatim>
- range dynamic-bootp 192.168.0.100 192.168.0.140;
- </verbatim>
-
- in the file "/etc/dhcpd.conf" (the point was the dynamic-bootp), then start it with:
-
- <verbatim>
- dhcpd -p 10067 -cf custom-config-file-for-this-purpose
- </verbatim>
-
-* Run a TFTP server at port 10069, handing out the firmware file specified by the filename in the file "dhcpd.conf". Register the port in the file "/etc/services", then copy the line in inetd.conf for the TFTP and put it on that port as well.
-
-It might look easier to use a Windows box, but getting it to work in Linux takes max half an hour and is very well worth it!
-
-Then we need the stock firmware for modifications, get it from hp.com. It should be about 48 MB, and comes packed in an EXE-file that should execute just fine with the program WINE.
-
-In the firmware, the data for the flash chips is located at offset 834710. That was the short story, if you don't have the 48 MB version it most likely won't be that so here's how I found out:
-
-The firmware is a concatenation of setup code and a package. Inside the package, the filesystem is in two files called "filesys0" and "filesys1" (at the end of the package).
-
-First do a flash of the stock firmware. Note the files that are transferred and their sizes... the filesystems are in "filesys0" and "filesys1". Search for those names in the firmware using an hex editor (i.e. ghex2). Somewhere before "filesys0" the size of "filesys0" is as a DWORD (four bytes) (you found the size when transferring, right?). Now, the four bytes before this is the offset from the start of the package.
-
-To find the start of the package (except by just figuring it out in the hex editor), basically find the size of the setup code before it, which is the sizes of the files "TFTP.dat" and "ulc_code.tmp" that can be found in the windows Netxfer download. Other Evo versions might have other setup code, so make a new firmware using the setup code bundled with the program NETXFER:
-
-<verbatim>
- mkutc.bat firmware-file
-</verbatim>
-
-It will "reformat" firmware-file with the setup code we know and stick it in the file "bootp.bin".
-
-Now, hopefully you've found the offset of the file "filesys0", you should find the Windows NT master boot record there (with strings referring to your lack of proper hard disk setup, etc.). Now mount it as a loop device:
-
-<verbatim>
- losetup -o 834198 /dev/loop0 firmware.bin
-</verbatim>
-
-Now we can make any changes we want on the device "/dev/loop0", treating it like a hard drive, and it will immedeately be reflected in the firmware. You can even mount 512 bytes further on the device "/dev/loop1" and mount the NTFS file system the Evo uses:
-
-<verbatim>
- losetup -o 834710 /dev/loop1 firmware.bin
- mount /dev/loop1 /mnt
-</verbatim>
-
-I like to zero out everything but the MBR at this stage:
-
-<verbatim>
- dd if=/dev/zero of=/dev/loop bs=512 seek=1
-</verbatim>
-
-just to remove every trace of Windows NTe. Then we must install our own stuff, I picked GRUB (because it was the one I first got to the assembler level of in my efforts to make the bootloaders work on the Evo...).
-
-!Making GRUB work
-
-Getting GRUB running was quite a challenge for me, I had to do my share of debugging through the assembler code of GRUB (which boils down to inserting assembler code for printing debug messages, then go through the three minute flashing process of the Evo, see the results, repeat. The flashing is the killer...).
-
-Instruction for getting GRUB sources from CVS are at the home page over at FSF (you want Legacy GRUB, not GRUB 2). Some patching will be needed...most are for relocating GRUB to disk sector 1 and onwards (and is a well documented configuration of GRUB, I just like to do it in the assembler when I've got the source anyway), while the "gate A20" problem is real patching.
-
-Relocation: (Why are we doing this? Well, it turns out that the BIOS ignores sector 0/the MBR, and always executes sector 1. Why escapes me.)
-
-First let's patch file "stage1.S" located in "grub/stage1/stage1.S":
-
-Change the location of file "stage2" from sector 1 to sector 2, that's at the stage2_sector label.
-
-Also the BIOS doesn't pass the boot device to GRUB so we must manually specify 0x80 (first hard drive) in place of GRUB_INVALID_DRIVE. Do this at the boot_drive label.
-
-The changes to the file "stage1" can be done with a hex editor instead, see the hacking section in the GRUB docs.
-
-That's it for file "stage1". Then we need to patch file "stage2" located in "grub/stage2/stage2.S":
-
-First we must tell the stage2 preloader to load from sector 3 instead of sector 2. We do this by changing the blocklists at the end of the file "stage2/start.S". Just change the number after blocklist_default_start to 3.
-
-Then it is time for the "gate A20" issue. A very good description of the problem that you might want to read is here:
-
-http://www.win.tue.nl/~aeb/linux/kbd/A20.html
-
-Basically, since the EVO T20 is "legacy free", it doesn't have a keyboard controller, and GRUB hangs when trying to use it to set the Gate A20. Now, it seems that Gate A20 is always enabled on the EVO T20 (as it should have been on all computers, really).
-
-Bottom line is, disable the A20 handling in GRUB and it will all work. The function itself is located in the file "stage2/asm.S", and is called from files "builtins.c" and "common.c" in the same dir. Comment it all out.
-
-Because we have no keyboard (only USB, won't work in GRUB or any bootloader that I know of because most BIOSes emulate a regular keyboard during startup) we must precode GRUBs actions. "dhcp --with-configfile" is my strong suggestion, as it lets you specify the GRUB boot options from a DHCP server.
-
-Create a new file "presetmenu":
-
-<verbatim>
- default 0
- timeout 0
- title Load config from DHCP
- dhcp --with-configfile
-</verbatim>
-
-(Why I have to write it as a menu instead of just the dhcp command is beyond me, but I must or it will enter an infinite DHCP loop...)
-
-That's it for the patches. Let's configure it, my suggestion:
-
-<verbatim>
- ./configure \
- --enable-preset-menu=presetmenu \
- --enable-natsemi \
- --enable-pci-direct \
- --disable-ext2fs \
- --disable-fat \
- --disable-ffs \
- --disable-ufs2 \
- --disable-minix \
- --disable-reiserfs \
- --disable-vstatfs \
- --disable-jfs \
- --disable-xfs \
- --disable-iso9660 \
- --disable-md5-password \
- --disable-serial
-</verbatim>
-
-The important ones is the presetmenu, to enable direct PCI (we have no PCI access from BIOS), and the natsemi network card.
-
-Now for installation.. make sure the loop device is set up (see first section), then:
-
-<verbatim>
- dd if=grub-src/stage1/stage1 of=/dev/loop0 bs=512 seek=1
- dd if=grub-src/stage2/stage2 of=/dev/loop0 bs=512 seek=2
-</verbatim>
-
-Finally, stick this somewhere in dhcp.conf on the server:
-
- option option-150 "(nd)/grub-menu.lst"
-
-
-And put something fancy in the file "grub-menu.lst". My LTSP (Linux Terminal Server Project) setup:
-
-<verbatim>
- default 0
- timeout 0
- title LTSP
- root (nd)
- kernel /lts/kernel-version/bzImage-kernelversion init=/linuxrc rw root=/dev/ram0
- initrd /lts/kernel-version/initrd-kernelversion.gz
-</verbatim>
-
-!Running X
-
-Running X was a relatively quick job compared to the madness above. Only a single problem occured: Xorg detects the driver to be "geode", which is actually wrong. What we want is the "nsc" driver. And, National Semiconductor (seems like they made every chip in that box, not that strange).
-
-Using LTSP, all I had to do was change "server" from "auto" to "nsc", and it would work.
-
-More info from a comparable system: http://www.larwe.com/technical/geode_linux.html
-
-The "vesa" driver also works, but nsc has some advantages: From a quick glance it looks slightly faster, it detects refresh rates much better and it displays a black screen during startup instead of garbage.
-
-I couldn't get either driver to run in anything better than 16 bit color no matter the resolution (the nsc driver complains it doesn't know 24 bit, but 32 bit I just get the standard "No screens found"). Getting it to run.
-
-!More stuff that could be done
-
-I probably won't do any of these, considering that they're not all that useful, but here's the ideas anyway:
-
-* Now that we can have Linux running we probably have full access to the BIOS code. Reflashing it with a different boot picture would be good (it still has that "Windows Powered" logo when booting...grrr). Considering that most of the time you won't see this (see point 3) it's not very useful, but then again it's probably not terribly difficult to do if the right tools exists.
-
-* Look into video. Try to allocate more video memory for higher modes, get it to run in 24/32-bit, etc.
-
-* The boot phase is strange: Orange LED shows during very basic initialization. This happen when it gets power (pressing power button not required). After this, it progresses with booting with the LED and screen output turned off. Then it pauses right before Linux is about to boot. Ok, with a splash screen in the Linux kernel it could look good since it takes you past all the text stuff, but still: Why does it pause at all? How does it detect that Linux is about to boot, and is there any way to make it go all the way, so that when the power button is pressed we have an X session ready and waiting?
-
-
-I have Linux appliances projects out there (commercial) running on Geode, and the driver is there, so if there is a higher potential than this it can probably be done.
-
-
-!Conclusions
-
-Like I said, a more thorough investigation is probably in order, but this is all I'll do for now. Please mail me any experiences you have with it...also, if someone running the Evo T20 the intended way (Windows with Rapport on server) is reading this: It would be interesting to know the highest resolution/color they can set on it.
-
-----
-!!Resources
-* [PXES|http://pxes.sf.net]
-* [Linux on Compaq EVO T20 HOWTO|http://www.kazak.ws/evo/]
-----
CategoryHardware
-
!tried the stuff above - i'm not really a hacker - but ... yes it works !
-
my way:
