search

p-durlej / newsys

Vanadium OS
http://www.durlej.net/v/
110 stars 14 forks source link

Stuck at "Autoconfiguring ..." while running at bare metal from BIOS #4

Open informer2016 opened 5 years ago

informer2016 commented 5 years ago

Hi there @p-durlej ! Finally I tested your wonderful Vanadium OS as a part of coreboot+SeaBIOS image ( #2 ) :wink: to be honest my earlier Vanadium experiences happened inside a VM. So, Vanadium initially seems to boot fine but then it becomes stuck at "Autoconfiguring ..." stage - while "_" symbol is blinking under O letter (Operating System at left upper corner of screen), so at least it's breathing - but still stuck

I am using your build from http://www.durlej.net/v/ - http://www.durlej.net/v/zinit.img.gz , hopefully it matches the latest source code of your newsys repository

Please tell, how could I help to debug these issues? Maybe there's some hidden debug mode to collect some logs, or a way to skip that Autoconfiguring ... (if I don't need to install Vanadium and would like to just run it in a "live floppy" mode)

p-durlej commented 5 years ago

Hello,

the "Autoconfiguring ..." message is shown when the sysload loader is detecting filesystem type and reading configuration files from /etc. This is the autoconf() function in sysload/main.c.

As this activity involves disk accesses using BIOS calls, it may be worth checking that the processor is in the expected state at the INT 13 entry. In particular, the processor should be in real address mode (as opposed to the kernel V86-mode BIOS calls), 16-bit code and data, segment limits = 64K, interrupts enabled.

Most of the sysload code runs in 32-bit protected mode (64-bit long mode on amd64). Therefore, during boot, sysload switches multiple times back and forth between the protected and real address mode. When calling the BIOS from sysload, the processor mode switching occurs in the bioscall routine in sysload/mach-*-pc/start.S.

There is no hidden debug mode in sysload. You may want to try to reproduce this issue in a virtual machine. This aim of this approach is would be to allow to pinpoint the problem more easily by connecting a debugger to the VM (or by just looking at the contents of the CS and EIP registers at the time of the hang).

For example QEMU includes a gdb server. Also, QEMU does not need a debugger to investigate register contents. AFAIR, to see the registers, you can type "info registers" at the QEMU monitor.

This approach probably involves rebuilding your coreboot/SeaBIOS image for QEMU.

An alternative approach would be to use the CON_TRACE macro (#defined in include/sysload/console.h) to trace the program flow and see where it hangs. This approach involves rebuilding the system from source.

mikebdp2 commented 10 months ago

@p-durlej Good day! I am also interested in running Vanadium as a coreboot+SeaBIOS secondary payload on my laptop. Please let me know if you are still developing your promising OS

p-durlej commented 10 months ago

@mikebdp2 Hello! Vanadium OS is not currently under very active development. I've done some maintenance work, though - such as upgrading gcc, fixing some bugs, etc.