Re: [PATCH] reserve_early end-of-conventional-memory to 1MB
* Alexander van Heukelum <[EMAIL PROTECTED]> wrote: > > Either way, the code should be shared between 32 and 64 bits. There > > is nothing bitsize-specific about it! > > Of course. That's also why I already added the old-Dell case ;). But > one problem at a time, please! i've applied your patch to x86.git#testing. Feel free to send a code-unification patch too :-) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reserve_early end-of-conventional-memory to 1MB
* Alexander van Heukelum [EMAIL PROTECTED] wrote: Either way, the code should be shared between 32 and 64 bits. There is nothing bitsize-specific about it! Of course. That's also why I already added the old-Dell case ;). But one problem at a time, please! i've applied your patch to x86.git#testing. Feel free to send a code-unification patch too :-) Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reserve_early end-of-conventional-memory to 1MB
Alexander van Heukelum wrote: Hello hpa, I failed to find a comment referring to 0x413 or int 0x12 in arch/x86/kernel. I do know the comment in Documentation/i386/boot.txt, however, suggesting that "INT 12h" _should_ be used, but that it would be pointless for zImage and old bzImage kernels, because they _have_ to be started from 0x9 anyway. New bzImage kernels do not have this limitation, and smart bootloaders simply put them at much lower addresses, like 0x4. (I know: you know.) My point is just that the argument not to use 0x413 in the bootloader is not valid for this case. OK, let me see if I can dig up the comment I thought I found at one point, and maybe found out the history behind it. Either that, or find out that my memory is faulty ;) -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reserve_early end-of-conventional-memory to 1MB
On Mon, 25 Feb 2008 10:13:17 -0800, "H. Peter Anvin" <[EMAIL PROTECTED]> said: > Alexander van Heukelum wrote: > > > > arch/x86/kernel/head64.c | 45 > > +++-- > > 1 files changed, 27 insertions(+), 18 deletions(-) > > > > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c > > index 38f32e7..b684552 100644 > > --- a/arch/x86/kernel/head64.c > > +++ b/arch/x86/kernel/head64.c > > @@ -49,33 +49,42 @@ static void __init copy_bootdata(char *real_mode_data) > > } > > } > > > > -#define EBDA_ADDR_POINTER 0x40E > > +#define BIOS_EBDA_SEGMENT 0x40E > > +#define BIOS_LOWMEM_KILOBYTES 0x413 > > > > Linus has specific comments in the 32-bit code that states we do not > want to use address 0x413 for anything - if nothing else because it's > often lowered when there is boottime code involved like CD-ROM booting > or PXE. Hello hpa, I failed to find a comment referring to 0x413 or int 0x12 in arch/x86/kernel. I do know the comment in Documentation/i386/boot.txt, however, suggesting that "INT 12h" _should_ be used, but that it would be pointless for zImage and old bzImage kernels, because they _have_ to be started from 0x9 anyway. New bzImage kernels do not have this limitation, and smart bootloaders simply put them at much lower addresses, like 0x4. (I know: you know.) My point is just that the argument not to use 0x413 in the bootloader is not valid for this case. That leaves the possibility that code/data is inserted at the top of conventional memory by either the BIOS or some kind of bootloader. My view on this is that this code/data should be preserved: it was specifically asked from us by lowering 0x413. One just loses a tiny bit of usable memory, and if the program booting the kernel knows better it can unload the driver if it wants to. It's just not a kernel problem. > Either way, the code should be shared between 32 and 64 bits. > There is nothing bitsize-specific about it! Of course. That's also why I already added the old-Dell case ;). But one problem at a time, please! Greetings, Alexander -- Alexander van Heukelum [EMAIL PROTECTED] -- http://www.fastmail.fm - I mean, what is it about a decent email service? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reserve_early end-of-conventional-memory to 1MB
Alexander van Heukelum wrote: arch/x86/kernel/head64.c | 45 +++-- 1 files changed, 27 insertions(+), 18 deletions(-) diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c index 38f32e7..b684552 100644 --- a/arch/x86/kernel/head64.c +++ b/arch/x86/kernel/head64.c @@ -49,33 +49,42 @@ static void __init copy_bootdata(char *real_mode_data) } } -#define EBDA_ADDR_POINTER 0x40E +#define BIOS_EBDA_SEGMENT 0x40E +#define BIOS_LOWMEM_KILOBYTES 0x413 Linus has specific comments in the 32-bit code that states we do not want to use address 0x413 for anything - if nothing else because it's often lowered when there is boottime code involved like CD-ROM booting or PXE. Either way, the code should be shared between 32 and 64 bits. There is nothing bitsize-specific about it! -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] reserve_early end-of-conventional-memory to 1MB
Explicitly reserve_early the whole address range from the end of
conventional memory as reported by the bios data area up to the
1Mb mark. Regard the info retrieved from the BIOS data area with
a bit of paranoia, though, because some biosses forget to register
the EBDA correctly.
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
--
I think this patch is against -x86.git#testing :-/.
Greetings,
Alexander
arch/x86/kernel/head64.c | 45 +++--
1 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 38f32e7..b684552 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -49,33 +49,42 @@ static void __init copy_bootdata(char *real_mode_data)
}
}
-#define EBDA_ADDR_POINTER 0x40E
+#define BIOS_EBDA_SEGMENT 0x40E
+#define BIOS_LOWMEM_KILOBYTES 0x413
+/*
+ * The BIOS places the EBDA/XBDA at the top of conventional
+ * memory, and usually decreases the reported amount of
+ * conventional memory (int 0x12) too.
+ */
static __init void reserve_ebda(void)
{
- unsigned ebda_addr, ebda_size;
+ unsigned int lowmem, ebda_addr;
- /*
-* there is a real-mode segmented pointer pointing to the
-* 4K EBDA area at 0x40E
-*/
- ebda_addr = *(unsigned short *)__va(EBDA_ADDR_POINTER);
+ /* end of low (conventional) memory */
+ lowmem = *(unsigned short *)__va(BIOS_LOWMEM_KILOBYTES);
+ lowmem <<= 10;
+
+ /* start of EBDA area */
+ ebda_addr = *(unsigned short *)__va(BIOS_EBDA_SEGMENT);
ebda_addr <<= 4;
- if (!ebda_addr)
- return;
+ /* Fixup: bios puts an EBDA in the top 64K segment */
+ /* of conventional memory, but does not adjust lowmem. */
+ if ((lowmem - ebda_addr) <= 0x1)
+ lowmem = ebda_addr;
- ebda_size = *(unsigned short *)__va(ebda_addr);
+ /* Fixup: bios does not report an EBDA at all. */
+ /* Some old Dells seem to need 4k anyhow (bugzilla 2990) */
+ if ((ebda_addr == 0) && (lowmem >= 0x9f000))
+ lowmem = 0x9f000;
- /* Round EBDA up to pages */
- if (ebda_size == 0)
- ebda_size = 1;
- ebda_size <<= 10;
- ebda_size = round_up(ebda_size + (ebda_addr & ~PAGE_MASK), PAGE_SIZE);
- if (ebda_size > 64*1024)
- ebda_size = 64*1024;
+ /* Paranoia: should never happen, but... */
+ if (lowmem >= 0x10)
+ lowmem = 0xa;
- reserve_early(ebda_addr, ebda_addr + ebda_size, "EBDA");
+ /* reserve all memory between lowmem and the 1MB mark */
+ reserve_early(lowmem, 0x10, "BIOS reserved");
}
void __init x86_64_start_kernel(char * real_mode_data)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reserve_early end-of-conventional-memory to 1MB
Alexander van Heukelum wrote: arch/x86/kernel/head64.c | 45 +++-- 1 files changed, 27 insertions(+), 18 deletions(-) diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c index 38f32e7..b684552 100644 --- a/arch/x86/kernel/head64.c +++ b/arch/x86/kernel/head64.c @@ -49,33 +49,42 @@ static void __init copy_bootdata(char *real_mode_data) } } -#define EBDA_ADDR_POINTER 0x40E +#define BIOS_EBDA_SEGMENT 0x40E +#define BIOS_LOWMEM_KILOBYTES 0x413 Linus has specific comments in the 32-bit code that states we do not want to use address 0x413 for anything - if nothing else because it's often lowered when there is boottime code involved like CD-ROM booting or PXE. Either way, the code should be shared between 32 and 64 bits. There is nothing bitsize-specific about it! -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] reserve_early end-of-conventional-memory to 1MB
Explicitly reserve_early the whole address range from the end of
conventional memory as reported by the bios data area up to the
1Mb mark. Regard the info retrieved from the BIOS data area with
a bit of paranoia, though, because some biosses forget to register
the EBDA correctly.
Signed-off-by: Alexander van Heukelum [EMAIL PROTECTED]
--
I think this patch is against -x86.git#testing :-/.
Greetings,
Alexander
arch/x86/kernel/head64.c | 45 +++--
1 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 38f32e7..b684552 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -49,33 +49,42 @@ static void __init copy_bootdata(char *real_mode_data)
}
}
-#define EBDA_ADDR_POINTER 0x40E
+#define BIOS_EBDA_SEGMENT 0x40E
+#define BIOS_LOWMEM_KILOBYTES 0x413
+/*
+ * The BIOS places the EBDA/XBDA at the top of conventional
+ * memory, and usually decreases the reported amount of
+ * conventional memory (int 0x12) too.
+ */
static __init void reserve_ebda(void)
{
- unsigned ebda_addr, ebda_size;
+ unsigned int lowmem, ebda_addr;
- /*
-* there is a real-mode segmented pointer pointing to the
-* 4K EBDA area at 0x40E
-*/
- ebda_addr = *(unsigned short *)__va(EBDA_ADDR_POINTER);
+ /* end of low (conventional) memory */
+ lowmem = *(unsigned short *)__va(BIOS_LOWMEM_KILOBYTES);
+ lowmem = 10;
+
+ /* start of EBDA area */
+ ebda_addr = *(unsigned short *)__va(BIOS_EBDA_SEGMENT);
ebda_addr = 4;
- if (!ebda_addr)
- return;
+ /* Fixup: bios puts an EBDA in the top 64K segment */
+ /* of conventional memory, but does not adjust lowmem. */
+ if ((lowmem - ebda_addr) = 0x1)
+ lowmem = ebda_addr;
- ebda_size = *(unsigned short *)__va(ebda_addr);
+ /* Fixup: bios does not report an EBDA at all. */
+ /* Some old Dells seem to need 4k anyhow (bugzilla 2990) */
+ if ((ebda_addr == 0) (lowmem = 0x9f000))
+ lowmem = 0x9f000;
- /* Round EBDA up to pages */
- if (ebda_size == 0)
- ebda_size = 1;
- ebda_size = 10;
- ebda_size = round_up(ebda_size + (ebda_addr ~PAGE_MASK), PAGE_SIZE);
- if (ebda_size 64*1024)
- ebda_size = 64*1024;
+ /* Paranoia: should never happen, but... */
+ if (lowmem = 0x10)
+ lowmem = 0xa;
- reserve_early(ebda_addr, ebda_addr + ebda_size, EBDA);
+ /* reserve all memory between lowmem and the 1MB mark */
+ reserve_early(lowmem, 0x10, BIOS reserved);
}
void __init x86_64_start_kernel(char * real_mode_data)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reserve_early end-of-conventional-memory to 1MB
On Mon, 25 Feb 2008 10:13:17 -0800, H. Peter Anvin [EMAIL PROTECTED] said: Alexander van Heukelum wrote: arch/x86/kernel/head64.c | 45 +++-- 1 files changed, 27 insertions(+), 18 deletions(-) diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c index 38f32e7..b684552 100644 --- a/arch/x86/kernel/head64.c +++ b/arch/x86/kernel/head64.c @@ -49,33 +49,42 @@ static void __init copy_bootdata(char *real_mode_data) } } -#define EBDA_ADDR_POINTER 0x40E +#define BIOS_EBDA_SEGMENT 0x40E +#define BIOS_LOWMEM_KILOBYTES 0x413 Linus has specific comments in the 32-bit code that states we do not want to use address 0x413 for anything - if nothing else because it's often lowered when there is boottime code involved like CD-ROM booting or PXE. Hello hpa, I failed to find a comment referring to 0x413 or int 0x12 in arch/x86/kernel. I do know the comment in Documentation/i386/boot.txt, however, suggesting that INT 12h _should_ be used, but that it would be pointless for zImage and old bzImage kernels, because they _have_ to be started from 0x9 anyway. New bzImage kernels do not have this limitation, and smart bootloaders simply put them at much lower addresses, like 0x4. (I know: you know.) My point is just that the argument not to use 0x413 in the bootloader is not valid for this case. That leaves the possibility that code/data is inserted at the top of conventional memory by either the BIOS or some kind of bootloader. My view on this is that this code/data should be preserved: it was specifically asked from us by lowering 0x413. One just loses a tiny bit of usable memory, and if the program booting the kernel knows better it can unload the driver if it wants to. It's just not a kernel problem. Either way, the code should be shared between 32 and 64 bits. There is nothing bitsize-specific about it! Of course. That's also why I already added the old-Dell case ;). But one problem at a time, please! Greetings, Alexander -- Alexander van Heukelum [EMAIL PROTECTED] -- http://www.fastmail.fm - I mean, what is it about a decent email service? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reserve_early end-of-conventional-memory to 1MB
Alexander van Heukelum wrote: Hello hpa, I failed to find a comment referring to 0x413 or int 0x12 in arch/x86/kernel. I do know the comment in Documentation/i386/boot.txt, however, suggesting that INT 12h _should_ be used, but that it would be pointless for zImage and old bzImage kernels, because they _have_ to be started from 0x9 anyway. New bzImage kernels do not have this limitation, and smart bootloaders simply put them at much lower addresses, like 0x4. (I know: you know.) My point is just that the argument not to use 0x413 in the bootloader is not valid for this case. OK, let me see if I can dig up the comment I thought I found at one point, and maybe found out the history behind it. Either that, or find out that my memory is faulty ;) -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
