public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* BOOT_CS
@ 2004-02-21  5:47 H. Peter Anvin
  2004-02-21 12:43 ` BOOT_CS Coywolf Qi Hunt
                   ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: H. Peter Anvin @ 2004-02-21  5:47 UTC (permalink / raw)
  To: linux-kernel

Anyone happen to know of any legitimate reason not to reload %cs in
head.S?  I think the following would be a lot cleaner, as well as a
lot safer (the jump and indirect branch aren't guaranteed to have the
proper effects, although technically neither should be required due to
the %cr0 write):

@@ -117,10 +147,7 @@
        movl %cr0,%eax
        orl $0x80000000,%eax
        movl %eax,%cr0          /* ..and set paging (PG) bit */
-       jmp 1f                  /* flush the prefetch-queue */
-1:
-       movl $1f,%eax
-       jmp *%eax               /* make sure eip is relocated */
+       ljmp $__BOOT_CS,$1f     /* Clear prefetch and normalize %eip
*/
 1:
        /* Set up the stack pointer */
        lss stack_start,%esp


I've been doing some cleanups in head.S after making the early page
tables dynamic.

	-hpa

^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: BOOT_CS
@ 2004-02-24 10:05 Etienne Lorrain
  2004-02-24 15:39 ` BOOT_CS H. Peter Anvin
  0 siblings, 1 reply; 28+ messages in thread
From: Etienne Lorrain @ 2004-02-24 10:05 UTC (permalink / raw)
  To: linux-kernel; +Cc: H. Peter Anvin

> H. Peter Anvin writes:
> > Eric W. Biederman wrote:
> > for those folks who want to place their ramdisk as low
> > in memory as possible?
> The problem is that you don't know until it's too late, since it can 
> depend on dynamic factors.  This is part of why your insistence of 
> putting the ramdisk in the "most incorrect" position is simply wrong.

  The other problem is for the people who want to check the validity
 of the RAM disk before starting Linux - for instance by checking
 the CRC32 of the decompressed RAM disk - and stop the boot process
 before it is too late - i.e. in the bootloader when you can select
 another kernel version / initrd to load.
  You cannot place the decompressed initrd at a maximum address before
 knowing its decompressed size - the address to place it is the max
 address (or the end of free RAM) minus ramdisk size if I remember
 correctly. That is working for so long loading the decompressed
 initrd after few Mb after the last kernel byte (so that the kernel
 will move it where it wants - no need to move it twice) that I do
 not remember the details. Did you changed this part?

  Etienne.

Yahoo! Mail - Votre e-mail personnel et gratuit qui vous suit partout !
 Créez votre adresse sur http://mail.yahoo.fr

^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: BOOT_CS
@ 2004-02-25 10:30 Etienne Lorrain
  2004-02-25 16:23 ` BOOT_CS H. Peter Anvin
  0 siblings, 1 reply; 28+ messages in thread
From: Etienne Lorrain @ 2004-02-25 10:30 UTC (permalink / raw)
  To: linux-kernel

me wrote:
> Keep initrd few Mb after kernel because I do not know where exactly
> to uncompress it - anyway the kernel will itself move it where it
> wants it.

hpa wrote:
> If you absolutely want to do this -- for pretty much no reason -- you
> can either decompress it twice, decompress it to nowhere (after all,
> the kernel will decompress it when it starts) or move it into place
> before starting the kernel.

  There is another reason to keep the two parts together, but I
 acknowledge this one is fadding away: the problem appears when loading
 Linux (+ initrd) from a DOS floppy or from operating system dated 98
 "reboot to DOS" menu.
 You then usually have an environment whith EMM386 active and the
 processor in virtual 86 mode + paged memory. Most of the times you
 also have a disk cache software loaded first just after the BIOS
 ROM, at the place you want to load Linux.
 You can still have hope: it has always been possible to do DMA in a
 XMS allocated memory (himem.sys managed) so the physical address is
 equal to the virtual address in these blocks.

 What I did is simply load and uncompress Linux to a legally allocated
 HIMEM block (so that is a 100 % compatible DOS software, you can use
 a network disk or a disk cache for that) and check everything is right
 before disabling interruption, switch back to real mode with
 4 Gb segments of non paged memory, copy the block at the right place, 
 and start Linux in protected mode.
 You have to remember keeping the code short in between the back switch
 to real mode and the start of Linux because the data (Linux kernel)
 is at a clear physical address, but your code itself is in a 4 Kbyte
 page which is available - but the page after it may not be loaded
 so no more code...

 When the problem of loading the initrd happen, you have two choice:
 load another XMS block or use the same one as the kernel.
 And here is the problem: if you load another XMS block with the
 initrd, which is usually smaller than the kernel (Kb size wise),
 you may get it in a block of XMS at the _beginning_ of extended
 memory in physical address - because of the first fit algorithm of
 himem.sys. Then, to move the kernel at its final position, you have
 to first move the initrd out of the way to not overwrite it, it
 begins to be complex to write this bit of assembler and debug at
 this point is not so easy.
 That is the short version why in some cases I did not try to load the
 initrd at the end of memory (just allocating one big block of XMS memory
 with a hole of few Mbytes in between the two - and then move the
 complete block - the complete block could not be of the size of the
 total memory). And if it is not always done, to move initrd at end,
 no need to do it only sometimes.
 Note also that in this corner case the size of the RAM may be tricky
 and could be given as a Linux command line parameter, so the position
 of the initrd is not trivial. I do not want to load the initrd after the
 RAM itself...

  Was just for info, not for flamewar,
  Etienne.

Yahoo! Mail - Votre e-mail personnel et gratuit qui vous suit partout !
 Créez votre adresse sur http://mail.yahoo.fr

^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: BOOT_CS
@ 2004-02-26 12:17 Etienne Lorrain
  2004-02-26 21:49 ` BOOT_CS Denis Vlasenko
  2004-02-27 18:41 ` BOOT_CS H. Peter Anvin
  0 siblings, 2 replies; 28+ messages in thread
From: Etienne Lorrain @ 2004-02-26 12:17 UTC (permalink / raw)
  To: linux-kernel

> >  What I did is simply load and uncompress Linux to a legally allocated
> >  HIMEM block (so that is a 100 % compatible DOS software, you can use
> >  a network disk or a disk cache for that) and check everything is right
> >  before disabling interruption, switch back to real mode with
> >  4 Gb segments of non paged memory, copy the block at the right place, 
> >  and start Linux in protected mode.
> 
> [...]
> 
> There is a hook in the kernel immediately after enteing protected mode
> for *exactly* this reason -- it was added to support LOADLIN.  The
> whole point is that your boot loader obtains control at that point so
> you can put things back where they need to go (such as 0x100000 for
> the main part of the kernel, which you will *never* get from an
> HMA-enabled DOS.)  The algorithm for that is pretty straightforward;
> you can even deal with the case where you have scattered pages all
> over memory.

  This interface is nice when the VCPI is loaded and running, but if
 only EMM386 is loaded and VCPI not active you cannot use it.

 Extract of "manual.txt" of "lodlin16.tgz":
>>>>>>>>>>>>
 Therefore:
 - You must be in 86 real mode (no EMS driver, no WINDOWS, no Windows 95
Graphics mode ...). or
 - You must have the VCPI server enabled in your EMS driver (still not
running WINDOWS or Windows 95, however).
   Using EMM386 please avoid the NOVCPI-option, but NOEMS doesn't hurt.
-------------
 May be that your VCPI server does garbage collection before entering
 protected mode, so please BE PATIENT, especially on systems with many
 mega bytes ! 
<<<<<<<<<<<<<<

  If the user of this boot floppy has not allocated some VCPI memory,
 usual for a boot floppy, the VCPI server is not active - only the
 GEMMIS interface is useable.

 Note that the user does not usually know in which mode the VCPI
 server is - and on this floppy lying in this box there is still maybe
 a EMM386/compatible software who cannot do VCPI.

 Moreover starting the VCPI server for just using the interface to
 exit it to real mode is really slow, the 4K pages have to be
 copied all other the place (the logical pages address increase
 with physical two lowest bit decreasing, pages are numbered
 0x13 0x12 0x11 0x10 0x17 0x16 0x15 0x14 ...).
 At last you are not guarantied some of the kernel pages have not been
 pushed to the swapping device (VCPI can do that if low memory).

 The GEMMIS interface is always available when VCPI is not present
 because that is the one the operating system dated 95/98 uses.

 With the latter interface you just do the XMS allocation and relocate
 like my bootloader. Once this is done, you do not need more work to
 support the case when the VCPI is running: the XMS allocation is
 still there and contigous memory.

 begining to be seriously off topic,
 Etienne.





	

	
		
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! 
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com

^ permalink raw reply	[flat|nested] 28+ messages in thread
end of thread, other threads:[~2004-02-27 18:42 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-21  5:47 BOOT_CS H. Peter Anvin
2004-02-21 12:43 ` BOOT_CS Coywolf Qi Hunt
2004-02-21 16:32   ` BOOT_CS Jamie Lokier
2004-02-23  4:43     ` [PATCH] BOOT_CS Coywolf Qi Hunt
2004-02-23 14:30       ` Jamie Lokier
2004-02-23 15:24         ` Rene Herman
2004-02-24  3:11         ` [PATCH] Remove the extra jmp Coywolf Qi Hunt
2004-02-24  3:30           ` Brian Gerst
2004-02-24 10:10             ` Coywolf Qi Hunt
2004-02-22 15:13 ` BOOT_CS Eric W. Biederman
2004-02-22 19:47   ` BOOT_CS H. Peter Anvin
2004-02-22 22:05     ` BOOT_CS Eric W. Biederman
2004-02-23 10:27 ` Does Flushing the Queue after PG REALLY a Necessity? Coywolf Qi Hunt
2004-02-23 15:18   ` Philippe Elie
2004-02-24  2:36     ` Coywolf Qi Hunt
2004-02-24  3:10       ` H. Peter Anvin
2004-02-24  4:55       ` Randy.Dunlap
2004-02-24  9:17         ` Coywolf Qi Hunt
2004-02-24 11:21           ` Herbert Poetzl
2004-02-24 11:33             ` Coywolf Qi Hunt
  -- strict thread matches above, loose matches on Subject: below --
2004-02-24 10:05 BOOT_CS Etienne Lorrain
2004-02-24 15:39 ` BOOT_CS H. Peter Anvin
2004-02-25 10:30 BOOT_CS Etienne Lorrain
2004-02-25 16:23 ` BOOT_CS H. Peter Anvin
2004-02-26 12:17 BOOT_CS Etienne Lorrain
2004-02-26 21:49 ` BOOT_CS Denis Vlasenko
2004-02-27 10:03   ` BOOT_CS Etienne Lorrain
2004-02-27 18:41 ` BOOT_CS H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox