|
|
|
31.10.2008 jsem dostal od kamaráda tento pěkný malý strojek. Jedná se o tenký klient, určený pro připojení k Windows Terminal Serveru. Jednotka tedy pouze zobrazuje data ze serveru a posílá vstupy od uživatele po síti. Nicméně narozdíl od starých unixových terminálů je tento tenký klient vybaven poměrně silným procesorem, který umožňuje běh samostatného operačního systému a tak se otevírá cesta k zajímavějšímu využití. Vzhledem k malým rozměrům a spotřebě kolem 5 W může sloužit třeba jako trvale běžící nenáročný linuxový server, logovací stanice pro různá měření nebo linuxový klient připojený k linuxovému serveru. Akorát na multimédia se vzhledem k slabšímu HW moc nehodí.
Hardware
Na základní desce je vidět snaha o max. hardwarovou jednoduchost a nízkou cenu. EVO T20 není přímo dílo Compaqu, ale je to v jádru WYSE Winterm 8235LE přebalený v jiné krabici. Design je podle mě docela zdařilý, takže neudělá ostudu ani v obýváku vedle televize. Srdcem T20 je 32-bitový nízkopříkonový x86 procesor Geode GX1 s integrovaným severním můstkem a grafickým jádrem taktovaný na 300 MHz. Geode vychází z jádra MediaGX, jenž vyvinula firma Cyrix, kterou později koupil National Semiconductors a od nich to pak koupilo AMD. Funkcemi ho lze přirovnat k Pentiu MMX, CPUID je 540h. Výrobce uvádí typickou spotřebu 1,2 W při taktu 300 MHz a napětí 2,0 V. Procesor v sobě integruje i funkce severního můstku, tedy řadič SDRAM pamětí, řadič PCI sběrnice a interface pro jižní můstek. Obsahuje i jednoduché grafické jádro, které využívá část (max. 4 MB) operační paměti jako videopaměť a zvládá základní 2D a MPEG1 akceleraci.
Procesoru sekunduje jižní můstek CS5530A sdružující 1-kanálový IDE řadič (v T20 ale bohužel není IDE interface využit), druhou část grafického jádra s analogovým výstupem na CRT a digitálním pro LCD (T20 má jen analogový výstup), 2-portový USB 1.1 řadič (dále rozšířený 4-portovým USB hubem TUSB2046), PCI2ISA můstek a integrovanou zvukovku AC97, která má navíc hardwarovou podporu pro emulaci SoundBlasteru 16 za pomoci SMBIOSu (výrobce to zde označuje jako VSA - Virtual System Architecture). Funguje to zhruba tak, že chipset odchytává všechny přístupy na I/O porty a DMA, které používal klasický SB16 a generuje SMI přerušení. Softwarová obsluha SMBIOSu pak zařídí odpovídající akci na AC97 hardwaru. To samozřejmě zabere určitý čas CPU navíc, ale zato emulace funguje v reálném i chráněném módu a nezávisle na operačním systému. Škoda, že už se to tak nedělá u dnešních integrovaných zvukovek. Další nezbytnou periferií je 10/100 Mbit ethernet síťovka DP83815, taktéž od Nationalu.
PS/2 konektory pro klávesnici a myš byste zde hledali marně. Výrobce se totiž pyšní sloganem "legacy free" a tak nezbývá než periferie zapojit do USB. Bohužel BIOS nepodporuje emulaci standardní klávesnice, takže OS a bootloadery bez USB HID podpory jsou v řiti. Teoreticky by se dal připojit SuperIO s rozšiřujícími porty na ISA sběrnici, ale napíchnout všechny potřebné signály sběrnice by bylo dost obtížné a navíc by se musel napsat kód pro jeho inicializaci. Jediné tlačítko na přední straně slouží k vypínání (funguje asi pouze ve Windows) a při delším držení dojde k resetu. Výrobce šetřil na hardware tak mocně, že se ani neobtěžoval zálohovat RTC baterií. To je ale celkem pochopitelné, protože se počítalo se synchronizací času z NTP serveru. Já jsem po vzoru Karla Mowsona přidělal na MB držák s klasickou 3V lithiovou baterií a připojil ji k RTC DS12885 (U20B), plus na pin č. 20 (Vbat) a mínus někam na zem, třeba pin č. 12. Pak je ještě potřeba odpájet odpory R85 a R86 z druhé strany. Případně je možné stávající RTC odpájet a vyměnit ho za DS12887A, který už má baterii vevnitř (na desce jsou na to připravené díry).
EVO T20 se vyrábělo v několika variantách s odstupňovanou velikostí pamětí, konkrétní typ určuje sériové číslo. Já mám pouze základní model s 32 MB onboard RAM a 16 MB onboard NAND flash. Nejvyšší má pak 256 MB RAM a 256 MB FlashROM. Mění se typy a počet osazených paměťových čipů na desce a obsazení paměťových slotů (např. 32M verze: 1 x 58F256, 48M verze: 58128 + 58256, 64M verze: 2 x 58F256, 96M verze: 2 x 58F256 + 32MB SmartMedia karta). Flash paměť lze sice teoreticky rozšířit SmartMedia kartou (max. 128 MB), ale prakticky se už nedá nikde koupit. Navíc nevím, zda-li by se BIOS vypořádal s netradiční kombinací onboard NAND flash a karty. Jako jedinou možnost tak vidím rozkuchat nějakou starší 64MB nebo 128MB CompactFlash kartu a z ní přepájet paměťové čipy. Operační paměť RAM lze rozšířit poměrně snadno pomocí SO-DIMM SDRAM PC133 modulu o max. velikosti 256 MB. Tak jsem také učinil. Jen upozorňuji, že v ČR se tyto historické moduly prodávají za docela vydřidušské ceny, na e-bay je lze koupit méně než za polovic. Vložený modul si BIOS sám zdetekoval a v OS se objevila plná velikost, tj. celkem 288 MB RAM. Zde je přehled HW parametrů:
CPU + NB: National Semiconductors Geode GX1 @ 300 MHz; 0,18 µm; 352-pin BGA SB + VGA: National Semiconductors CS5530A; max. 4 MB VRAM; 1280x1024/16bpp; VBE 2.0 Paměť: RAM: 4x Hynix HY57V641620HG 4M x 16 SDRAM
1x soket pro SO-DIMM SDRAM PC133 modul, max. 256 MB
NAND flash: 1x Toshiba TC58128AFT 16 MB
1x slot pro SmartMedia kartuSíťovka: National Semiconductors DP83815 10/100 Mbit ethernet Audio: CS5530A Kahlua - integrovaná v SouthBridge, AC97
VSA emulace SoundBlaster 16 přes SMI BIOSRTC: Dallas DS12885 bez záložní baterie USB: 4-portový USB 1.1 hub Texas Instruments TUSB2046 Konektory: 1 x napájení 5 V DC (na konektoru vpravo dole je -, ostatní 3 dutinky jsou +, protikus)
4 x USB 1.1
1 x VGA D-SUB 15
1 x 3,5 mm jack phones / line out
1 x 3,5 mm jack microphone in
1 x RJ45 ethernetBIOS: Wyse embedded BIOS, nemá SETUP, upgrade po síti přes TFTP
256 kB FlashROM Winbond W29C020, 5 V nebo
512 kB FlashROM Winbond W29C040, 5 V (verze s WinXPE)
rozměry: 19 x 20 x 4,5 cm (bez podstavce); samotná deska: 14 x 16 cm
Základní deska:
Firmware (BndL, no-PXE)
Od velikosti instalované paměti se odvíjí také nainstalovaný operační systém. Verze s 16 a 32 MB Flash běží na Windows CE 2.12 nebo Windows CE.NET, 48 - 128 MB verze jedou na Windows NT embedded a nejvyšší 192 a 256 MB drtí Windows XP embedded. Některé verze firmwaru mají podporu PXE (bootování ze sítě). Originální firmware lze stáhnout na webu hp. Firmware se skládá ze dvou částí: safemode BIOS + Netxfer klient, který sídlí ve 256kB FlashROM (U11) a hlavní BIOS s dalšími ROM moduly a operační systém, který je uložen v onboard NAND flash (U9), případně na SmartMedia kartě. BIOS nemá klasický SETUP, veškerá nastavení se provádí až v operačním systému.
Update firmware se provádí po síti protokolem BOOTP/TFTP. Pokud nemáme k dispozici LAN, budeme potřebovat křížený UTP kabel pro přímé propojení s PC - serverem. Na PC je třeba nainstalovat utilitu Netxfer a ta vyžaduje pro svou funkci M$ Javu (pod Sun JVM nefunguje). V nastavení sítě vypneme DHCP a nastavíme IP adresu 10.0.0.1 a masku 255.255.255.0. Soubor s příslušným firmwarem zkopírujeme do adresáře Netxferu a přejmenujeme ho na bootp.bin. Spustíme Netxfer a mělo by se objevit konzolové okno se statistikou stažených souborů. Po zapnutí EVO T20 několikrát stiskneme klávesu 'P' dokud se neobjeví hlášení klientské strany Netxferu "Contacting Server" (pokud T20 místo toho normálně bootuje, restartujeme delším stiskem power tlačítka a zkusíme to znovu), která by se měla po chvilce spojit se serverem a začít stahovat soubor s firmwarem. Po úspěšném stažení se soubor nejprve zkontroluje (nelze např. do verze s Windows NTE nahrát firmware s Windows CE - zanadává že "Security Key does not match" nebo do verze s méně Flash paměti nahrát fimware, který zabírá více Flash paměti). Pak se updatuje safemode BIOS a následně NAND flash s hlavním BIOSem a OS. Na obrazovce se vypisuje, které soubory z image firmware se právě flashují. Nakonec se T20 sám restartuje a měl by najet nový firmware. Netxfer na serveru můžeme zavřít. V případě, že je druhá část firmware pro NAND flash nějakým způsobem poškozena a systém nenastartuje tak jak má, lze znovu klávesou 'P' spustit Netxfer klient a opakovat flashování. Pokud chyba postihne systémový BIOS a nelze tak spustit Netxfer klient, nezbývá než FlashROM vyndat a přeprogramovat v programátoru.
Pokud máte PC s Linuxem, lze pro upload firmwaru použít správně nakonfigurované servery dhcpd a tftpd, tzn. DHCP na portech 10067, 10068 a TFTP na portu 10069. Karl Mowson na to napsal skript netxfer.sh. Prý ještě existuje možnost s klávesou 'Q', která by měla spustit Netxfer klient na standardních portech - nezkoušel jsem, používal jsem jenom windozí Netxfer.
Nyní se podíváme podrobněji na obsah firmware image. Ten se liší podle druhu operačního systému a zda-li obsahuje bootrom s podporou PXE. Firmwary s Windows NTE nebo XPE vždy obsahují image virtuálního disku se souborovým systémem NTFS, z kterého BIOS klasicky zavádí OS, zatím co firmware s Windows CE nepoužívá (nebo mi není znám) souborový systém a startuje přímo soubor nk.bin (jádro Windows CE). Když jsem zkoumal různé firmwary, narazil jsem mimo jiné na kuriózní řetězce typu "All Your Base Are Belong To Us.", "Somebody Set Us Up The Bomb!", "You Have No Chance To Survive Make Your Time." a pod. (firmware Windows NTE+PXE 64 MB h064b218.bin od offsetu 322190h). Tamtéž na offsetu 3219F2h jsem našel řetězce, které vypadají jako z nějakého SETUPu - "USB: ", "Legacy", "Enabled" "Disabled", přitom T20 žádný SETUP nemá. Později jsem přišel na to, že novější verze firmware s PXE vypisuje při bootu textovou informační tabulku o konfiguraci hardware, kde se tyto řetězce vyskytují. Takže USB legacy podpora to asi nebude.
Dále se budu podrobněji zabývat pouze firmwarem Windows NTE 48 MB u48cpq163.bin, jehož struktura je detailněji známá a existují linuxové nástroje bundle-tools 0.7, které ho umí rozebrat a zase složit. Firmware image je vlastně slepenec z více různých souborů, některé jsou pouze dočasné pro další potřeby flashování, další se nahraje do 256kB FlashROM a ostatní do NAND flash. Zde jsem se pokusil sestavit mapu zmiňovaného 48MB firmware s Windows NTE u48cpq163.bin:
začátek konec popis 0000000 00001FF 512B hlavička firmwaru, adresy a velikosti obsažených modulů, končí 55,AAh 0000200 00081FF 32kB firmware loader tftp.dat 0008200 00481FF 256kB sfamode BIOS + Netxfer client 9.06 ulc_code.ce (stejný ve všech FW) 0048200 0048206 7B bundle ROM signatura 1B, 58, 00, "BndL", následuje seznam souborů.
15 B před jménem souboru je velikost souboru UINT32,
19 B před jménem souboru je UINT32 offset od začátku bundle.0048352 0088351 256kB sfamode BIOS + Netxfer client ulc_code.ce (2. kopie) 0088352 0088365 20B binární klíč k identifikující konkrétní verzi EVO T20 0088366 00C8365 256kB hlavní BIOS ulc_code.bin (+ další ROMky, VGA BIOS, SETUP?) 00A8366 00B0365 32kB VGA BIOS version 2.07 (C) Elpin Systems (součást ulc_code.bin) 00B8366 00C8365 64kB rezidentní část BIOSu, která se mapuje na adresy F0000 - FFFFFh 00C8366 00C836A 5B řetězec verze OS os.ver, zde "4.36 " 00C836E 00CBA95 14120B start-up obrázek (RLE BMP 640 x 480 / 8 bpp) poweron.bmp 00CBA96 00CBC95 512B MBR HDD image filesys0.img o velikosti 31719424 B 00CBC96 00CBE95 512B NTFS bootsector HDD image, CHS: 8/208/56, celkem 93183 sektorů 1F0BA96 2E4BA95 15990784B druhá část HDD image filesys1.img 2E4BA96 2E4BA9B 6B patička firmware image
Pomocí bundle-tools lze jednoduše extrahovat soubory z ROM bundle (obsažené v hlavičce "BndL") do připraveného adresáře. Pak je můžeme změnit, odstranit nebo přidat a opět složit do nového ROM bundle, ke kterému musíme ještě přilepit začátek původního firmware image, tzv. bootstrap o velikosti 295424 B. Firmwary s podporou PXE (64 - 256 MB) mají jinou strukturu, obsahují novější verzi Netxfer klienta 11.49 a VGA BIOSu, neobsahují ROM bundle signaturu a není zde žádný nástroj na jejich modifikaci.
První, co jsem si zkusil změnit, bylo samozřejmě start-up logo, které se zobrazuje při bootování. Při výrobě vlastního obrázku je potřeba nechat v paletě rezervu pro systémové barvy (v PSP volba include windows colors), jinak si je systém alokuje sám a dojde tak k pomrvení obrázku. Výsledek uložíme do BMP souboru velikosti 640 x 480, 8 bitů na pixel s kompresí RLE.
Pro účely nahackování jiného OS nás bude zajímat hlavně HDD image - soubory filesys0.img a filesys1.img. BIOS obsahuje služby INT 13h, které emulují klasický HDD pomocí jeho image v NAND flash, ale podporuje pouze funkce pro čtení, takže na virtuální disk nelze zapisovat. Proces bootování se od klasického PC liší v tom, že BIOS T20 vůbec neprovádí kód MBR (1. sektor). Pouze si přečte partition tabulku a z ní si odvodí CHS geometrii emulovaného disku. Stávající HDD image má poněkud obskurní geometrii CHS: 8/208/56, já jsem použil CHS: 140/16/32 a BIOS podle toho správně přenastavil geometrii (ověřil jsem si to výpisem z volání služby č. 8 INT 13h). Místo toho BIOS načte a spustí 2. sektor, kde očekává bootsektor operačního systému - zde NTFS bootsektor, který dále načítá soubor ntldr - zavaděč Windows NTE. To je třeba mít na paměti, protože FDISK a další diskové nástroje nechávají vždy první stopu prázdnou a oddíl tak začíná až od CHS: 1/0/1 jak je na PC zvykem. Nejjednodušší je po instalaci OS zkopírovat bootsektor z CHS: 1/0/1 na CHS: 0/0/2 v hexaeditoru.
Mým cílem bylo vytvořit si vlastní HDD image se souborovým systémem FAT16, kam bych nainstaloval DOS a linuxové jádro, které by se podle potřeby načítalo loadlinem. Hlavně jsem musel HDD image zmenšit, abych se vešel do 16MB NAND flash. K těmto hrátkám se dobře hodí PC emulátor BOCHS. V něm jsem si vytvořil 35MB HDD image s geometrií CHS: 140/16/32 (větší velikost kvůli FAT16), který nakonec oříznu na velikost 16056832 B a použiju jako filesys0.img pro sestavení nového ROM bundle. Pokud soubory na filesystému nepřekročí s rezervou tuto velikost, tak po defragmentaci nehrozí žádná ztráta dat. Zde je můj konfigurák pro BOCHS.
FreeDOS na EVO T20
8.11.2008 V BOCHSu jsem zkusil na HDD image nainstalovat celou řadu různých verzí DOSu, které sice v emulátoru krásně fungovaly, ale po flashnutí do T20 se to vždy při bootování zaseklo. Např. FreeDOS vytuhnul kdesi na začátku bootsektoru a vypsal jen "FreeDOS" (mělo následovat "Kernel" a "GO!"), MS-DOS 6.22 a 8.0 zase skončily na "Starting MS-DOS", PC-DOS 7.1 nápodobně, SysLinux 3.72 nemohl najít ldlinux.sys, GRUB4DOS 0.4.4 nenašel grldr. Jediná funkční výjimka byl NT Loader a NT bootsector, který jsem vytvořil pomocí utility bootprep z Windows XPE. Nepřišel jsem na to, co dělá tento bootsector jinak, ale prostě funguje. Jenže k čemu je dobrý NT Loader, když ne k bootování Windows? NT loader má ještě další schopnost - umí načíst a spustit jiný bootsector ze souboru, který je uveden v boot.ini. Spouštění bootsectoru DOSu nemělo žádný smysl, ale zato se dá tímto způsobem načíst přímo grldr a GRUB4DOS už nabízí více možností. Umožňuje přímo spouštět FreeDOS kernel a Linuxový kernel včetně initrd a parametrů. Bootovací řetězec tedy vypadá takto: BIOS -> NT bootsector -> NT Loader -> GRUB4DOS -> FreeDOS Kernel. Můj boot.ini vypadá následovně:
a menu.lst pro GRUB4DOS:
Tím ale nebyl problém bootování FreeDOSu zdaleka u konce. FreeDOS kernel spadl ve fázi InitDisk a skončil dělením nulou:
Zkoušel jsem několik verzí kernelu (starší 2035, 2036 i poslední 2038 SVN), ale všechny spadly stejně. Napadlo mě tedy využít možnost GRUBu nabootovat image diskety s FreeDOSem, ale to dopadlo špatně kvůli chybějící funkci BIOSu: "Fatal: Your BIOS has no support for System Memory Map(INT15/EAX=E820h)." Podobně špatně dopadl pokus s MemDiskem 3.72, který úspěšně načetl malý HDD image s FreeDOSem do paměti, ale pak skončil: "Loading boot sector... booting... disk error". Takže tudy cesta nevede.
Nakonec jsem si stáhl zdrojáky FreeDOS kernelu 2038 SVN a jal se je debugovat. Jako překladač jsem použil Watcom C 11.0c, zde je chyba se zapnutým debug výpisem:
V modulu initdisk.c jsem narazil na několik chyb, např. špatný výpočet celkového počtu sektorů oddílu, kde chybělo explicitní přetypování a výsledek násobení tak přetekl a chybělo přičtení 1 pro cylindry, protože BIOS vrací max. hodnotu počítanou od nuly a ne počet:driveParam->total_sectors = (ULONG)(driveParam->chs.Cylinder+1)*driveParam->chs.Head*driveParam->chs.Sector;Další a podle mě fatální chyba byla v některých inicializacích globálních proměnných. Konkrétně proměnná:COUNT nUnits BSS_INIT(0);nabývala náhodně podezřele vysokých hodnot. Typ COUNT je definován jako integer a makro BSS_INIT() najdeme v souboru init-mod.h. Pro překladač Microsoft C se rozvine jako:#define BSS_INIT(x) = xa pro ostatní překladače zůstává jako prázdné makro:#define BSS_INIT(x)a Watcom C zřejmě globální proměnné sám neinicializuje. Zajímavé, že v BOCHSu i na ostatních PC to takhle fungovalo, jen na EVO T20 nikoliv. Zahrnul jsem tedy __WATCOMC__ do definice makra s explicitním nulováním a hle, najednou to krásně nabootovalo:
Zde jsou ke stažení mnou upravené zdrojové kódy FreeDOS kernelu z 30.11.2008. Zahrnují i několik neoficiálních hotfixů od Erica Auera.
Tušil jsem, že by EVO T20 mohlo díky transparentní emulaci SoundBlasteru 16 dobře posloužit i na hraní starších her a pouštění demíček. Pro inicializaci zvukové karty nejsou potřeba žádné ovladače, jenom stačí do souboru autoexec.bat přidat řádek:SET BLASTER=A220 I5 D1 H5 P330 T6který ostatním programům napoví, jaké prostředky mají pro zvuk použít. Napřed jsem zkusil DOSový přehrávač MPXPlay 1.56 a přehrát nějakou MP3 - bez problémů. Akorát nutno podotknout, že zvukový výstup je trochu zarušen šumy z MB. Pak jsem zkusil pustit moje oblíbené demíčko Boost od Doomsday, které se po chvíli taky rozběhlo i se zvukem, zde malá ukázka.
Říkal jsem si, že když už jsem došel až sem, podaří se to dotáhnout do konce nějakým USB HID ovladačem. Dlouho jsem googlil a pročítal různá fóra, ale žádný takový driver jsem nenašel. Pouze ovladače pro USB mass-storage zařízení a jeden ovladač pro USB myš. Vyzkoušel jsem všechny, jenže žádný nefungoval ani s USB klíčenkou ani s myší. USBMASS/386 4.05 se pokoušel něco detekovat, ale pořád jen vypisoval tečky a nic. USBASPI 2.27 nenajde žádný OHCI řadič, ASPIOHCI 1.1 nenajde žádné zařízení. USBLink 2.5 inicializuje OHCI řadič, ale nenajde myš. DUSE 4.9 detekovalo správně OHCI řadič: "OHCI USB Controller initialized (BASE 0xCC000, IRQ 6)" a pozná i zařízení, když zastrčím klíčenku do USB: "Detected USB Storage Device", ale hned na to vypíše "Failed to load USB Storage Device". Jedinou nadějí by mohlo být DOSUSB 1.4c, které je ještě ve vývoji a autor zde má i ukázkový kód čtení znaků z USB klávesnice. Bohužel se při spuštění kousne. Před časem jsem pomáhal Georgovi testovat verzi 1.4b, která dělala chyby při přenosu většího množství dat, kdy se totálně zbořil filesystém na USB flashce (opraveno ve verzi 1.4c). Poprosil jsem ho o nějakou ladicí verzi, abych mohl problém vystopovat, ale bylo mi suše řečeno, že pokud chci nějak sahat do zdrojáků, mám si koupit licenci za 1000 euro. Takže tímto byl osud FreeDOSu na EVO T20 zpečetěn, OS bez možnosti ovládání je dost na nic :(.
Debian Linux na EVO T20
6.12.2008 Na Internetu se dá najít několik hotových distribucí přímo pro EVO T20 vycházejících z Debianu, DSL, Gentoo, Slackwaru, ... Avšak jako správný nadšenec jsem si chtěl zkusit sestavit svou vlastní distribuci a naučit se tak něco nového. Vyšel jsem z Debianu Etch, protože už s Debianem mám jisté zkušenosti na svém PC a notebooku (v současnosti Debian Lenny). Debian lze snadno nainstalovat, základní systém zabere něco přes 100 MB a můžeme ho pak dále podle potřeby snadno rozšiřovat instalací balíčků (kterých je jenom na www.debian.org asi 10000) ze sítě přes apt. Už celkem chápu hlášku "Toto APT má schopnosti svaté krávy" :) Bootování systému jsem už vyřešil v předchozím případě. Stačí nahrát kernel a initrd na HDD image a GRUB4DOS se už o to postará. Pro změnu jádra je tedy nutné přeflashovat firmware. Kořenový systém je umístěn na USB klíčence, který si jádro za pomoci USB driverů připojí a nastartuje systém jako z normálního disku.
Rozmýšlel jsem, jakou verzi kernelu pro EVO T20 použít. Z Karlova porovnání kernelů 2.4.27-2-386 a 2.6.18-3-486 jasně vyplývá, že 2.4.x kernel je rychlejší. Důvodem pro 2.6.x kernel zas můžou být nové ovladače, zejména pro různá USB zařízení. Rozhodl jsem se pro poslední verzi kernelu 2.4.37 na kterou jsem aplikoval patch pro driver síťovky od Franka Boehma, který zamezí otravným kernel debug výpisům na konzoli. Pustil jsem se do konfigurace jádra a odebral některé zbytečné komponenty, ale nesnažil jsem se zas odrbat kernel až na kost. Nechal jsem tam zatím drivery na IDE a klasickou klávesnici, aby bylo možno kernel ladit v BOCHSu. Jejich vynecháním by se start urychlil o několik vteřin. Po několika cyklech kompilace a testů jsem doiteroval k funkčnímu konfiguráku.
Překlad byl pro mě trochu oříšek, protože 2.4.x kernel nejde normálně přeložit gcc 4.x, je potřeba starší verze (ach ta kompatabilita). To by nebyl problém, v Debianu lze nainstalovat více gcc balíčků a pak jen změnit symlinky. Horší bylo, že starší kernel vyžadoval initrd-tools a ten byl zas v konfliktu s initramfs-tools pro můj 2.6.x kernel. Nakonec jsem si vzpomněl, že se mi válí ve skříni starší HDD s instalací Debian Etch a 2.4.x jádrem a tak jsem ho vrazil do šuplíku a přeložil to na něm. Výsledný initrd mi ale nějak nefungoval. Vůbec se nenačetly moduly pro USB řadič a HID, přestože v initrd byly. Inspiroval jsem se tedy initrd od Franka. V případě 2.4.x jádra má initrd (init ramdisk) podobu malého image s filesystémem ext2, který je zabalen gzipem a jsou v něm uloženy moduly potřebné pro start systému, initskript a pár utilit. Pomocí příkazu:mount -o loop initrd /evo-t20/initrdjsem si ho připojil, přepsal původní moduly novými a upravil initskript. Pak zas odmountovat, zagzipovat a hotovo. Zavaděč systému (zde GRUB4DOS) rozbalí image kernelu a ramdisku do paměti a spustí kernel. Ten si přimountuje dočasně ramdisk jako kořenový souborový systém a podle initskriptu natáhne další moduly, zejména ovladače zařízení z kterého se má dále bootovat. Pak se pokusí přimountovat daný oddíl na bootovacím zařízení (zde USB klíčenka). Pokud nic nenajde, ohlásí obligátní "Kernel panic: Unable to mount root fs..." (zde se aspoň pustí busybox). Pokud úspěšně přimountuje bootovací zařízení, dojde pomocí pivot_root k přepnutí kořenového adresáře a pokračuje zpracování dalších inicializačních skriptů, které můžou zavádět další moduly jádra, vypouštět démony, atd.
Základní instalaci Debianu pro EVO T20 jsem provedl pod Linuxem na svém PC pomocí vychytané utility debootsrap:debootsrap etch /evo-t20/rootfskterá postahuje z netu potřebné balíčky dané distribuce a vytvoří adresářový strom cílové distribuce v daném adresáři. Pak je potřeba ručně upravit několik konfiguračních souborů v /etc, zejména /etc/fstab a /etc/apt/sources.list. Pak se můžeme do nové instalace přepnout příkazem:chroot /evo-t20/rootfsa v tom okamžiku se adresář cílové distribuce stává kořenovým adresářem. Pak je možno přes apt doinstalovat další balíčky, v mém případě např.: mc, gcc, dosemu, fonty, localepurge, gpm, htop, bluetooth, mpg123, opencubicplayer, mplayer, xmms, xorg, xpdf, gkrellm, icewm, iceape, lynx, centericq, bittorrent, mutella, apache2, php4, mini-httpd, openssh-client, openssh-server, vsftpd, xvncviewer, webcam, perl, python a další, kompletní seznam zde. Nakonec jsem ještě nainstaloval balíčky kernel-headers-2.4.37 a kernel-image-2.4.37, které jsem si předtím při překladu vytvořil pomocí make-kpkg. Po promazání zbytečností a kompresi většiny binárek UPXem, jsem se dostal s velikostí instalace pod 400 MB. Abych trochu ulehčil USB klíčence od častých zápisů, mountuju kořenový filesystem s parametrem "noatime", který zamezí ukládání času posledního přístupu k souborům a adresář /temp jsem vytvořil v dynamickém ramdisku. Tam jsem také symlinkem přesměroval adresář /var/log, aby se po čase systém nezahltil nahromaděnými logy (ukládání některých logů jsem rovnou vypnul). Zde je můj /etc/fstab:
Pak bylo potřeba přenést připravenou instalaci na USB klíčenku. Oddíly lze sice vytvořit linuxovým fdiskem, ale já mám radši PQ Magic. Původně jsem systém instaloval na 1GB intel USB Solid State Disk, jenže ten záhy umřel na vadné sektory (asi už byl načatý). Další pokus se konal na 2GB reklamní klíčence, kterou jsem dostal na veletrhu od uBloxu. Kolegům sice dvě tyto klíčenky hned skáply, ta moje se zatím drží. Vytvořil jsem 2 primární oddíly, první FAT16 o velikosti 1,4 GB a druhý ext2 o velikosti 600 MB. Moje bootovací zařízení je tedy /dev/sda2. Zjistil jsem, že je ještě potřeba na novém oddílu nechat pomocí fsck vytvořit UUID, jinak je z toho Linux zmatený. Při použití linuxového mkfs to není třeba. Pak jsem USB klíčenku přimountoval a na ext2 oddíl překopíroval adresářový strom cílové instalace, odmountoval, zastrčil do EVO T20 a tradá. Do firmware jsem na HDD image přidal novou položku GRUBu do menu.lst:
Po zapnutí EVO T20 se obrazovka GRUBu objeví za 40 s, konzolový Linux login za 1:40 od zapnutí a start X Windows s ICEWM trvá dalších 30 s.
Po odladění kernelu a initrd jsem už nemusel dále firmware přeflashovávat. Avšak s doinstalováním a konfigurací balíčků byla ještě spousta práce. Při rozcházení zvukovky jsem nejprve zkoušel nativní driver kahlua AC97, který se sice správně zavedl, ale nehrálo to. Frank mi poradil přesnou konfiguraci pro sb driver, přes který to hraje dobře, akorát je díky emulaci vyšší zátěž CPU. Do souboru etc/modules stačí přidat řádek:sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0Pak jsem měl problém, že se mi nechtěl spustit Xorg, protože chybělo zařízení /dev/input/mouse0 a defaultní konfigurák Xorg bez myši nespustil. Upravil jsem si k obrazu svému xorg.conf od Philipa D Loewena. Driver nsc mi sice v Xkách fungoval dobře, jenže po ukončení Xorg a návratu do textového režimu konzole se nastavila nezvykle vysoká obnovovací frekvence 140 Hz / 69,2 kHz (vypadá to, jako by se nepřeprogramoval CRTC a zůstalo časování z grafického režimu). Můj CRT to ještě stíhal, ale žádný LCD takovou frekvenci nepobere a lze akorát tak restartovat systém. Proto používám vesa driver, který je o něco pomalejší, ale funguje. Také jsem zjistil, že nejde nastavit vyšší rozlišení jak 1024 x 768, přestože by grafické jádro mělo umět až 1280 x 1024 / 16 bpp. Příčina bude asi v tom, že VGA BIOS v EVO T20 nastaví grafické jádro tak, že si alokuje pouze 2,5 MB místo max. 4 MB videopaměti (pro 1280 x 1024 / 16 bpp je potřeba asi 2,6 MB). Existuje sice patch pro GRUB od Mr. Johannsena, který při bootování přenastaví registry grafického jádra na 4 MB videopaměti, ale zas to prý zlobí při použití framebuffer konzole, kde se pak v části obrazovky ukazuje nějaké smetí.
28.12.2008 Ohledně problému s VGA BIOSem mě napadla taková věc, že bych zkusil do firmware nahrát jiný VGA BIOS (stávající je ver. 2.07), který by byl možná ochoten alokovat více videopaměti. Napřed jsem zkusil vyextrahovat VGA BIOS ver. 4.13 z 128MB NTE+PXE verze firmwaru pro EVO T20, ale po flashnutí vůbec nenaskočil obraz. To samé u VGA BIOSu z 256MB firmware pro WYSE Winterm 8235LE. Hledal jsem tedy na Internetu BIOSy pro různé průmyslové desky postavené na Geode GX1. Podařilo se mi vyextrahovat VGA BIOS ver. 2.08, který po flashnutí normálně fungoval, ale opět alokoval jenom 2,5 MB videopaměti. Když nebylo co dál zkoušet, prohnal jsem původní VGA BIOS 2.07 disassemblerem a prošel inicializační rutinu. Jak jsem zjistil, tak ta pouze ověřuje, zda-li sedí PCI Device ID s tím, co je uloženo v interní PCIR struktuře BIOSu a dále provádí nějaké nastavení na IO portech CRTC. Žádný přístup k registrům, které mají něco společného s nastavením videopaměti jsem nenašel. Z toho plyne, že VGA BIOS za nic nemůže a je třeba hledat jinde, nejspíš v systémovém BIOSu.
5.1.2009 Zaměřil jsem se tedy na systémový BIOS, reps. jeho rezidentní část, která se mapuje na adresy F0000 - FFFFFh (poslední 64kB blok modulu ulc_code.bin). Ten jsem prohnal disassemblerem - zde je kompletní výpis, který jsem částečně upravil a okomentoval. V datasheetu k procesoru Geode GX1 jsem vytipoval 2 registry, které mají co do činění s velikostí framebufferu:
1) 32-bitový registr BC_DRAM_TOP (GX_BASE+8000h), který na počátku obsahuje nejvyšší adresu fyzické RAM. BIOS ho automaticky nastaví podle velikosti detekované RAM v systému (včetně přídavného paměťového modulu SO-DIMM), v mojem případě má hodnotu 11FFFFFFh (32 + 256 MB RAM).
2) 32-bitový registr MC_GBASE_ADD (GX_BASE+8414h), který obsahuje počáteční adresu framebufferu, jenž je umístěn na konci RAM. Rozdíl těchto 2 adres tedy určuje velikost framebufferu. Z logiky věci vyplývá, že velikost lze měnit pouze ve fázi inicializace BIOSu, později by mohlo dojít k přepsání paměti operačního systému novým framebufferem. V mojem případě byla tato adresa nastavena na 11D80000h, tedy 2,5 MB pro framebuffer (ten může měnit velikost pouze s krokem po 0,5 MB). Po nastavení bázové adresy framebufferu BIOS posune BC_DRAM_TOP o jeho velikost níže, u mě na hodnotu 11D7FFFFh. Tím je zajištěno, že OS nevyužije paměť výše jako normální operační paměť a nedojde ke kolizi kódu/dat s obrazovými daty ve framebufferu.
GX_BASE je bázová adresa MMIO (paměťově mapovaných) registrů funkčních bloků procesoru a lze ji získat z GCR registru CPU, v mojem případě má hodnotu 40000000h. V BIOSu jsem našel odpovídající část kódu, která nastavuje registr MC_GBASE_ADD a podrobil ho důkladnější analýze - ve výpisu najdete zmíněný blok pod labelem "SET_FB_SIZE". Je zde vidět, že BIOS vybírá velikost framebufferu ze čtyř konstant: 2, 4, 6, 8 MB na základě volání funkce, která manipuluje s IO portem F808h. Bohužel sem nikde v dokumentaci o portu F808h nic nenašel. Zkusil jsem tedy velikost nastavit natvdro přepsáním řádku s instrukcí "OR SI, 1" na "MOV SI, 8" pro 4MB framebuffer:
To v praxi znamená přepsání 3 Byte v modulu ulc_code.bin (ten začíná na offsetu 88366h v image firmware bootp.bin) na offsetech:
3C6E7h: 83h -> BEh (MOV SI opcode) 3C6E8h: CEh -> 08h (immediate value LSB) 3C6E9h: 01h -> 00h (immediate value MSB)BIOS nekontroluje žádný checksum, takže tato úprava opravdu stačí. Po úspěšném flashnutí nového firmwaru jsem si v linuxu zpětným čtením ověřil, že se MC_GBASE_ADD posunul na 11C00000h, tedy framebuffer se zvětšil na 4 MB. Nativní driver nsc pro Xorg hned tuto změnu detekoval a správně nastavil rozlišení 1280 x 1024 / 16 bpp. Bohužel však přetrvává problém při návratu do textové konzole, kdy se nastaví 140 Hz refresh monitoru. Zkoušel jsem nainstalovat i backport Xorg 7.3.0 pro Debian Etch, ale bohužel se stejným výsledkem.
Reportovaná velikost videopaměti VESA BIOSem se nezměnila, stále hlásí 2240 kB. Vrátil jsem se tedy k disassemblovanému VGA BIOSu a hledal tentokrát kód VESA/VBE funkce 4F00h, viz label "VESA_GET_INFO". Ta vrací základní informace o VBE včetně velikosti videopaměti v 64kB blocích. Funkci detekující velikost videopaměti najdete pod labelem "get_vram_size". Ta čte rozšířený CRTC registr s indexem 3Eh. O něm se píše v dokumentaci, že obsahuje velikosti videopaměti v 64kB blocích, ale ani slovo o tom, jakým způsobem si to vycucá z prstu, když na změny MC_GBASE_ADD nereflektuje. Pokusil jsem se tedy vnutit velikost videopaměti ručně přepsáním řádku s instrukcí "MOV AL, AH" na "MOV AL, 40h" pro 4 MB:
To v praxi znamená přepsání 3 Byte v modulu ulc_code.bin (ten začíná na offsetu 88366h v image firmware bootp.bin) na offsetech:
2678Eh: 8Ah -> B0h (MOV AL opcode) 2678Fh: C4h -> 40h (immediate value) 27FFEh: FFh -> 5Dh (updated checksum)VGA BIOS je regulerní ROM modul s 55AAh hlavičkou a tak by měl být opraven i jeho kontrolní součet. Po úspěšném flashnutí upraveného firmwaru vesa driver pro Xorg správně detekoval 4 MB videopaměti a nastavil rozlišení 1280 x 1024 / 16 bpp, jenže obraz byl nějaký rozbitý. Rozeznal jsem barvu pozadí IceWM a svislý šedý pruh v barvě taskbaru, ale nebyla vidět ani myš ani okna. Možná bude ještě potřeba upravit jinou VESA/VBE funkci (např. pro nastavení videomódu či získání informací o videomódu).
Dále jsem se dozvěděl z mailing listu zajímavou informaci, že u firmwarů s Windows XPE + PXE lze nastavit normálně rozlišení 1280 x 1024 / 16 bpp. Možná bude schůdnější cesta upravit tento firmware pro moje EVO T20 s 16 MB NAND flash...
3.4.2010 David Parkinson zkoumal moje disassemblované kódy BIOSu a objevil, že hodnota registru MC_GBASE_ADD se nastavuje podle jednoho byte v konfigurační EEPROM, která je připojená k ethernet čipu National Semiconductors DP8381. Prvních 12 wordů je vyhrazeno pro konfiguraci síťovky (např. MAC adresa) a dalších pár slov využívá BIOS. Čtení a zápis do této EEPROM se dělá přes I/O port F808h. Na to jsem předtím narazil, ale nevěděl co to dělá. To znamená, že není potřeba patchovat kód BIOSu, ale pouze změnit word 18h z hodnoty 0010h na 0014h. David k tomuto účelu napsal jednoduchý prográmek evo_eeprom (s využitím kódů diagnostické utility od National Semiconductors). Zkusil jsem tedy tuto modifikaci, ale bohužel VESA mód 1280 x 1024 / 16 bpp stejně nefungoval korektně. Možná je potřeba změnit ještě nějaké další bajty v EEPROM, ale k tomu bychom potřebovali porovnat dump z PXE firmware.
Firmware (s podporou PXE)
16.1.2009 Jak už bylo zmíněno výše, firmwary s podporou PXE (WinNTE i WinXPE) mají jinou strukturu, než firmwary bez PXE. Večer jsem na mailing listu zachytil zprávu od Klause Kleina, který přidal na SourceForge Wiki detailní popis firmwaru WinNTE s PXE pro EVO T20 s 64 MB NAND flash. Já jsem si pro změnu stáhnul 256MB firmware s WinXPE a PXE a podrobil ho analýze, zda-li popis odpovídá. Struktura je stejná jako u WinNTE firmwarů s PXE. Tento druh firmware neobsahuje žádnou centrální tabulku s popisem obsahu, ale skládá se z několika modulů slepených dohromady, kde každý modul začíná svou hlavičkou, jenž popisuje jeho velikost, jméno, atd. a dále obsahuje vlastní binární data. Na konci jsou pak 2 speciální moduly bez vlastního obsahu, které image firmware zakončují. Hlavička modulu, stejně jako obsah, má proměnnou délku. Zde je popis hlavičky:
velikost popis 4 Byte začátek hlavičky, vždy stejný DWord 00003938h ("89 ") 4 Byte velikost binárního obsahu modulu (DWord little endian) 4 Byte neznámý, vždy stejný DWord 00000000h 4 Byte délka jména cílového modulu (včetně koncové nuly, DWord little endian) N Bytů nulou ukončený řetězec se jménem cílového modulu 4 Byte délka jména zdrojového modulu (včetně koncové nuly, DWord little endian) M Bytů nulou ukončený řetězec se jménem zdrojového modulu
Jméno modulu obsahuje i cestu odkud byl soubor načten a kam se má do flash uložit. Ihned za hlavičkou následují binární data. Zde jsem se pokusil sestavit mapu zmiňovaného 256MB firmware s Windows XPE s podporou PXE h256b255.bin:
začátek konec popis 00000000 000001FF 512B hlavička firmwaru, končí 55,AAh 00000200 0021F1FF 2224128B Netxfer client bootstrap (zarovnáno 0) 0021F200 0021F245 70B hlavička modulu .\skeys\k.UTCXPECompaqClosedMASK 0021F246 0021F259 20B .\skeys\k.UTCXPECompaqClosedMASK (binární klíč identifikující konkrétní verzi EVO T20) 0021F25A 0021F28C 51B hlavička modulu ulc512.rom 0021F28D 0029F28C 524288B safemode BIOS ulc512.rom (obsahuje Netxfer client 11.48, skládá se ze dvou identických 256kB bloků) 0029F28D 0029F2CE 66B hlavička modulu .\component\prepmsg.txt 0029F2CF 0029F2D6 8B .\component\prepmsg.txt (textový soubor, obsahuje jen "dummy \r\n") 0029F2D7 0029F30A 52B hlavička modulu t20.raw 0029F30B 0F69F30A 255852544B HDD image t20.raw (CHS: 976/16/32, LBA: 499712) 0029F30B 0029F50A 512B MBR na HDD image t20.raw (CHS: 0/0/1, LBA: 0) 002A330B 002A350A 512B Wyse (typ 52h = CP/M) partition bootsector v t20.raw (CHS: 0/1/1, LBA: 32) 002A350B 003A330A Wyse partition data (celková velikost oddílu 1048576 B včetně bootsektoru) 003A330B 003A350A 512B NTFS (typ 07h = NTFS) partition bootsector v t20.raw (CHS: 4/1/1, LBA: 2080) 003A350B 0F69F30A NTFS partition data (celková velikost oddílu 254787584 B včetně bootsektoru) 0F69F30B 0F69F33D 51B hlavička modulu bios.bin 0F69F33E 0F71F72A 525293B hlavní BIOS bios.bin (+ další ROMky, VGA BIOS, PXE BootROM, start-up logo, SETUP?) 0F6ED2FB 0F6F428A 28560B VGA BIOS version 4.13 (C) Elpin Systems, ROM header: 55,AA,40h (součást bios.bin) 0F71F72B 0F71F762 56B hlavička modulu version.inf 0F71F763 0F71F8DF 381B textový soubor s info o firmware version.inf 0F71F8E0 0F71F91C 61B hlavička modulu component\transferend 0F71F91D 0F71F9C8 172B textový soubor component\transferend s hláškou, která se objeví při úspěšném dokončení update firmwaru 0F71F9C9 0F71F9EC 36B hlavička modulu ~REBOOT (0 B, příkaz k restartu) 0F71F9ED 0F71FA0A 30B hlavička modulu ~EOT (0 B, patička FW image)
Na základě těchto znalostí jsem se pokusil vytvořit vlastní verzi firmware, která by se vešla do 16MB NAND flash. První úskalí bylo v modulu ulc512.rom, který počítá s 512kB FlashROM, ale můj model EVO T20 má jen 256 kB. Jak jsem zjistil, tak tento modul se skládá ze dvou identických 256kB částí, takže lze jednu vynechat. Modul jsem tedy oříznul na 256 kB a upravil v hlavičce jeho velikost. Dále bylo potřeba zmenšit HDD image. U tohoto typu firmware může HDD image zabírat celou velikost NAND Flash, takže jsem použil parametry CHS: 64/16/32, celkem 32768 sektorů a upravil patřičně partition tabulku. HDD image obsahuje vždy dva oddíly. První je typu 52h (CP/M), neaktivní, o velikosti 1 MB a slouží pro uložení hlavního BIOSu (512kB modul bios.bin) a textového souboru version.inf). Pokud Netxfer nenajde na HDD image oddíl tohoto typu, odmítne dál pokračovat ve flashování. BIOS bootuje standardním postupem, tj. načítá a spouští kód MBR, který pak načte bootsektor aktivního oddílu. Druhý oddíl je typu 07h (NTFS), aktivní, o velikosti 243 MB a obsahuje instalaci Windows XPE. Přeformátoval jsem ho na FAT, nasysoval a zkopíroval soubory ntldr, grldr, linuxové jádro + initrd, atd. a samozřejmě zkontroloval v BOCHSu.
Při flashování nového firmware image se objevil další zádrhel - Netxfer hlásil, že nesouhlasí security klíč, že se pokouším přeflashovat jiný model EVO T20. To jsem podle Klausova popisu obešel tím, že jsem nahradil modul .\skeys\k.UTCXPECompaqClosedMASK 20B klíčem ze svého předchozího firmware založeného na 48MB verzi WinNTE bez PXE. Při dalším pokusu se sice vyskytla chyba "Unable to OPEN DEVICE! (nand/format.nand)", "Stream ERROR! Unable to Bind Device! (nand/format.nand)", ale to je při změně na jiný typ firmware normální. Stačilo restartovat a nechat proběhnout upgrade znovu, tentokrát už s novou verzí Netxfer klienta 11.48. Po dalším restartu mě přivítalo jiné start-up logo a taky nově textová tabulka shrnující informace o hardware a PXE 2.0 BootROM.
Na otestování velikosti videopaměti jsem si napsal jednoduchý prográmek - bootsektor v assembleru, který přečte a vypíše CRTC registr 3Eh. Přečtená hodnota je 40h, tzn. 40h * 64 kB = 4096 kB, takže už by nemělo nic bránit v použití rozlišení 1280 x 1024 /16 bpp. Bohužel tak snadné to ale nebude. Jak jsem zjistil, moje původní konfigurace ntldr - grldr nefunguje. GRUB4DOS 0.4.4 najednou píše "Missing helper" a zatuhne ještě před zobrazením menu. Zkusil jsem schválně GRUB nainstalovat pomocí grubinst.exe do bootsektoru 2. oddílu. V tom případě se sice GRUB spustil, ale nenašel soubor menu.lst a přepnul se do konzole. Jenže to je mi bez podpory USB klávesnice na houby... Zkusil jsem ještě instalaci do MBR, ale to skončilo hláškou "Missing MBR helper". Pak jsem zkoušel oddíl nasysovat FreeDOSem - kernel vytuhnul po initdisku (v nějaké funkci z newstuff.c). Zkoušel jsem i jiné verze DOSu, jiné verze GRUB4DOS, SysLinux, ale nic nefungovalo (v BOCHSu samozřejmě bez problémů). Zkusil jsem i prohodit pořadí oddílů na disku a taky nic. Klaus narazil na stejný problém při použití GRUBu na linuxovém ext2 oddílu. Takže jediné, co funguje, je NT loader a ten sám o sobě neumí přímo spouštět linuxový nebo FreeDOS kernel. Vypadá to, že emulace INT 13h nefunguje tak, jak by měla. Řešením by mohl být vlastní NAND flash driver, který by pouze zkopíroval linux kernel do RAM a spustil. Momentálně mě nic dalšího nenapadá, ale snad se to podaří časem rozlousknout...
Download
BIOSF000.TXT [964 kB] Disassembly listing systémového BIOSu z oblasti F0000 - FFFFFh VGABIOS.TXT [574 kB] Disassembly listing VGA BIOSu z oblasti C0000 - C7FFFh BNDLTOOL.TGZ [21 kB] Bundle-tools 0.7 - nástroje pro manipulaci s firmware image FDK2038S.ZIP [498 kB] Opravené zdrojové kódy FreeDOS kernelu 2038 SVN BOCHSRC.TXT [33 kB] Konfigurační soubor pro BOCHS emulátor pro ladění HDD image CONFIG [37 kB] Konfigurační soubor pro Linux kernel 2.4.37 XORGCONF [3 kB] Konfigurační soubor pro Linux Xorg 7.1.0 DPKG-L.TXT [46 kB] Výpis instalovaných balíčků v Debian Linuxu (Etch) NATSEMI.PAT [420 B] Patch pro Linux kernel driver síťovky National Semiconductors DP83815 GRUBVRAM.PAT [5 kB] Patch pro GRUB od Mr. Johannsena na zvětšení videopaměti EEPROM.ZIP [13 kB] Nástroj na modifikaci obsahu konfigurační EEPROM BOOSTDMO.AVI [644 kB] Videoukázka bootujícího FreeDOSu a kousek dema Boost/Doomsday
