0

Given some x86_64 linux stock kernel running one single GPU embedded into whatever pci-e extension board.


cat-ing /proc/iomem, I can realize that some space is reserved in RAM and associated to the Video ROM.

  1. Can I rightly assume that this is nothing but an exact copy of the BIOS (or equivalent) code for dealing with whatever legacy VGA device plugged into the ISA bus or whatever PCI device capable of decoding legacy VGA IO and/or MEM ?
  2. Why is this code copied into RAM ?
    In order to allow faster access times?
    In order to keep it runable after kernel will have switched into protected mode?
  3. Can I righly assume that this code will only be used as long as whatever in-kernel dedicated framebuffer driver (fbcon, vgafb, vesafb…) does not take precedence ?
  4. In case whatever framebuffer driver is made available, can this code be of later use in the lifetime of the running kernel ?
    If not then why the linux kernel does not, at boot time, simply get rid of that region when freeing unused memory ?

1 Answer 1

1
  1. Not quite. iomem entries describe physical address uses; system RAM is marked as such, anything else describes ranges of addresses which aren’t used for RAM. The “Video ROM” entry points to the actual ROM (well, flash in practice). On x86 it is mapped on systems using a BIOS or CSM; systems booted through UEFI might not have it.

    You’ll see that on x86 it’s always mapped at 0xC0000:

    $ sudo cat /proc/iomem|grep "Video ROM"
    000c0000-000cfdff : Video ROM
    

    That’s where the video BIOS has always been mapped, and various (old) pieces of software need it to be there.

  2. It is typically not copied into RAM. (It used to be, into “shadow RAM”, but that’s not done any more.)

  3. On current systems, the code isn’t used (it used to be, in a limited number of scenarios, but as far as I’m aware it isn’t any more, except by vesafb on 32-bit x86).

  4. The kernel doesn’t need to get rid of it, it doesn’t take away any memory and it lives in a range of addresses which is ignored in any case (the lower part of the physical address space is effectively unused on x86).

10
  • Thanks Stephen. Your answer leading to some additional question : What code is responsible for display management before whatever framebuffer driver can take this in charge ?
    – MC68020
    Commented Nov 15, 2022 at 15:02
  • In other words, what is the magic allowing the display of early printks ?
    – MC68020
    Commented Nov 15, 2022 at 15:09
  • And in case they would only be buffered until some fb-driver being made available, how can some stack dump be displayed in case of early boot segfault ?
    – MC68020
    Commented Nov 15, 2022 at 15:14
  • Do you mean vgacon? That takes care of the console if fbcon or something better isn’t available. It doesn’t use the video ROM, it drives the VGA hardware directly. Commented Nov 15, 2022 at 15:33
  • 1
    My main point is that even for early printks, even on x86 PCs booting using BIOS, the video ROM isn’t needed, and the code it contains doesn’t run after boot. Commented Nov 15, 2022 at 17:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .