ivt | programable Scientific RPN Calculator

The problem was not with code, but with linker script. I have put my vector table at 0x10000, as you can see in the linker script, but it should be placed at 0x0. So SVC was not handled properly because the handler was placed in a wrong place.

When I changed the base address in my ld script and tried to load the firmware as ELF, everything starts to work perfectly.

Only for 80x86 systems that support BIOS and booted using BIOS.

Q2. Is IVT size always 1024 bytes? Q3. Is BDA start address always set to 0x00000400?

There isn't any "hard barrier" between these things. The IVT itself is 1 KiB, but various entries (especially near the end) are used for BIOS data, so it's more like the IVT and BDA are intertwined and overlapping.

Q4. Is BDA size always 256 bytes?

For compatibility with ancient DOS stuff the BDA "should" end before 0x00000500. There's no guarantee that the BIOS cared about compatibility with ancient DOS stuff though.

A better (more cautious/conservative) idea is to just ignore the first 4 KiB of RAM until the operating system's boot code no longer needs BIOS anymore, and then treat it like free usable RAM (unlike EBDA, there's no reason for an OS to preserve the data in the BDA).

Note: Even while boot code still needs BIOS there no reason for the boot code to read anything in the BDA itself (it only needs to avoid trashing the data so BIOS can read it). For example, rather than looking at 0x040E you can just use int 0x12 (or int 0x15, eax=0xE820). The only other things I've seen people use BDA for is to determine floppy drive types and number of serial ports (which are things from BIOS settings that are likely to be set wrong by the user, and therefore unreliable and useless).

If you only want to know which areas are usable RAM; then "int 0x15, eax=0xE820" (with the restriction that the BDA will be considered usable), or UEFI's "get memory map" function, are all you need. Note that for both cases one/some areas may be reported as "ACPI reclaimable", which means that after you've finished parsing ACPI tables (or if you don't care about ACPT tables) the RAM will become usable.

If you want more information you need to do more work, because the information is scattered everywhere. Specifically:

• ACPI's SRAT table describes which things (e.g. which areas of memory) are in which NUMA domain; and ACPI's SLIT table describes the performance implications of that.

• ACPI's SRAT table also describes which things (e.g. which areas of memory) are "hot plug removable" and reserved for "hot insert".

• the CPU's CPUID instruction will tell you "physical address size in bits". This is useful to know if/when you're trying to find a suitable area of the physical address space to use for a memory mapped PCI device's BARs, because the memory maps you get are too silly to tell you the difference between "not usable by memory mapped PCI devices", "usable by memory mapped PCI devices" and "used by memory mapped PCI devices".

• parsing (or configuring) PCI configuration space (in conjunction with IOMMUs if necessary) tells you which areas of the physical address space are currently used by which PCI devices

• parsing "System Management BIOS" tables can (with a lot of work and "heuristical fumbling") tell you which areas of the physical address space correspond to which RAM chips on the motherboard and what the details of those RAM chips are (type, speed, etc).

• various ACPI tables (e.g. MADT/APIC and HPET) can be used to determine the location of various special devices (local APICs, IO APICs, HPET).

• you can assume that (part of) the area ending at physical address 0xFFFFFFFF will be the firmware's ROM; and (with some more "heuristical fumbling" to subtract any special devices from the area reported as "reserved" by the firmware's memory map) you can determine the size of this area.

If you do all of this you'll have a reasonably complete map describing everything in the physical address space.