Import of previous repository

ChangeLog

@@ -0,0 +1,29 @@
+stboot 0.2.1 (2012/25/10)
+------------
+- Added support for systems with more than one HDD
+- Fixed typos in source files and READMEs
+
+stboot 0.2 (2011/29/11)
+----------
+- Implemented a simple bootloader as a separate program, which loads the
+  the VBR of an active partition
+- GRUB4DOS is not included anymore, since it became useless (but it can
+  still be used as an alternative bootsect.bin)
+- Set the correct video mode for text mode programs
+- Added a procedure to display some messages
+- Introduced a function-like macro to calculate real mode addresses
+- Changes in the README in order to reflect the latest changes
+
+stboot 0.1.1 (2011/08/26)
+------------
+- Code clean-up:
+  - removal of unneeded instructions
+  - optimization of the copy instructions, by moving double-words
+    instead of bytes
+  - improve code readability with macro definition of constants
+  - correction of some comments
+- Minor corrections in the README
+
+stboot 0.1 (2011/08/21)
+----------
+- Initial release

README

@@ -0,0 +1,113 @@
+--------------------------------------------------
+stboot - A CEFULL replacement
+and a boot loader for Splashtop-compatible systems
+--------------------------------------------------
+by trya - [email protected]
+
+DISCLAIMER:
+THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
+LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER
+PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
+EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO
+THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM
+PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
+CORRECTION.
+
+Overview
+--------
+This program enables the use of the Splashtop (and related) start button in
+order to launch an OS other than Splashtop OS, quickly and without having to
+install Splashtop OS itself.
+
+Splashtop OS boot process
+-------------------------
+When the Splashtop button is pressed:
+- After POST, the BIOS loads the option ROM (containing the DeviceVM ROM
+Loader and a CE program) at 0x7c00 and jumps there.
+- The ROM Loader switches the computer to protected mode and transfers control
+to the CE program, looking for splash.idx at the root of a FAT32 or NTFS
+partition in the HDD.
+- If the file is found, then the program will look for CEFULL in the directory
+(except the root) as mentioned in the second line of splash.idx.
+- If CEFULL is present, it is copied to 0x100000 [1] and execution is
+transfered to this address.
+- CEFULL looks for kernel.bin in one of the FAT32 or NTFS partitions, in the
+given directory from splash.idx. kernel.bin is the combination of a vmlinuz and
+an initrd.img.
+- Once kernel.bin is loaded, the rest of Splashtop OS initialization is left
+to the Linux kernel.
+
+[1] as for the Linux kernel bzImages. The CE_BZ files used with systems with
+no Splashtop button or starting Splashtop OS from a USB stick are also bzImages
+(CE_BZ = linux_head.S + CEFULL), which allows starting Splashtop OS from a
+classic boot loader (Splashtop usually uses a custom version of GRUB).
+
+Solutions
+---------
+1. Patch the option ROM, but on the one hand, this solution doesn't come
+without risk and on the other hand, it would be difficult to find a universal
+method, as the integration of Splashtop by manufacturers may vary.
+
+2. Integrate kexec in Splashtop OS, in order to run another kernel from
+Splashtop Linux kernel, but on the one hand, this method required to have
+Splashtop OS installed and on the other hand, you can lose up to 15 seconds
+between booting and kexec call, the time Splashtop OS takes to be initialized.
+
+3. Build a custom kernel.bin, except that the format of kernel.bin remains
+unknown and only Splashtop developers have access to the tools that would
+allow us to build this file.
+
+4. Execute our own boot loader from CEFULL, so we need to write a program that
+reproduces the CEFULL format and switches the computer back to real mode with
+our boot loader copied to 0x7c00, simulating the 19h interrupt without having
+to load specific drivers to access our boot loader from the HDD. stboot is an
+implementation of this method. 
+
+Usage
+-----
+- Assembly:
+The generated CEFULL from stboot.asm consists of a header, the code preparing
+bootstrap and the boot sector "bootsect.bin" of your choice. You can build
+your own CEFULL by assembling stboot.asm with yasm:
+
+  $ cp -f [custom_bootsector] bootsect.bin
+  $ yasm -o CEFULL stboot.asm
+
+- Installation:
+A Splashtop OS installation is not required. On the other hand, a FAT32 or
+NTFS partition is necessary. In our example, the file tree of the partition
+containing CEFULL should look like this :
+
+─┬─stboot/
+ │   │
+ │   └CEFULL  (our own boot loader)
+ │
+ └─splash.idx (shows CEFULL location)
+
+This ready-for-use file tree is available in the root-example directory. At this
+point, the boot loader configuration is entirely up to you. In the default
+installation, the bootsect.bin included in CEFULL is a minimal bootloader which
+looks for and loads the boot sector of the first active partition found.
+
+However, you are free to integrate your own boot sector into CEFULL.
+Typically, extraction of a boot sector in Linux (or any Unix-like) is performed
+with the dd utility like this:
+
+  # dd if=/dev/[disk|partition] of=1st_sect.bin bs=512 count=1
+
+Please refer to the "Assembly" section above for the boot sector integration
+into CEFULL.
+
+Known limitations
+-----------------
+- Memory mapping only occurs in a 32-bit address space, the BIOS apparently
+doesn't do memory hole remapping when booting Splashtop, since Splashtop OS is
+supposed to be 32-bit only. This shouldn't prevent you from loading a 64-bit
+kernel but it will never access more than 4 GB of RAM (and around 3 GB in
+practice because of MMIO).
+- SATA controllers are limited to Compatible (IDE) mode, even if the BIOS
+supports AHCI mode under normal conditions.
+
+---
+END OF README

README-fr

@@ -0,0 +1,119 @@
+-----------------------------------------------------------------
+stboot - un remplacement de CEFULL
+et un chargeur d'amorçage pour les systèmes compatibles Splashtop
+-----------------------------------------------------------------
+par trya - [email protected]
+
+DISCLAMER :
+IL N’Y A AUCUNE GARANTIE POUR LE PROGRAMME, DANS LES LIMITES PERMISES PAR LA
+LOI APPLICABLE. À MOINS QUE CELA NE SOIT ÉTABLI DIFFÉREMMENT PAR ÉCRIT, LES
+PROPRIÉTAIRES DE DROITS ET/OU LES AUTRES PARTIES FOURNISSENT LE PROGRAMME « EN
+L’ÉTAT » SANS GARANTIE D’AUCUNE SORTE, QU’ELLE SOIT EXPRIMÉE OU IMPLICITE, CECI
+COMPRENANT, SANS SE LIMITER À CELLES-CI, LES GARANTIES IMPLICITES DE
+COMMERCIALISABILITÉ ET D’ADÉQUATION À UN OBJECTIF PARTICULIER. VOUS ASSUMEZ LE
+RISQUE ENTIER CONCERNANT LA QUALITÉ ET LES PERFORMANCES DU PROGRAMME. DANS
+L’ÉVENTUALITÉ OÙ LE PROGRAMME S’AVÉRERAIT DÉFECTUEUX, VOUS ASSUMEZ LES COÛTS
+DE TOUS LES SERVICES, RÉPARATIONS OU CORRECTIONS NÉCESSAIRES.
+
+Objectif
+--------
+Ce programme permet d'utiliser le bouton de démarrage de Splashtop (et
+apparentés) afin de lancer un OS autre que Splashtop OS, de manière rapide et
+sans avoir à installer Splashtop OS lui-même.
+
+Procédure de démarrage de Splashtop OS
+--------------------------------------
+Quand le bouton Splashtop est pressé :
+- Après le POST, le BIOS charge la ROM option (contenant le DeviceVM ROM Loader
+et un programme CE) à l'adresse 0x7c00 et saute à cet endroit.
+- Le DeviceVM Rom Loader fait passer l'ordinateur en mode protégé et transfère
+le contrôle au programme CE, chargé de rechercher un fichier splash.idx à la
+racine d'une partition FAT32 ou NTFS du disque dur.
+- Si ce fichier est trouvé, alors le programme CE va chercher un fichier CEFULL
+dans le dossier (sauf la racine) indiqué dans la deuxième ligne de splash.idx.
+- Si CEFULL est présent, il est copié à l'adresse 0x100000 [1] et le contrôle
+est passé à cette adresse.
+- CEFULL recherche un fichier kernel.bin dans une des partitions FAT32 ou NTFS
+à l'endroit indiqué par splash.idx. kernel.bin est la combinaison d'un vmlinuz
+et d'un initrd.img.
+- Une fois kernel.bin chargé, le reste de l'initialisation de Splashtop OS est
+laissé au noyau Linux.
+
+[1] comme pour les bzImages du noyau Linux. Les fichiers CE_BZ utilisés avec
+les systèmes n'ayant pas de bouton Splashtop ou démarrant Splashtop OS à partir
+d'une clé USB sont aussi des bzImages (CE_BZ = linux_head.S + CEFULL),
+permettant ainsi le démarrage de Splashtop OS à partir d'un chargeur de
+démarrage classique (Splashtop OS utilise habituellement une version modifiée
+de GRUB).
+
+Solutions
+---------
+1. Patcher la ROM option, mais d'une part, cette solution n'est pas sans risque
+et d'autre part, il serait difficile d'en faire une méthode universelle sachant
+que l'intégration de Splashtop par les constructeurs peut varier.
+
+2. Intégrer kexec dans Splashtop OS, afin de lancer un autre noyau
+à partir du noyau Linux de Splashtop, mais d'une part cette méthode nécessite
+d'avoir installé Splashtop OS et d'autre part, on peut perdre jusqu'à 15
+secondes entre le démarrage de l'ordinateur et l'appel à kexec, le temps
+que Splashtop OS soit initialisé.
+
+3. Construire un kernel.bin personnalisé, sauf que le format de kernel.bin
+reste inconnu et seuls les développeurs de Splashtop ont accès aux outils
+permettant de construire ce fichier.
+
+4. Exécuter notre propre chargeur d'amorçage à partir de CEFULL, ce qui
+nécessite d'écrire un programme reproduisant le format d'un CEFULL et faisant
+repasser l'ordinateur en mode réel avec notre chargeur d'amorçage copié à
+l'adresse 0x7c00, simulant ainsi l'interruption 19h sans avoir à charger des
+pilotes spécifiques pour accéder à notre chargeur d'amorçage sur le disque dur.
+stboot est une implémentation de cette méthode.
+
+Utilisation de stboot
+---------------------
+- Assemblage :
+Le CEFULL généré à partir de stboot.asm est composé d'un en-tête, du code
+préparant l'amorçage et du secteur de boot "bootsect.bin" de votre choix.
+Vous pouvez construire votre propre CEFULL en assemblant stboot.asm avec yasm :
+
+  $ cp -f [custom_bootsector] bootsect.bin
+  $ yasm -o CEFULL stboot.asm
+
+- Installation :
+Une installation de Splashtop OS n'est pas nécessaire, une partition FAT32 ou
+NTFS est par contre obligatoire. L'arborescence de la partition contenant CEFULL
+doit être la suivante :
+
+─┬─stboot/
+ │   │
+ │   └CEFULL  (notre propre chargeur d'amorçage)
+ │
+ └─splash.idx (indique l'emplacement de CEFULL)
+
+Cette arborescence prête à l'emploi est disponible dans le dossier root-example.
+À ce moment-là, la configuration du chargeur d'amorçage dépend entièrement de
+vous. Dans l'installation par défaut, le bootsect.bin inclus dans CEFULL est un
+chargeur d'amorçage minimal qui recherche et charge le secteur de boot de la
+première partition active trouvée.
+
+Cependant, vous êtes libre d'intégrer votre propre secteur de boot dans CEFULL,
+Typiquement, l'extraction d'un secteur de boot sous Linux (ou Unix-like)
+s'effectue avec le programme dd de cette manière :
+
+  # dd if=/dev/[disque|partition] of=1st_sect.bin bs=512 count=1
+
+Référez-vous au paragraphe "Assemblage" au-dessus pour l'intégration du secteur
+de boot dans CEFULL.
+
+Limitations connues
+-------------------
+- Le "memory mapping" ne se produit que dans un espace mémoire 32 bits, le BIOS
+ne fait pas apparemment de "memory hole remapping" quand Splashtop est démarré,
+puisque Splashtop OS est censé être uniquement un système 32 bits. Cela ne
+devrait pas vous empêcher de charger un noyau 64 bits mais il ne pourra jamais
+accéder à plus de 4 Go de RAM (et environ 3 Go en pratique à cause du MMIO).
+- Les contrôleurs SATA sont limités au mode Compatible (IDE), même si le BIOS
+supporte le mode AHCI en temps normal.
+
+---
+FIN DU README