---410349432-1993828638-910703506=:2232
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.04.9811101414021.467@zagadka.crans.ens-cachan.fr>
1) What is it
-------------
This patch follows my previous calls for help. Fortunately, I finally
managed to cook something which works at least on my machine.
I'd really appreciate other people try it out, in particular if people
with ACPI BIOSes could send me the result of "cat /proc/sysmemmap".
The thing is at
http://www.crans.ens-cachan.fr/~chepelov/linux/qsam-2.1.127.patch
and is against pristine 2.1.127
2) What it does
---------------
Basically, it calls the BIOS using int15/E820 to get a more precise map of
the extended memory than the previously used int15/E801 or int15/88 (of
course if E820 isn't here, it falls back to the previous behaviour).
The reason for doing this is that ACPI BIOSes give some really important
tables (whole p-code drivers for the power management), somewhere in
extended memory, which is usually clobbered by Linux.
A very good side effect of this patch is that configurations with memory
holes are supported too (see the attached /proc/sysmemmap demo), without
wasting all the memory above the first hole (not counting the ROM).
(please note I still have to upgrade my BIOS to get ACPI support
(TX97-XE). Otherwise an AddressRangeACPI would have appeared in the
sysmemmap)
It is running very solid on my machine, and successfully passed "make -j
10 bzImage".
It should not break for people using broken Thinkpads (as originally
complained in arch/i386/mm/init.c)
The QSAM interface can theoretically support 64-bit address space (though
my implementation doesn't).
3) Why this patch
-----------------
* Adding ACPI support will require having access to the ACPI tables.
Either we get an arbitrary length buffer between the 16-bit and 32-bit
early boot code, and copy the ACPI tables there, or we simply tell Linux
to let these tables alone and use them later, while initialising the ACPI
module (much better IMHO)
* Currently, machines with memory holes were limited to using the memory
under the first hole (BIOS ROM not counted). This is not the case anymore
with this patch.
* Self-learning tool (my first > 3 line patch, and my first public one)
3) Potential problems
---------------------
* I had to find a ~1k communication area between the 16-bit and the 32-bit
parts of the early boot code. Since the kernel seems to process only the
first 256 bytes of the command line arguments, I have truncated the
cmdline buffer to 256 bytes and stole 1028 bytes above that.
Though I have experimented no problems (with vgacon and vesafb), there was
some argument buffer magic in arch/i386/kernel/head.S I did not
fully understand, but I nonetheless deleted as it was in my way.
I'd really love to be taught a better way to pass that 1kb buffer.
* The assembly code is not totally optimal. It works for me, at least.
* While it works for me, I must have made a beginner's big mistake in
arch/i386/mm/init.c . I'd really appreciate a mm guru's comment on my
modifications.
* My coding style is probably not totally up to the standards and
certainly needs some reworking.
I'll welcome any comments !
-- Cyrille
---410349432-1993828638-910703506=:2232
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=proc_sysmemmap_with_hole
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.04.9811101411460.2232@zagadka.crans.ens-cachan.fr>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME=proc_sysmemmap_with_hole
emFnYWRrYSVjYXQgL3Byb2Mvc3lzbWVtbWFwICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfg0KU3lzdGVtIG1l
bW9yeSBtYXAgZW50cmllczogNw0KICBBZGRyPTB4MDAwMDAwMDAwMDAwMDAw
MCBMZW5ndGg9MHgwMDAwMDAwMDAwMDlmYzAwIFR5cGU9MSBBZGRyZXNzUmFu
Z2VNZW1vcnkNCiAgQWRkcj0weDAwMDAwMDAwMDAwOWZjMDAgTGVuZ3RoPTB4
MDAwMDAwMDAwMDAwMDQwMCBUeXBlPTIgQWRkcmVzc1JhbmdlUmVzZXJ2ZWQN
CiAgQWRkcj0weDAwMDAwMDAwMDAwZjAwMDAgTGVuZ3RoPTB4MDAwMDAwMDAw
MDAxMDAwMCBUeXBlPTIgQWRkcmVzc1JhbmdlUmVzZXJ2ZWQNCiAgQWRkcj0w
eDAwMDAwMDAwMDAxMDAwMDAgTGVuZ3RoPTB4MDAwMDAwMDAwMGQwMDAwMCBU
eXBlPTEgQWRkcmVzc1JhbmdlTWVtb3J5DQogIEFkZHI9MHgwMDAwMDAwMDAw
ZTAwMDAwIExlbmd0aD0weDAwMDAwMDAwMDAyMDAwMDAgVHlwZT0yIEFkZHJl
c3NSYW5nZVJlc2VydmVkDQogIEFkZHI9MHgwMDAwMDAwMDAxMDAwMDAwIExl
bmd0aD0weDAwMDAwMDAwMDUwMDAwMDAgVHlwZT0xIEFkZHJlc3NSYW5nZU1l
bW9yeQ0KICBBZGRyPTB4MDAwMDAwMDBmZmZmMDAwMCBMZW5ndGg9MHgwMDAw
MDAwMDAwMDEwMDAwIFR5cGU9MiBBZGRyZXNzUmFuZ2VSZXNlcnZlZA0KDQoj
IHRoZXJlJ3MgYSBob2xlIGJldHdlZW4gMTQgYW5kIDE2IE1iLiBTdG9jayBr
ZXJuZWwgd291bGQgaGF2ZSB1c2VkIG9ubHkNCmFib3V0IDEzIE1iIG9mIFJB
TSwgaWdub3JpbmcgODAgTWIgIQ0KemFnYWRrYSVjYXQgL3Byb2MvbWVtaW5m
byAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfg0KICAgICAgICB0b3RhbDogICAgdXNlZDogICAgZnJlZTog
IHNoYXJlZDogYnVmZmVyczogIGNhY2hlZDoNCk1lbTogIDk2MDQ3MTA0IDg5
ODc0NDMyICA2MTcyNjcyIDMzNzEwMDgwICA1ODgxODU2IDU5ODc5NDI0DQpT
d2FwOiAyNjcwMDE4NTYgIDIzMTQyNDAgMjY0Njg3NjE2DQpNZW1Ub3RhbDog
ICAgIDkzNzk2IGtCDQpNZW1GcmVlOiAgICAgICA2MDI4IGtCDQpNZW1TaGFy
ZWQ6ICAgIDMyOTIwIGtCDQpCdWZmZXJzOiAgICAgICA1NzQ0IGtCDQpDYWNo
ZWQ6ICAgICAgIDU4NDc2IGtCDQpTd2FwVG90YWw6ICAgMjYwNzQ0IGtCDQpT
d2FwRnJlZTogICAgMjU4NDg0IGtCDQo=
---410349432-1993828638-910703506=:2232--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/