After fixing problems leading to compiler warnings---legitimate
warnings, but even the too short binary negated unsigned 32bits values
promoted to 64 bits with leading bits hence 0 as mask were harmless---
now I want to look at the stumbing block.
For me, under vmx, this is the assert in map.c:17:
assert(pa < KSEG2);
that triggers, and it should come from a call from multiboot.
My first reflex is to start adding printf() instructions to track the
problem, but is there a better way when dealing with the kernel?
Second question: since, if I'm not mistaken, 9front doesn't use
multiboot, is vmx usable (i.e. agnostic about) with the multiboot stuff?
The embedded boot stuff should handle the thing by itself without load
addresses having to be adjusted because of vmx?
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T8b5b89fcf829819e-M1aa8501df3408a8c92dd8170
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
