I've finally got round to trying out the BIOS memory detection functions, and it turns out that I don't appear to have any machines with a 15-16MB memory hole. Some of my machines don't support any of the BIOS memory detection functions, but the ones that do only support the E820 one, while the rest (E801, E881, DA88, 88 and 8A) all return 86h in ah to say that they aren't supported. I had expected them all to work if the BIOS supports E820 because an older OS which doesn't know about E820 would find the older functions useful, but it looks as if they are left to probe for memory instead. This seems odd and leads me to wonder if I'm doing something wrong - is it normal for E801, E881, DA88, 88 and 8A to be unsupported on machines where E820 is supported?
When using E820 I'm getting a single table entry each time (typically the fourth entry) covering from the 1MB point right up to near the top of memory, followed by a couple of ACPI entries, so does that guarantee that there's no memory hole from 15 to 16MB? If there is no memory hole there, does that mean that some other part of memory has mapped I/O ports in it which I must avoid reading? Clearly if the memory is labelled with a 1 or a 5 it's going to be safe to read it, if it's a 2 it might not be safe to read it, if it's a 3 (ACPI reclaimable) it is presumably safe to read it, but if it's a 4 (ACPI non-reclaimable) should I take that as meaning it isn't safe to read it, or is it only harmful to write to it? Because my OS lets the user scroll around through machine memory to view the contents, I need to be sure that it blocks any areas that are unsafe, but I don't want to block them if they are safe because I want to make the machine as open as possible for people who want to explore it.
Memory detection and memory hole questions
- DavidCooper
- Member
- Posts: 1150
- Joined: Wed Oct 27, 2010 4:53 pm
- Location: Scotland
Memory detection and memory hole questions
Help the people of Laos by liking - https://www.facebook.com/TheSBInitiative/?ref=py_c
MSB-OS: http://www.magicschoolbook.com/computing/os-project - direct machine code programming
MSB-OS: http://www.magicschoolbook.com/computing/os-project - direct machine code programming
- Owen
- Member
- Posts: 1700
- Joined: Fri Jun 13, 2008 3:21 pm
- Location: Cambridge, United Kingdom
- Contact:
Re: Memory detection and memory hole questions
ACPI reclaimable (3) memory can be used as soon as you are finished with the ACPI tables. NVS memory (4) "is in use or reserve by the system and must not be used by the operating system. This range is required to be saved and restored across an NVS sleep." The fact that it must be saved and restored indicates that it is presumably readable... though this may only be the case when certain ACPI operations are happening
Unusable (5) memory I would say is probably safe to read... probably. There is always the possibility that touching it would cause bus errors.
Reserved (2) can be devices. I would assume the same for disabled (6), and any other undefined types.
Unusable (5) memory I would say is probably safe to read... probably. There is always the possibility that touching it would cause bus errors.
Reserved (2) can be devices. I would assume the same for disabled (6), and any other undefined types.
Re: Memory detection and memory hole questions
Hi,
For 80386 and later, it's very unlikely that a computer supports none of the functions at all. Typically for 80486 and later they support something (but if none of the functions are supported then try CMOS locations 0x17 and 0x18).
Also note that if E820 isn't supported then there is no ACPI (and therefore you don't need to worry about ACPI reclaimable or ACPI NVS areas).
Cheers,
Brendan
The 15-16 MiB memory hole is for ISA devices (the ISA bus is limited to 24-bit addresses, so this hole couldn't be higher). On motherboards that have no ISA slots it's pointless, and on motherboards that have both ISA and PCI it's likely there's an "enable ISA memory hole" BIOS option. For computers that have ISA but don't have PCI, there's probably only 8 MiB (or less) RAM anyway.DavidCooper wrote:I've finally got round to trying out the BIOS memory detection functions, and it turns out that I don't appear to have any machines with a 15-16MB memory hole.
It's possible for all the older BIOS functios to be unsupported (if E820 is supported). In my experience, it's rare for a computer to only support E820 and nothing else (but I'd assume newer computers are more likely to omit the older functions).DavidCooper wrote:Some of my machines don't support any of the BIOS memory detection functions, but the ones that do only support the E820 one, while the rest (E801, E881, DA88, 88 and 8A) all return 86h in ah to say that they aren't supported. I had expected them all to work if the BIOS supports E820 because an older OS which doesn't know about E820 would find the older functions useful, but it looks as if they are left to probe for memory instead. This seems odd and leads me to wonder if I'm doing something wrong - is it normal for E801, E881, DA88, 88 and 8A to be unsupported on machines where E820 is supported?
For 80386 and later, it's very unlikely that a computer supports none of the functions at all. Typically for 80486 and later they support something (but if none of the functions are supported then try CMOS locations 0x17 and 0x18).
Also note that if E820 isn't supported then there is no ACPI (and therefore you don't need to worry about ACPI reclaimable or ACPI NVS areas).
It'd be easier to pretend to let them scroll through the memory - nobody wants to see it anything above the first 1 MiB, so nobody will notice...DavidCooper wrote:Because my OS lets the user scroll around through machine memory to view the contents, I need to be sure that it blocks any areas that are unsafe, but I don't want to block them if they are safe because I want to make the machine as open as possible for people who want to explore it.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
- DavidCooper
- Member
- Posts: 1150
- Joined: Wed Oct 27, 2010 4:53 pm
- Location: Scotland
Re: Memory detection and memory hole questions
Thanks for the replies.
I'll play it safe and just block it - if anyone's determined to explore it they can remove the blocking code, but I'm not keen to explore it as there's no real point in doing so.Owen wrote:NVS memory (4) ... The fact that it must be saved and restored indicates that it is presumably readable...
I'll assume it's safe, but I'll label it as damaged and see if anyone ever reports a problem with it.Unusable (5) memory I would say is probably safe to read... probably. There is always the possibility that touching it would cause bus errors.
I hadn't thought about numbers > 5, so I'd better just block them all if they occur.I would assume the same for disabled (6), and any other undefined types.
One of them's a Compaq presario 1200 which is pretty ancient, but it only seems to respond to E820. Maybe I'm doing something wrong - I'll check my code later.Brendan wrote:It's possible for all the older BIOS functios to be unsupported (if E820 is supported). In my experience, it's rare for a computer to only support E820 and nothing else (but I'd assume newer computers are more likely to omit the older functions).
My only currently-functioning 486 doesn't respond to any of the functions, so that's another reason to think there may be an error in my code, though it's so simple that it doesn't make it easy to get it wrong. I haven't tried looking at the CMOS memory info yet, but there seem to be enough options there to sort out something reliable for any machine that lacks E820, even if that means just assuming there's a 15MB memory hole.For 80386 and later, it's very unlikely that a computer supports none of the functions at all. Typically for 80486 and later they support something (but if none of the functions are supported then try CMOS locations 0x17 and 0x18).
They might well want to scroll through the ACPI tables, and they'll certainly want to be able to scroll through any area of memory where their files and program code can be loaded in - they may need to view and edit the contents of memory directly for any number of reasons. I find it extremely useful being able to jump to different memory locations to check that things are there and that they look right, as well as to hack their contents to correct faults or modify the way they work.It'd be easier to pretend to let them scroll through the memory - nobody wants to see it anything above the first 1 MiB, so nobody will notice...
Help the people of Laos by liking - https://www.facebook.com/TheSBInitiative/?ref=py_c
MSB-OS: http://www.magicschoolbook.com/computing/os-project - direct machine code programming
MSB-OS: http://www.magicschoolbook.com/computing/os-project - direct machine code programming