[LinuxBIOS] RESEND: patch: fix the problem with CONFIG_CONSOLE_VGA not pulling in the emulator
This is a resend from yesterday, I am hoping for an ack :-)
ron
On Thursday 03 January 2008, ron minnich wrote:
This is a resend from yesterday, I am hoping for an ack :-)
Not yet. This fixes the problem Luc found along the way, and which nobody has cared about for a while.
How do we want to express now that the console is on a VGA-compatible device without the necessity for any emulator (e.g. onboard SiS300, unichrome, i810 or maybe RS480)?
Torsten
On Jan 3, 2008 3:15 PM, Torsten Duwe duwe@lst.de wrote:
On Thursday 03 January 2008, ron minnich wrote:
This is a resend from yesterday, I am hoping for an ack :-)
Not yet. This fixes the problem Luc found along the way, and which nobody has cared about for a while.
How do we want to express now that the console is on a VGA-compatible device without the necessity for any emulator (e.g. onboard SiS300, unichrome, i810 or maybe RS480)?
well, will those on-board devices have an option ROM associated with them? If not, there is no issue; the option ROM won't be run. Luc has already set up his native code to set the vga_inited variable.
There's a harder problem. What if we're on a a system with a unichrome and, for whatever reason, somebody drops in a different graphics card and wants that to be the console? Of the set of devices that *could* be the console, which one *should* be the console?
For this latter case, in which there is a native non-option-ROM VGA device and a VGA device with an option ROM, you are going to need to leave the emulator in, I am afraid. I'm happy to be shown wrong, because I don't much like this situation.
We never had a good solution to the latter problem. Standard bios rules are to use the one in the slot, ignoring the on-board device.
Maybe this issue will never come up with a unichrome, but we need to solve it for other systems with native devices and pci-e slots that can take non-native cards with option roms.
ron
On Friday 04 January 2008, ron minnich wrote:
There's a harder problem. What if we're on a a system with a unichrome and, for whatever reason, somebody drops in a different graphics card and wants that to be the console? Of the set of devices that *could* be the console, which one *should* be the console?
For this latter case, in which there is a native non-option-ROM VGA device and a VGA device with an option ROM, you are going to need to leave the emulator in [...]
True. Even those Epia-boards have a slot. Luc, or anyone else, have a board with VGA and totally without PCI, AGP or the like? Or is this a ROM space issue?
My main concern is that console on VGA and ROM emulators are orthogonal, and one should not pull in the other, for design reasons. But if there is no hardware, I'll be quiet.
Torsten
On Jan 3, 2008 3:49 PM, Torsten Duwe duwe@lst.de wrote:
My main concern is that console on VGA and ROM emulators are orthogonal, and one should not pull in the other, for design reasons. But if there is no hardware, I'll be quiet.
I don't understand the comment. Console on VGA may in some cases depend on the ROM emulator. So they are not necessarily orthogonal I think.
ron
On Friday 04 January 2008, ron minnich wrote:
On Jan 3, 2008 3:49 PM, Torsten Duwe duwe@lst.de wrote:
My main concern is that console on VGA and ROM emulators are orthogonal, and one should not pull in the other, for design reasons. But if there is no hardware, I'll be quiet.
I don't understand the comment. Console on VGA may in some cases depend on the ROM emulator. So they are not necessarily orthogonal I think.
For the board config, I meant.
Some boards will have both ROM emu and VGA, some neither, some one of them but not the other. The big question is: do all 4 cases really exist out there? So far we're missing the case with open source onboard VGA, and not a single slot were an x86 ROM could appear. If not all 4 cases exist, orthogonality is academic.
Torsten
Torsten Duwe wrote:
On Friday 04 January 2008, ron minnich wrote:
There's a harder problem. What if we're on a a system with a unichrome and, for whatever reason, somebody drops in a different graphics card and wants that to be the console? Of the set of devices that *could* be the console, which one *should* be the console?
For this latter case, in which there is a native non-option-ROM VGA device and a VGA device with an option ROM, you are going to need to leave the emulator in [...]
True. Even those Epia-boards have a slot. Luc, or anyone else, have a board with VGA and totally without PCI, AGP or the like? Or is this a ROM space issue?
This is, I believe, a moot point. Saying that all boards have a PCI slot doesn't mean that a user/developer wants to or has any intention of using it. Think of situations where an embedded board is dropped into a specialized case and sold as a project, for instance, the msntv2. The board inside (rca rm4100) does have a PCI "slot", but no header, and the case is designed such that pci cards are not meant to be used. In such a case, there's no reason to include the rom emulator, increasing the size (if ever so slightly), nor a reason to search for a video option rom, increasing the boot time, if there is no rom to run.
BTW, thanks for getting back to this Luc, I know you're busy with the new job. I apologize for the rather scalding response your patch has had, these are the types of responses to patches this community does not need, because we will scare away very experienced and good developers.
I think that we need a 3rd option, something like CONFIG_NATIVE_VGA_INIT, to do what you want and skip the video option rom search. I think that would make everyone happy ;)
-Corey
On Jan 3, 2008 9:31 PM, Corey Osgood corey.osgood@gmail.com wrote:
This is, I believe, a moot point. Saying that all boards have a PCI slot doesn't mean that a user/developer wants to or has any intention of using it. Think of situations where an embedded board is dropped into a specialized case and sold as a project, for instance, the msntv2. The board inside (rca rm4100) does have a PCI "slot", but no header, and the case is designed such that pci cards are not meant to be used. In such a case, there's no reason to include the rom emulator, increasing the size (if ever so slightly), nor a reason to search for a video option rom, increasing the boot time, if there is no rom to run.
Very true. But it's also not saying they do NOT want to be able to do it. That's what makes this so messy. But that's what the targets config file is for -- so you can reset an option that doesn't fit a particular case. It's why those files were set up that way in the first place.
I apologize for the rather scalding response your patch has had, these are the types of responses to patches this community does not need, because we will scare away very experienced and good developers.
I'm sorry if it sounded that way, but the problem was and remains that Luc's patch removes a capability that people asked us for. It really is not unusual (it just happened to me recently) for someone to come to me with a 5 year old motherboard and need a new build. When we remove options we need to be aware of the ramifications.
I think that we need a 3rd option, something like CONFIG_NATIVE_VGA_INIT, to do what you want and skip the video option rom search. I think that would make everyone happy ;)
Well, we have several cases in fact.
- native vga init, - option roms for vga - option roms for everything not vga
So we need something that supports these combinations, as users come up with new ways of combining them.
thanks
ron
Here's the full story, which I'm hoping to address all related problems with. We agreed that a VGA console and the need to run any option ROMs is mutually not strictly dependent, Luc's problem was that LBv2 code doesn't reflect that. There are 6 combinations:
* Console may be on VGA or not (e.g. serial)
_independently_
* LB might run - no option ROMs - only VGA option ROMs - all option ROMs
The combination "no option ROMs" / "VGA console" currently does not compile; Ron fixed that.
I would now additionally introduce CONFIG_VGA_ROM_RUN, to map all 6 combinations. The implicit (broken) assumption that CONSOLE_VGA would also run the ROMs is lifted, and transferred to this new config option instead; the source code becomes less ambiguous.
This change is minimally intrusive, because all board configs that previously assumed CONSOLE_VGA would also run the ROMs didn't compile, they had to also specify PCI_ROM_RUN, so this new option only offers 2 new opportunities which didn't work before or were impossible to specify, respectively.
This part combines Luc's and Ron's patches, and adds the new option to clarify.
Signed-off-by: Torsten Duwe duwe@lst.de
Walking through the code to distinguish between VGA_ROM_RUN and CONSOLE_VGA, I've seen assumptions about the memory layout and PCI_ROM_RUN, which I considered errors; CONSOLE_VGA || PCI_ROM_RUN was probably cut and pasted? I removed the PCI_ROM_RUN, please check.
Signed-off-by: Torsten Duwe duwe@lst.de
diff -BNurbp LinuxBIOSv2.orig/src/config/linuxbios_ram.ld LinuxBIOSv2/src/config/linuxbios_ram.ld --- LinuxBIOSv2.orig/src/config/linuxbios_ram.ld 2007-07-25 18:26:10.000000000 +0200 +++ LinuxBIOSv2/src/config/linuxbios_ram.ld 2008-01-05 17:14:27.000000000 +0100 @@ -92,8 +92,8 @@ SECTIONS _stack = .; .stack . : { /* Reserve a stack for each possible cpu */ - /* the stack for ap will be put after pgtbl in 1M to CONFIG_LB_MEM_TOPK range when VGA and ROM_RUN and CONFIG_LB_MEM_TOPK>1024*/ - . = ((CONFIG_CONSOLE_VGA || CONFIG_PCI_ROM_RUN)&&(_RAMBASE<0x100000)&&(CONFIG_LB_MEM_TOPK>(0x100000>>10)) ) ? STACK_SIZE : (CONFIG_MAX_CPUS*STACK_SIZE); + /* the stack for ap will be put after pgtbl in 1M to CONFIG_LB_MEM_TOPK range when VGA mem is used and CONFIG_LB_MEM_TOPK>1024*/ + . = (CONFIG_CONSOLE_VGA &&(_RAMBASE<0x100000)&&(CONFIG_LB_MEM_TOPK>(0x100000>>10)) ) ? STACK_SIZE : (CONFIG_MAX_CPUS*STACK_SIZE); } _estack = .; _heap = .; @@ -111,7 +111,7 @@ SECTIONS
_bogus = ASSERT( ( (_eram_seg>>10) < (CONFIG_LB_MEM_TOPK)) , "please increase CONFIG_LB_MEM_TOPK");
- _bogus = ASSERT( !((CONFIG_CONSOLE_VGA || CONFIG_PCI_ROM_RUN) && ((_ram_seg<0xa0000) && (_eram_seg>0xa0000))) , "please increase CONFIG_LB_MEM_TOPK and if still fail, try to set _RAMBASE more than 1M"); + _bogus = ASSERT( !(CONFIG_CONSOLE_VGA && ((_ram_seg<0xa0000) && (_eram_seg>0xa0000))) , "please increase CONFIG_LB_MEM_TOPK and if still fail, try to set _RAMBASE more than 1M");
/DISCARD/ : { *(.comment) diff -BNurbp LinuxBIOSv2.orig/src/cpu/x86/lapic/lapic_cpu_init.c LinuxBIOSv2/src/cpu/x86/lapic/lapic_cpu_init.c --- LinuxBIOSv2.orig/src/cpu/x86/lapic/lapic_cpu_init.c 2007-07-25 18:25:59.000000000 +0200 +++ LinuxBIOSv2/src/cpu/x86/lapic/lapic_cpu_init.c 2008-01-05 17:11:43.000000000 +0100 @@ -226,7 +226,7 @@ int start_cpu(device_t cpu) index = ++last_cpu_index; /* Find end of the new processors stack */ -#if (CONFIG_LB_MEM_TOPK>1024) && (_RAMBASE < 0x100000) && ((CONFIG_CONSOLE_VGA==1) || (CONFIG_PCI_ROM_RUN == 1)) +#if (CONFIG_LB_MEM_TOPK>1024) && (_RAMBASE < 0x100000) && (CONFIG_CONSOLE_VGA==1) if(index<1) { // only keep bsp on low stack_end = ((unsigned long)_estack) - (STACK_SIZE*index) - sizeof(struct cpu_info); } else { diff -BNurbp LinuxBIOSv2.orig/src/cpu/x86/pae/pgtbl.c LinuxBIOSv2/src/cpu/x86/pae/pgtbl.c --- LinuxBIOSv2.orig/src/cpu/x86/pae/pgtbl.c 2007-07-25 18:25:59.000000000 +0200 +++ LinuxBIOSv2/src/cpu/x86/pae/pgtbl.c 2008-01-05 17:11:20.000000000 +0100 @@ -54,7 +54,7 @@ void *map_2M_page(unsigned long page) struct pde pdp[512]; } __attribute__ ((packed));
-#if (CONFIG_LB_MEM_TOPK>1024) && (_RAMBASE<0x100000) && ((CONFIG_CONSOLE_VGA==1) || (CONFIG_PCI_ROM_RUN == 1)) +#if (CONFIG_LB_MEM_TOPK>1024) && (_RAMBASE<0x100000) && (CONFIG_CONSOLE_VGA==1) /* pgtbl is too big, so use last one 1M before CONFIG_LB_MEM_TOP, otherwise for 8 way dual core with vga support will push stack and heap cross 0xa0000, and that region need to be used as vga font buffer. Please make sure set CONFIG_LB_MEM_TOPK=2048 in MB Config diff -BNurbp LinuxBIOSv2.orig/src/stream/rom_stream.c LinuxBIOSv2/src/stream/rom_stream.c --- LinuxBIOSv2.orig/src/stream/rom_stream.c 2007-07-25 18:26:00.000000000 +0200 +++ LinuxBIOSv2/src/stream/rom_stream.c 2008-01-05 17:06:01.000000000 +0100 @@ -79,7 +79,7 @@ int stream_init(void)
#if _RAMBASE<0x00100000 olen = *(unsigned int *)dest; -#if (CONFIG_CONSOLE_VGA==1) || (CONFIG_PCI_ROM_RUN == 1) +#if CONFIG_CONSOLE_VGA==1 if((dest < 0xa0000) && ((dest+olen)>0xa0000)) { dest = (CONFIG_LB_MEM_TOPK<<10); }
Mailers...
On 05.01.2008 17:42, Torsten Duwe wrote:
Here's the full story, which I'm hoping to address all related problems with. We agreed that a VGA console and the need to run any option ROMs is mutually not strictly dependent, Luc's problem was that LBv2 code doesn't reflect that. There are 6 combinations:
- Console may be on VGA or not (e.g. serial)
_independently_
- LB might run
- no option ROMs
- only VGA option ROMs
- all option ROMs
I'm missing the "all option ROMs except VGA" choice for machines with a native video driver/init and some plugged-in SCSI cards.
The combination "no option ROMs" / "VGA console" currently does not compile; Ron fixed that.
I would now additionally introduce CONFIG_VGA_ROM_RUN, to map all 6 combinations. The implicit (broken) assumption that CONSOLE_VGA would also run the ROMs is lifted, and transferred to this new config option instead; the source code becomes less ambiguous.
Agreed. How about an additional CONFIG_NONVGA_ROM_RUN?
This change is minimally intrusive, because all board configs that previously assumed CONSOLE_VGA would also run the ROMs didn't compile, they had to also specify PCI_ROM_RUN, so this new option only offers 2 new opportunities which didn't work before or were impossible to specify, respectively.
This part combines Luc's and Ron's patches, and adds the new option to clarify.
Signed-off-by: Torsten Duwe duwe@lst.de
This is a good start. I assume you have tested it with abuild. Please try to get another ack from Ron or Luc as well.
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Regards, Carl-Daniel
On Sat, Jan 05, 2008 at 10:32:15PM +0100, Carl-Daniel Hailfinger wrote:
I'm missing the "all option ROMs except VGA" choice for machines with a native video driver/init and some plugged-in SCSI cards.
With native init, with the native device becoming VGA Primary, the vga rom doesn't get run, unless the native driver itself call the relevant functions, and specifies CONFIG_PCI_ROM_RUN in its Config.lb.
Maybe, in V3, a way to specify which roms to run, partly during buildtime, partly through rtc cmos, could be looked into.
Agreed. How about an additional CONFIG_NONVGA_ROM_RUN?
This is a good start. I assume you have tested it with abuild. Please try to get another ack from Ron or Luc as well.
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
It looks very good from an initial glance, but i will take a more in depth look first before ack :)
Luc Verhaegen. SUSE/Novell X Driver Developer.
On Jan 5, 2008 1:59 PM, Luc Verhaegen libv@skynet.be wrote:
Maybe, in V3, a way to specify which roms to run, partly during buildtime, partly through rtc cmos, could be looked into.
Yes, a move to cmos control is an excellent idea.
It looks very good from an initial glance, but i will take a more in depth look first before ack :)
Thanks
ron
On Sat, Jan 05, 2008 at 10:59:14PM +0100, Luc Verhaegen wrote:
Agreed. How about an additional CONFIG_NONVGA_ROM_RUN?
This is a good start. I assume you have tested it with abuild. Please try to get another ack from Ron or Luc as well.
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
It looks very good from an initial glance, but i will take a more in depth look first before ack :)
Acked-by: Luc Verhaegen libv@skynet.be
On Saturday 05 January 2008, Luc Verhaegen wrote:
On Sat, Jan 05, 2008 at 10:59:14PM +0100, Luc Verhaegen wrote:
Agreed. How about an additional CONFIG_NONVGA_ROM_RUN?
This is a good start. I assume you have tested it with abuild. Please
Since I don't touch any board specifics, I checked 3 of the 4 old config combinations on my working target to make sure it does not break anything. But abuild didn't show anything either now.
try to get another ack from Ron or Luc as well.
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
It looks very good from an initial glance, but i will take a more in depth look first before ack :)
Acked-by: Luc Verhaegen libv@skynet.be
Thanks, revision 3034.
*Please* also look at part 2 of the patch I followed up with. These are ambiguous parts of the code I spotted, and am unsure what is meant there.
I assume it's about VGA resource allocation, namely 0xA0000 to 0xBFFFF memory getting into the way of AP stacks, which would clearly depend on CONSOLE_VGA, and no ROM_RUNs
-
Carl-Daniel Hailfinger -
Corey Osgood -
Luc Verhaegen -
ron minnich -
Torsten Duwe