no console will be available to OS

[gumbosoup]

Hello,
I've searched the threads and Google and couldn't find anyone who had this same problem. However, there are a lot of threads,
so I apologize if this is an answered topic and would appreciate a link to such a thread. I've been using the boot.s
and linker.ld from the Bare Bones tutorial on the wiki. It's been working fabulously on qemu, but none of that
mattered when I attempted to boot onto my actual PC with GRUB2.

When I entered the GRUB2 command line and typed: multiboot (hd0,gpt6)<path>/myos.bin,I get the following
message: "Warning: no console will be available to OS"
I typed boot and hit enter anyway and the GRUB2 command line just stayed there with the commands I had typed
still on the screen, but nothing else happened. Just as GRUB2 had said, there was no console available.

The Multiboot specs didn't mention this warning, or else my Ctrl F didn't work.

My multiboot header is as follows:

Code: Select all

# Declare constants used for creating a multiboot header.
.set ALIGN,    1<<0             
.set MEMINFO,  1<<1  
.set FLAGS,    ALIGN | MEMINFO
.set MAGIC,    0x1BADB002       
.set CHECKSUM, -(MAGIC + FLAGS) 

#the multiboot header
.section .multiboot
.align 4
.long MAGIC
.long FLAGS
.long CHECKSUM

My linker script is this:

Code: Select all

/* The bootloader will look at this image and start execution at the symbol
   designated as the entry point. */
ENTRY(_start)

/* Tell where the various sections of the object files will be put in the final
   kernel image. */
SECTIONS
{
	/* Begin putting sections at 1 MiB, a conventional place for kernels to be
	   loaded at by the bootloader. */
	. = 1M;

	/* First put the multiboot header, as it is required to be put very early
	   early in the image or the bootloader won't recognize the file format.
	   Next we'll put the .text section. */
	.text BLOCK(4K) : ALIGN(4K)
	{
		*(.multiboot)
		*(.text)
	}

	/* Read-only data. */
	.rodata BLOCK(4K) : ALIGN(4K)
	{
		*(.rodata)
	}

	/* Read-write data (initialized) */
	.data BLOCK(4K) : ALIGN(4K)
	{
		*(.data)
	}

	/* Read-write data (uninitialized) and stack */
	.bss BLOCK(4K) : ALIGN(4K)
	{
		*(COMMON)
		*(.bss)
		*(.bootstrap_stack)
	}

	/* The compiler may produce other sections, by default it will put them in
	   a segment with the same name. Simply add stuff here as needed. */
}

I tried including the flag 1<<2 in my multiboot FLAGS, but instead of "Warning: no console will be available to OS,"
I got "error: unsupported graphical mode type -2125244841"

If anyone else had this issue I would love to know how you solved it. Again, sorry if it's something silly, like needing
to change the flags to tell GRUB2 I'm booting a binary or something like that.

[Icee]

This message appears as a combination of three factors.

1. Your system is using EFI on which GRUB cannot set text mode because the EFI_GRAPHICS_OUTPUT_PROTOCOL doesn't support that.
2. The video fields in Multiboot header can be used to select the kind of console required (either a framebuffer or a EGA text console).
3. The default console is EGA text console.

So GRUB assumes you want a text console but cannot change video mode to text through EFI interfaces, thus the warning.

[iansjack]

There are quite a few hits on Google for this error. All of them seem to relate to EFI booting. Are you using EFI or conventional BIOS?

[gumbosoup]

Ah. Yes, I believe I am using EFI.
I switched my boot mode to support Legacy and boot priority to Legacy first, but
I still recieved the Warning: no console will be available to OS.

Legacy mode did allow me to use the bootloader from the babysteps tutorial
to print "Hello World" to the screen, so I may be able to boot my OS without GRUB2.

EDIT: Well, looks like I was unable to make a bootloader that could actually load the
Bare Bones kernel. There seems to be no code actually showing that in the wiki. If it was
there I think that would complete the Bare Bones tutorial. I changed my multiboot header to one
in another thread that mentions framebuffer consoles:

Code: Select all

# Declare constants used for creating a multiboot header.
.set ALIGN,    1<<0             
.set MEMINFO,  1<<1  
.set VIDINFO,  1<<2
.set FLAGS,    ALIGN | MEMINFO | VIDINFO
.set MAGIC,    0x1BADB002       
.set CHECKSUM, -(MAGIC + FLAGS) 

#the multiboot header
.section .multiboot
.align 4
.long MAGIC
.long FLAGS
.long CHECKSUM
.long 0, 0, 0, 0, 0
.long 0 #set graphics mode
.long 1024, 768, 32 #width, height, depth

GRUB2 seems to be fine with this, but when I boot, it's just a blank black screen.
Does this mean that all of my VGA console code doesn't work and i have to print
each individual pixel of each individual character?

[Brendan]

Hi,

GRUB2 seems to be fine with this, but when I boot, it's just a blank black screen.
Does this mean that all of my VGA console code doesn't work and i have to print
each individual pixel of each individual character?

Yes; in graphics mode you're no longer in text mode, the display memory contains pixels and not characters, and you have to draw your own characters.

Note that "draw your own characters" means that (e.g.) you can support Unicode properly, and use proportional fonts, and have bold/italic/underline, and use different fonts for different things, and support different font sizes, and smooth the edges of characters (anti-aliasing, etc), and do fancy things (like characters with gradients that aren't one solid colour) or rotate characters 90 degrees or...

Basically, if the only thing you need to display is text, then graphics mode is better for text. Of course typically it's best to draw more than just text. For a simple example, you could have a progress bar in the middle of the screen that goes from "nothing" (just got control from GRUB) to "full" (GUI ready to use) as you're booting; or a set of icons representing various subsystems (disk, network, video, etc) that start out dull grey and turn white when the subsystem is initialised (and red when the subsystem failed to initialise), or perhaps just a "Your OS name" splash screen in the background, or...

Actually...

For a single-user OS, you could display the user's "desktop background" as soon as possible during boot, and then draw the OS's "boot log" as if it's in a window on top of the user's desktop background. This would give the user a nice smooth transition from "booting" to "GUI working".

In a similar way, for a multi-user OS you could display the "user login screen" (with the "user name" input box greyed out until the keyboard works) and draw the OS's "boot log" as if it's in a window on top of that. You may also be able to let the user start logging in while the OS is still booting (e.g. as soon as keyboard is working they can start typing their name, even if disk and network aren't ready yet).


Cheers,

Brendan

[gumbosoup]

Cool. Thanks.

I went ahead and made a putpixel() function just to see what would happen.

Code: Select all

uint16_t *graphics_memory = (uint16_t *)0xA0000;

void putpixel()
{
	graphics_memory[0] = 0xff;
	graphics_memory[1] = 0xff;
	graphics_memory[2] = 0xff;
}

Fortunately, my computer survived this experiment, as far as I can tell. According to the wiki,
I need to get the VBE info before I start putting pixels on the screen.

I've been looking at this "Mosquito OS" https://github.com/tristanseifert/Mosqu ... s/system.c
It looks like this guy puts a structure called sys_multiboot_info (of the type multiboot_info_t) into the ebx register. This
structure contains a uint32_t typecast of a pointer to a structure called vbe_mode_info that contains the width, height,
pitch, bpp, etc.

I noticed he did this:

Code: Select all

jmp_highhalf:
   # Now, we're executing at 0xC0100000, so use the virtual address for stack.
   mov	$stack_top, %esp
   # Push multiboot info (EBX) and magic number (EAX)
   push %ebx
   push	%eax
   # Write multiboot info pointer to memory
   mov	%ebx, sys_multiboot_info
   # Check for SSE, and if it exists, enable it
   mov	$0x1, %eax
   cpuid
   test	$(1 << 25), %edx
   jz .noSSE

From his resulting vbe_mode_info structure, he gets all the info the wiki says I need
to put a pixel at an arbitrary location on the screen without making wild assumptions.
Is this how to get the VBE info?
If I were to do it according to the wiki, would I make a structure, put it in the ebx register,
then do:

Code: Select all

   mov $0x4F00, %ax
   int $0x10

?

[Brendan]

From his resulting vbe_mode_info structure, he gets all the info the wiki says I need
to put a pixel at an arbitrary location on the screen without making wild assumptions.
Is this how to get the VBE info?
If I were to do it according to the wiki, would I make a structure, put it in the ebx register,
then do:

Code: Select all

   mov $0x4F00, %ax
   int $0x10

?

If you're using Multiboot; then the boot loader should give you a "Multiboot Information Structure" (example). This structure contains a variety of things, potentially including (if its configured right) a "vbe_mode_info" field that tells you the physical addresses of the VBE mode information returned by VBE Function 0x01. Basically, the boot loader should have already got this information from VBE for you.


Cheers,

Brendan

[gumbosoup]

I'm so frustratingly close to the info for putpixel().

When I ran my OS in qemu, my vbe info was this:

So I arranged putpixel() like so:

Code: Select all

void putpixel(uint32_t* screen,int x,int depth,int y,int pitch,uint32_t color)
{
	unsigned where = (x * depth) + (y * pitch);
	screen[where] = color & 255;
	screen[where + 1] = (color >> 8) & 255;
	screen[where + 2] = (color >> 16) & 255;
	screen[where + 3] = (color >> 24) & 255;
}

and invoked the function in this way:

Code: Select all

putpixel((uint32_t *)vbe_mode_info->physbase,0,32,0,vbe_mode_info->pitch,my_color);

and still nothing. I noticed the MosquitoOS divided the bpp by 8 tbefore using it, so i did that and got 31.
plugging in 31 and 32 for the depth in putpixel() both yielded no visible results.
qemu gave the warning: "multiboot knows vbe, we don't." So do I have to boot into textmode on my actual
hardware to get the real information or did I just write my putpixel() incorrectly?

[Brendan]

Hi,

I'm so frustratingly close to the info for putpixel().

When I ran my OS in qemu, my vbe info was this:

Were you expecting a 61440 * 65363 video mode (with 255 bits per pixel)?

Better code would've checked to see if the "signature" field is correct and then displayed an error, and avoided reporting so much misinformation to its user.


Cheers,

Brendan

[Combuster]

The "qemu -kernel" command line is a hack that boots linux and a bit more, but doesn't do the rest.

If you want to boot a kernel with VBE enabled, you need a proper disk image with grub and everything (or EFI partitions and everything), and ask qemu to boot that. QEmu can also run EFI firmware, but in practice it has shown that the difference between that and real hardware is the actual pixel formats.

Also, physbase=F000D5E2 says you're reading a NULL pointer. (that's an IVT entry)

[gumbosoup]

Well this is a fine pickle.

--My computer has UEFI, which will not allow GRUB2 to boot into text mode, so I have to use graphics mode.
--I can't get the information needed to display anything in graphical mode because I cannot boot into text mode.
--I could theoretically boot into text mode since my computer offers "Legacy Support", it's term for conventional BIOS.
--This would involve making a bootloader, but the wiki has a very nice explanation of how to make a bootloader that says "Hello World"

The tecnology has surpassed the existing information on the subject.
If there was some explanation somewhere on the internet of how to make a bootloader that would load the kernel
from the bare bones tutorial, that would be great. Until then, the best I can hope for is emulation.

[Octocontrabass]

Install GRUB2 in BIOS mode instead of UEFI mode.

[gumbosoup]

I tried sudo grub-install --root-directory=/media/YouLabel --no-floppy --recheck --force /dev/sdX
but it installed it in EFI mode. Apparently I need a bios partition on ym USB stick for GRUB
to install as BIOS compatible. Is there a simple set of commands that I can type in the
Parted utiliy to make that?

[Owen]

I'm not sure why you tried dumping the graphical mode information in text mode above. I mean, shouldn't it be obvious that if GRUB tells you it has booted you in text mode, then the graphical mode information will be invalid?

I suggest asking GRUB to always boot you in graphical mode, and to debug, dump the mode information elsewhere (e.g. serial port, Bochs port e9 hack)

[Octocontrabass]

grub-install --root-directory=/media/YouLabel --no-floppy --recheck --force /dev/sdX

You forgot "--target=i386-pc".

Apparently I need a bios partition on ym USB stick for GRUB
to install as BIOS compatible. Is there a simple set of commands that I can type in the
Parted utiliy to make that?

Your disk is probably already compatible. In the unlikely case that it isn't, you can reformat it using this command:

parted /dev/sdX mklabel msdos

(This will erase all data on the disk, so you'll have to recreate the partitions.)