The first thing I should say is that you need to be warned that the
Detecting Memory (x86) page, like far too many in the wiki, is not entirely up to date. For this, we have to apologize. We try to keep things up to date, but we can only do so much on a volunteer basis.
However, we can't say how relevant this is without more information about the system, what you have tried to do, and how you did it. Could you please tell us:
- Whether the test host uses a PC Legacy BIOS, an UEFI BIOS in Legacy mode, or an UEFI BIOS in the full UEFI mode (note that I am using 'BIOS' in the general sense here; most references to BIOS in PCs refer to the PC Legacy BIOS based on the original IBM PC, with UEFI being quite a different beast and not usually referred to as 'BIOS' as it usually isn't used as one after boot-up);
- whether you are running this live, or on an emulator (such as Bochs or QEMU) or virtualizer (such as QEMU/KVM, VirtualBox, or Hyper-V);
- how you are booting the system, specifically whether you are using the UEFI boot loader (if available), a stock boot loader such as GRUB or Boot Magic, or one you wrote yourself; and,
- just which method given in the wiki (or gotten anywhere else) you tried to use.
We really can't give definite answers without know this much, at minimum. It would help if you could also tell us:
- The PC model you are using for your testing host (if it is a pre-built model from a manufacturer such as Dell or HP) or motherboard model (if it is a component build);
- the brand and model of the CPU, if you know them (e.g., Intel Core 2 Duo, Pentium, Celeron, or i3/i5/i7/i9; AMD Opteron, Ryzen, etc.; or for non-PC systems, ARM A8 Cortex-M, MIPS64 rev 6, etc.) - for a standard PC, it will be in the docs, while presumably if you built the system yourself or ordered it custom you would already know;
- the chipset, if you know it (it should be possible to look that up from the PC or motherboard documentation);
- if you are emulating or virtualizing, then whether the emulated/virtualized system differs from the test host system;
- what your are using for your development host OS; and,
- what toolchain you are using, including version numbers, and if you are using a cross-compiler and cross toolchain (as opposed to one configured for the host OS).
MrLolthe1st wrote:Im booting with bootloader from FAT32 FS. loading file, jumping, entering PM, copies a kernel, jump into kernel.
From this, it seems you are rolling your own boot loader, then, and that it is a BIOS system rather than UEFI (or if it is UEFI, that you are using it in Legacy mode).
If this is the case, then the most sensible solution is to interrogate the BIOS in your second stage loader before going into protected mode, and passing the information as a header to the OS. This means using either assembler, or a real-mode C compiler such as BCC for that part of the code, but this is true of the second stage loader in general prior to the switch to protected mode.
Note that the roll-your-own approaches given on the wiki page all assume that this is what you are actually doing; there is no reliable way to get the system memory in protected mode once the system loader hands control off to your boot loader. This is because getting an accurate memory map depends on chipset-specific operations, indeed even motherboard-specific ones depending on how the memory bus controller and PCI bridges were designed. In most cases, you
can't get the information you would need to get the memory map without probing (which you really need to avoid if at all possible), because it is proprietary to the motherboard manufacturer. Even if you could get it, it wouldn't apply to any other model of motherboards - maybe not even ones in the same product line by the same manufacturer.
For a BIOS-based system (or one running in Legacy mode), you would need to try calling multiple BIOS functions to get the full map; as the wiki page explains, the only 'standard' (in the sense of, 'it existed since the original PC') BIOS call for memory detection only handles the real-mode low memory map, and the ones which can determine the rest of the memory aren't standardized.
UEFI does have a standard memory detecting function, which any UEFI motherboard is
supposed to implement; for current ones from trustworthy manufacturers, it is reasonably reliable, if a bit of a pain to work with, but some older or cheaper UEFI mobos might be a bit sketchy on this - they might only work with the Windows boot loader. This isn't all that common, but it does happen AFAICT, and I am afraid that if that's the case for your mobo, well... you'd be SOL for running live. It should still be possible to emulate a system, but you'd need to emu the BIOS as well, which makes for a slower emulation.
I wish it were better than this, but unfortunately, this is where things stand for all of us, at least on PCs (other kinds of systems, such as Raspberry Pis, have different quirks, but none of them are all the easy).