Re: boot in console mode from grub2
On Wed, May 7, 2014 at 4:59 AM, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> On Ma, 06 mai 14, 17:42:12, Steve Litt wrote:
>> On Tue, 06 May 2014 12:39:03 -0500
>> Hugo Vanwoerkom <hvw59601@care2.com> wrote:
>>>
>>> from /etc/default/grub:
>>>
>>> # Uncomment to disable graphical terminal (grub-pc only)
>>> #GRUB_TERMINAL=console
>>>
>>> then run update-grub.
>>
>> That often doesn't work, and it for sure doesn't boot straight to the
>> monitor without a framebuffer.
>
> Are you sure you're not confusing framebuffer with KMS?
I suspect that he means kms.
There's the "nomodeset" kernel cmdline option to turn it off (there
are also the card-specific "i915.modeset=0", "nouveau.modeset=0"
options) but grepping "kernel-parameters" for nomodeset in the
3.15-rc4, 3.14.3, 3.12.18 source (the ones that I have on-disk)
returns nothing. Maybe it was never documented in "kernel-parameters";
or has it been removed?
Grepping through the entire source of 3.15.rc4 returns the following
linux-3.15-rc4/Documentation/EDID/HOWTO.txt:Adding the kernel
parameter "nomodeset" helps in most cases, but causes
linux-3.15-rc4/drivers/video/console/vgacon.c:__setup("nomodeset", text_mode);
linux-3.15-rc4/drivers/video/fbdev/aty/radeon_base.c:static bool nomodeset = 0;
linux-3.15-rc4/drivers/video/fbdev/aty/radeon_base.c: if (nomodeset)
linux-3.15-rc4/drivers/video/fbdev/aty/radeon_base.c: } else if
(!strncmp(this_opt, "nomodeset", 9)) {
linux-3.15-rc4/drivers/video/fbdev/aty/radeon_base.c: nomodeset = 1;
linux-3.15-rc4/drivers/video/fbdev/aty/radeon_base.c:module_param(nomodeset,
bool, 0);
linux-3.15-rc4/drivers/video/fbdev/aty/radeon_base.c:MODULE_PARM_DESC(nomodeset,
"bool: disable actual setting of video mode");
linux-3.15-rc4/drivers/gpu/drm/radeon/radeon_drv.c: /* set to
modesetting by default if not nomodeset */
linux-3.15-rc4/drivers/gpu/drm/i915/i915_dma.c: DRM_INFO("See
CONFIG_DRM_I915_KMS, nomodeset, and i915.modeset parameters\n");
so it's supported/still supported but the first hit is interesting:
cat linux-3.15-rc4/Documentation/EDID/HOWTO.txt
<begin>
In the good old days when graphics parameters were configured explicitly
in a file called xorg.conf, even broken hardware could be managed.
Today, with the advent of Kernel Mode Setting, a graphics board is
either correctly working because all components follow the standards -
or the computer is unusable, because the screen remains dark after
booting or it displays the wrong area. Cases when this happens are:
- The graphics board does not recognize the monitor.
- The graphics board is unable to detect any EDID data.
- The graphics board incorrectly forwards EDID data to the driver.
- The monitor sends no or bogus EDID data.
- A KVM sends its own EDID data instead of querying the connected monitor.
Adding the kernel parameter "nomodeset" helps in most cases, but causes
restrictions later on.
As a remedy for such situations, the kernel configuration item
CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an
individually prepared or corrected EDID data set in the /lib/firmware
directory from where it is loaded via the firmware interface. The code
(see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
commonly used screen resolutions (1024x768, 1280x1024, 1600x1200,
1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
not contain code to create these data. In order to elucidate the origin
of the built-in binary EDID blobs and to facilitate the creation of
individual data for a specific misbehaving monitor, commented sources
and a Makefile environment are given here.
To create binary EDID and C source code files from the existing data
material, simply type "make".
If you want to create your own EDID file, copy the file 1024x768.S,
replace the settings with your own data and add a new target to the
Makefile. Please note that the EDID data structure expects the timing
values in a different way as compared to the standard X11 format.
X11:
HTimings: hdisp hsyncstart hsyncend htotal
VTimings: vdisp vsyncstart vsyncend vtotal
EDID:
#define XPIX hdisp
#define XBLANK htotal-hdisp
#define XOFFSET hsyncstart-hdisp
#define XPULSE hsyncend-hsyncstart
#define YPIX vdisp
#define YBLANK vtotal-vdisp
#define YOFFSET (63+(vsyncstart-vdisp))
#define YPULSE (63+(vsyncend-vsyncstart))
The CRC value in the last line
#define CRC 0x55
also is a bit tricky. After a first version of the binary data set is
created, it must be checked with the "edid-decode" utility which will
most probably complain about a wrong CRC. Fortunately, the utility also
displays the correct CRC which must then be inserted into the source
file. After the make procedure is repeated, the EDID data set is ready
to be used.
</end>
Reply to: