Robert Millan wrote:
On Mon, Dec 31, 2007 at 04:40:00PM +0100, Christian Franke wrote:
This version of the patch contains only the fix for the E801 EISA memory
map. The memory existence check was helpful for testing but is not
really necessary.
I think the memory existence check
Robert Millan wrote:
...
This part is intended to handle the (normal) case of one continuous
region with not gap between 1M and 16M:
(0x3C00 10) = 0x10 * 15 = 15M
But this part does not work due to the same bug.
It is IMO not necessary to make this distinction. The function
On Tue, Jan 01, 2008 at 07:03:36PM +0100, Christian Franke wrote:
Ah, ok. Have you verified that this is so? (setting debug=mem variable
during init might help on that).
Yes. During testing, I temporarily added some diagnostic output. The
function compact_mem_regions() works as
This version of the patch contains only the fix for the E801 EISA memory
map. The memory existence check was helpful for testing but is not
really necessary.
But this bug should be fixed, otherwise GRUB2 would crash if BIOS does
not provide the E820 memory map.
Christian
2007-12-31
Robert Millan wrote:
On Tue, Oct 23, 2007 at 09:06:16PM +0200, Christian Franke wrote:
+/* Check memory address */
+static int
+addr_is_valid (grub_addr_t addr)
+{
+ volatile unsigned char * p = (volatile unsigned char *)addr;
+ unsigned char x, y;
+ x = *p;
+ *p = x ^ 0xcf;
+ y = *p;
+
On Sun, Nov 18, 2007 at 12:09:25PM +0100, Marco Gerards wrote:
Robert Millan [EMAIL PROTECTED] writes:
On Fri, Nov 09, 2007 at 10:53:23PM +0100, Christian Franke wrote:
Ah, and why 0xcf instead of 0xff ?
... or 0xaa or 0x55.
0xaa and 0x55 are typicaly used directly in
On Tue, Oct 23, 2007 at 09:06:16PM +0200, Christian Franke wrote:
+/* Check memory address */
+static int
+addr_is_valid (grub_addr_t addr)
+{
+ volatile unsigned char * p = (volatile unsigned char *)addr;
+ unsigned char x, y;
+ x = *p;
+ *p = x ^ 0xcf;
+ y = *p;
+ *p = x;
+
Robert Millan [EMAIL PROTECTED] writes:
On Fri, Nov 09, 2007 at 10:53:23PM +0100, Christian Franke wrote:
Ah, and why 0xcf instead of 0xff ?
... or 0xaa or 0x55.
0xaa and 0x55 are typicaly used directly in memory because every bit is
negated, which is precisely what `^ 0xff' would
On Sun, Nov 18, 2007 at 12:27:37PM +0100, Robert Millan wrote:
On Tue, Oct 23, 2007 at 09:06:16PM +0200, Christian Franke wrote:
+/* Check memory address */
+static int
+addr_is_valid (grub_addr_t addr)
+{
+ volatile unsigned char * p = (volatile unsigned char *)addr;
+ unsigned
Christian Franke [EMAIL PROTECTED] writes:
Marco Gerards wrote:
...
+static int
+addr_is_valid (grub_addr_t addr)
+{
+ volatile unsigned char * p = (volatile unsigned char *)addr;
Why volatile? I have the feeling it is not needed.
+ unsigned char x, y;
+ x = *p;
+ *p = x ^
Marco Gerards wrote:
Christian Franke [EMAIL PROTECTED] writes:
...
volatile is necessary here to tell the complier that the memory
address might not behave like regular memory. Otherwise, the optimizer
might legitimately remove memory accesses and then constant
propagation detects an
On Tue, Oct 23, 2007 at 09:06:16PM +0200, Christian Franke wrote:
+/* Check memory address */
+static int
+addr_is_valid (grub_addr_t addr)
+{
+ volatile unsigned char * p = (volatile unsigned char *)addr;
+ unsigned char x, y;
+ x = *p;
+ *p = x ^ 0xcf;
+ y = *p;
+ *p = x;
+
On Fri, Nov 09, 2007 at 10:53:23PM +0100, Christian Franke wrote:
Ah, and why 0xcf instead of 0xff ?
... or 0xaa or 0x55.
0xaa and 0x55 are typicaly used directly in memory because every bit is
negated, which is precisely what `^ 0xff' would do.
--
Robert Millan
GPLv2 I know my
This patch fixes the broken evaluation of the E801 EISA memory map. The
shift was too much, the high word is already shifted :-) The bug was
hidden until the E820 memory map evaluation was broken due to the struct
packing issue fixed in my last patch.
The extra handling of 0x3C00 case is IMO
On Tue, Oct 23, 2007 at 09:06:16PM +0200, Christian Franke wrote:
This patch fixes the broken evaluation of the E801 EISA memory map. The
shift was too much, the high word is already shifted :-) The bug was
hidden until the E820 memory map evaluation was broken due to the struct
packing
Robert Millan wrote:
On Tue, Oct 23, 2007 at 09:06:16PM +0200, Christian Franke wrote:
This patch fixes the broken evaluation of the E801 EISA memory map. The
shift was too much, the high word is already shifted :-) The bug was
hidden until the E820 memory map evaluation was broken due to
16 matches
Mail list logo
