Hi all,
Small update on NaoixOS, my i686 hobby kernel developed entirely on an Android phone through Termux (no PC involved at any point in the toolchain — Clang/LLD targeting i686-elf, cross-built and tested on-device via QEMU).
This release adds basic hardware self-awareness: NaoixOS can now report what CPU it's running on and how much usable RAM it has, instead of running blind.
**CPU identification (`arch/cpuid.c`)**
Two small wrappers around the `CPUID` instruction:
- `cpuid_get_vendor()` — leaf `0`, reads the 12-byte vendor string out of `EBX:EDX:ECX` (in that order, not alphabetical — always trips people up the first time).
- `cpuid_get_brand()` — leaves `0x80000002`-`0x80000004`, pulls the full 48-byte brand string ("AMD EPYC Processor", "Intel(R) Core(TM)...", etc). Falls back to the vendor string on older CPUs that don't expose the extended brand leaves.
**RAM detection, two paths depending on how NaoixOS was booted**
- Multiboot1 path (`qemu -kernel` / GRUB): reads `mem_lower` + `mem_upper` straight out of the multiboot info struct.
- Legacy BIOS path (custom bootloader, `boot/stage1.S`): walks the `INT 0x15, EAX=0xE820` memory map in real mode before switching to protected mode, and leaves the raw entry list at a fixed physical address (`0x1000`, safely below the boot sector and the kernel load address) for the 32-bit kernel to read later. `nfetch` sums every region marked `E820_TYPE_USABLE` and shifts to MB.
A `g_boot_magic` / `g_boot_info_addr` pair, set once at the top of `kmain()`, lets any shell command know which boot path was taken without re-deriving it — used to decide which of the two RAM-detection paths is valid.
**Result, tested on Limbo + SeaBIOS:**
```
naoixos > nfetch
===== nfetch =====
OS : NaoixOS v0.6.9-rc
Shell : NaoixSH v0.3.4
Arch : i686 (x86, protected mode)
CPU : AMD EPYC Processor
RAM : 7 MB
```
The RAM figure is real, not a placeholder — 8 MB configured on the test setup, 7 MB reported usable, with the difference being the low-memory region the BIOS reserves for itself. Multiple test runs confirmed the number is consistent, not noise.
Both detection paths intentionally avoid 64-bit arithmetic (32-bit-only summation, power-of-two shifts instead of division) to avoid pulling in libgcc helpers — fine for anything at hobby scale, would need revisiting long before getting anywhere near 4 GB.
Repo, as always, is 100% built and tested from a phone: https://github.com/jackidevz/NaoixOS
Screenshots: