On Mon, Oct 05, 2015 at 05:04:09PM +0100, edward wandasiewicz wrote:
Following on from this post - http://seabios.seabios.narkive.com/UAt3jVij
I was having the exactly the same problem.
So to summarize, you can boot Linux on Samus, but can not boot any *BSD? Both Linux and the BSDs do work on Link?
[...]
If I run "vbeinfo" within Grub2 on the Pixel 2013, we get a long list, including 640 x 400 and 800 x 600
On the Pixel 2015, "vbeinfo" only gives one entry, and one entry only of 1280 x 850 x 16
Could this explain why *BSD operating systems and MemTest utility cannot boot from USB or SD card (..properly..) ? They boot up in a "text console", versus a "graphical console in text mode".
It's certainly possible that cbvga SeaVGABIOS is the cause. The cbvga support in SeaVGABIOS is a hack to get some minimal display support when only a graphical framebuffer is available. It is known to not work with some bootloaders and OSes (that don't use the VGA BIOS to write to the screen). For that reason, it's not going to work with MemTest86+.
Looks like you have a rom from John Lewis. I'd confirm that the SeaVGABIOS in the rom is relatively recent as there were some changes ("leal" emulation) that are known to work better on the *BSDs.
If SeaVGABIOS is recent, then I think the next step would be to see if you can replace SeaVGABIOS with an Intel VGABIOS.
-Kevin
P.S. it should be possible to implement a SeaVGABIOS with support for mode switching on Intel graphics adapters. That should solve these problems (at least on Intel hardware), but it's a bit of work as I find the Intel graphics manuals to be basically indecipherable. :-(
On 2015-10-06 02:02, Kevin O'Connor wrote:
On Mon, Oct 05, 2015 at 05:04:09PM +0100, edward wandasiewicz wrote:
Following on from this post - http://seabios.seabios.narkive.com/UAt3jVij
I was having the exactly the same problem.
So to summarize, you can boot Linux on Samus, but can not boot any *BSD? Both Linux and the BSDs do work on Link?
[...]
If I run "vbeinfo" within Grub2 on the Pixel 2013, we get a long list, including 640 x 400 and 800 x 600
On the Pixel 2015, "vbeinfo" only gives one entry, and one entry only of 1280 x 850 x 16
Could this explain why *BSD operating systems and MemTest utility cannot boot from USB or SD card (..properly..) ? They boot up in a "text console", versus a "graphical console in text mode".
It's certainly possible that cbvga SeaVGABIOS is the cause. The cbvga support in SeaVGABIOS is a hack to get some minimal display support when only a graphical framebuffer is available. It is known to not work with some bootloaders and OSes (that don't use the VGA BIOS to write to the screen). For that reason, it's not going to work with MemTest86+.
Looks like you have a rom from John Lewis. I'd confirm that the SeaVGABIOS in the rom is relatively recent as there were some changes ("leal" emulation) that are known to work better on the *BSDs.
If SeaVGABIOS is recent, then I think the next step would be to see if you can replace SeaVGABIOS with an Intel VGABIOS.
I'm not absolutely sure how old it is, but I don't think it's any older than 2 or 3 weeks, since that was the last time I really had a bash at getting this working properly, and I finished up by putting the cbvga option ROM in. I guess what this points to is that I should get the script, run by Jenkins, to update the cbvga option ROM every time, if I'm going to continue running that way.
If I disable coreboot framebuffer support in SeaBIOS and then use the VGABIOS from the stock ROM in RW_LEGACY, I don't get any display from SeaBIOS on Broadwell.
If I do the same with a Haswell Chromebook, the display works.
In the former case, SeaBIOS appears to find and load the VGABIOS, according to cbmem, just no display.
I think whatever this problem is may also explain why I'm not able to get display using a modified BOOT_STUB with SeaBIOS on Broadwell.
Another thing that may or may not have some bearing is that on Baytrail, if I try to use RW_LEGACY with SeaBIOS, SeaBIOS initialises the display, but Linux won't display anything unless I disable KMS with "nomodeset" on the kernel cmdline. That unfortunately leaves me with a display resolution of 1024x768 (presumably what coreboot sets the framebuffer to).
If you have some stuff I can try to get a VGABIOS working properly with BOOT_STUB and RW_LEGACY on Broadwell and Baytrail Chromebooks, I would sure appreciate it, Kevin.
-John.
-Kevin
P.S. it should be possible to implement a SeaVGABIOS with support for mode switching on Intel graphics adapters. That should solve these problems (at least on Intel hardware), but it's a bit of work as I find the Intel graphics manuals to be basically indecipherable. :-(
On Tue, Oct 6, 2015 at 12:53 PM, John Lewis jlewis@johnlewis.ie wrote:
I'm not absolutely sure how old it is, but I don't think it's any older than 2 or 3 weeks, since that was the last time I really had a bash at getting this working properly, and I finished up by putting the cbvga option ROM in. I guess what this points to is that I should get the script, run by Jenkins, to update the cbvga option ROM every time, if I'm going to continue running that way.
It was version legacy-230915.
I just updated via https://johnlewis.ie/flash_chromebook_rom.sh and version is now legacy-021015.
Tried booting the *BSD and Memtest86 with legacy-021015, still get the same behaviour. No boot.
I've included a cbmem -c for this ROM at
If I disable coreboot framebuffer support in SeaBIOS and then use the VGABIOS from the stock ROM in RW_LEGACY, I don't get any display from SeaBIOS on Broadwell.
If I do the same with a Haswell Chromebook, the display works.
In the former case, SeaBIOS appears to find and load the VGABIOS, according to cbmem, just no display.
I think whatever this problem is may also explain why I'm not able to get display using a modified BOOT_STUB with SeaBIOS on Broadwell.
Another thing that may or may not have some bearing is that on Baytrail, if I try to use RW_LEGACY with SeaBIOS, SeaBIOS initialises the display, but Linux won't display anything unless I disable KMS with "nomodeset" on the kernel cmdline. That unfortunately leaves me with a display resolution of 1024x768 (presumably what coreboot sets the framebuffer to).
If you have some stuff I can try to get a VGABIOS working properly with BOOT_STUB and RW_LEGACY on Broadwell and Baytrail Chromebooks, I would sure appreciate it, Kevin.
-John.
On Tue, Oct 06, 2015 at 12:53:44PM +0100, John Lewis wrote:
Looks like you have a rom from John Lewis. I'd confirm that the SeaVGABIOS in the rom is relatively recent as there were some changes ("leal" emulation) that are known to work better on the *BSDs.
If SeaVGABIOS is recent, then I think the next step would be to see if you can replace SeaVGABIOS with an Intel VGABIOS.
I'm not absolutely sure how old it is, but I don't think it's any older than 2 or 3 weeks, since that was the last time I really had a bash at getting this working properly, and I finished up by putting the cbvga option ROM in. I guess what this points to is that I should get the script, run by Jenkins, to update the cbvga option ROM every time, if I'm going to continue running that way.
The "leal" stuff went in around June, so it's probably recent enough then.
If I disable coreboot framebuffer support in SeaBIOS and then use the VGABIOS from the stock ROM in RW_LEGACY, I don't get any display from SeaBIOS on Broadwell.
If I do the same with a Haswell Chromebook, the display works.
In the former case, SeaBIOS appears to find and load the VGABIOS, according to cbmem, just no display.
I think whatever this problem is may also explain why I'm not able to get display using a modified BOOT_STUB with SeaBIOS on Broadwell.
IIUC, the intel vgabios fails to work properly on some gpus if it is run after the hardware has already been initialized. If that's the case you'd need to be careful to only init the display once (either native coreboot vga + SeaVGABIOS cbvga, or no video in coreboot + SeaBIOS run intel vgabios).
Another thing that may or may not have some bearing is that on Baytrail, if I try to use RW_LEGACY with SeaBIOS, SeaBIOS initialises the display, but Linux won't display anything unless I disable KMS with "nomodeset" on the kernel cmdline. That unfortunately leaves me with a display resolution of 1024x768 (presumably what coreboot sets the framebuffer to).
When you say "SeaBIOS initialises the display" do you mean cbvga SeaVGABIOS? If so, that does not initialize the hardware - it just draws on the framebuffer that coreboot sets up. I'm not sure why Linux wouldn't be able to use a display that coreboot setup. Maybe there is some setting that will convince it to use it.
If you have some stuff I can try to get a VGABIOS working properly with BOOT_STUB and RW_LEGACY on Broadwell and Baytrail Chromebooks, I would sure appreciate it, Kevin.
[...]
P.S. it should be possible to implement a SeaVGABIOS with support for mode switching on Intel graphics adapters. That should solve these problems (at least on Intel hardware), but it's a bit of work as I find the Intel graphics manuals to be basically indecipherable. :-(
I don't have anything. A few months ago I looked through the Intel gpu docs. As near as I can tell, the Intel hardware is compatible with all the legacy VGA interfaces. It seemed like the only thing that would need to be done to switch into true legacy modes would be to enable the "legacy vga mode" and to program something called a "panel fitter". The docs were not much help though.
-Kevin
If I disable coreboot framebuffer support in SeaBIOS and then use the VGABIOS from the stock ROM in RW_LEGACY, I don't get any display from SeaBIOS on Broadwell.
If I do the same with a Haswell Chromebook, the display works.
In the former case, SeaBIOS appears to find and load the VGABIOS, according to cbmem, just no display.
I think whatever this problem is may also explain why I'm not able to get display using a modified BOOT_STUB with SeaBIOS on Broadwell.
IIUC, the intel vgabios fails to work properly on some gpus if it is run after the hardware has already been initialized. If that's the case you'd need to be careful to only init the display once (either native coreboot vga + SeaVGABIOS cbvga, or no video in coreboot + SeaBIOS run intel vgabios).
Yes, which is why I removed the intel vgabios from the coreboot part of the ROM, to make sure coreboot wasn't able to initialise it to begin with. The backlight comes on, but I don't get any display until the kernel loads.
Another thing that may or may not have some bearing is that on Baytrail, if I try to use RW_LEGACY with SeaBIOS, SeaBIOS initialises the display, but Linux won't display anything unless I disable KMS with "nomodeset" on the kernel cmdline. That unfortunately leaves me with a display resolution of 1024x768 (presumably what coreboot sets the framebuffer to).
When you say "SeaBIOS initialises the display" do you mean cbvga SeaVGABIOS? If so, that does not initialize the hardware - it just draws on the framebuffer that coreboot sets up. I'm not sure why Linux wouldn't be able to use a display that coreboot setup. Maybe there is some setting that will convince it to use it.
When I say initialise in that case, I mean "give some display". ;)
Yes, well, as I said, it will bring up a display if I use "nomodeset" but it's only 1024x768 (not 1366x768), and it won't allow me to change the resolution in Gnome.
If you have some stuff I can try to get a VGABIOS working properly with BOOT_STUB and RW_LEGACY on Broadwell and Baytrail Chromebooks, I would sure appreciate it, Kevin.
[...]
P.S. it should be possible to implement a SeaVGABIOS with support for mode switching on Intel graphics adapters. That should solve these problems (at least on Intel hardware), but it's a bit of work as I find the Intel graphics manuals to be basically indecipherable. :-(
I don't have anything. A few months ago I looked through the Intel gpu docs. As near as I can tell, the Intel hardware is compatible with all the legacy VGA interfaces. It seemed like the only thing that would need to be done to switch into true legacy modes would be to enable the "legacy vga mode" and to program something called a "panel fitter". The docs were not much help though.
Well, Matt DeVillier has some experience tweaking the Intel vgabios to do things like output to the HDMI port first, maybe there're some things I can experiment with in that area. I'll have a look anyway.
-John.
On Tue, Oct 06, 2015 at 04:10:05PM +0100, John Lewis wrote:
If I disable coreboot framebuffer support in SeaBIOS and then use the VGABIOS from the stock ROM in RW_LEGACY, I don't get any display from SeaBIOS on Broadwell.
If I do the same with a Haswell Chromebook, the display works.
In the former case, SeaBIOS appears to find and load the VGABIOS, according to cbmem, just no display.
I think whatever this problem is may also explain why I'm not able to get display using a modified BOOT_STUB with SeaBIOS on Broadwell.
IIUC, the intel vgabios fails to work properly on some gpus if it is run after the hardware has already been initialized. If that's the case you'd need to be careful to only init the display once (either native coreboot vga + SeaVGABIOS cbvga, or no video in coreboot + SeaBIOS run intel vgabios).
Yes, which is why I removed the intel vgabios from the coreboot part of the ROM, to make sure coreboot wasn't able to initialise it to begin with. The backlight comes on, but I don't get any display until the kernel loads.
So, even if coreboot doesn't initialize the display (no native init and no intel vgabios) and SeaBIOS does run the intel vgabios you still don't get a screen? That's unfortunate.
-Kevin
On Tue, Oct 6, 2015 at 2:02 AM, Kevin O'Connor kevin@koconnor.net wrote:
On Mon, Oct 05, 2015 at 05:04:09PM +0100, edward wandasiewicz wrote:
Following on from this post - http://seabios.seabios.narkive.com/UAt3jVij
I was having the exactly the same problem.
So to summarize, you can boot Linux on Samus, but can not boot any *BSD? Both Linux and the BSDs do work on Link?
Correct.
Link - Arch Linux, *BSD and Memtest86+ from the Arch Linux install ISO all boot fine
Samus - Arch Linux boots, *BSD and Memtest86+ fail to boot, all current snapshots as of October 2015
OpenBSD and FreeBSD do not display any dmesg output at all
NetBSD has a VESA framebuffer console which will boot, and display dmesg output, but crashes midway - can't find disks properly
vesa list vesa 1280 x 850 x 16 boot
We see dmesg output on the screen change resolution to a (very) small font and start it's output
[...]
If I run "vbeinfo" within Grub2 on the Pixel 2013, we get a long list, including 640 x 400 and 800 x 600
On the Pixel 2015, "vbeinfo" only gives one entry, and one entry only of 1280 x 850 x 16
Could this explain why *BSD operating systems and MemTest utility cannot boot from USB or SD card (..properly..) ? They boot up in a "text console", versus a "graphical console in text mode".
It's certainly possible that cbvga SeaVGABIOS is the cause. The cbvga support in SeaVGABIOS is a hack to get some minimal display support when only a graphical framebuffer is available. It is known to not work with some bootloaders and OSes (that don't use the VGA BIOS to write to the screen). For that reason, it's not going to work with MemTest86+.
Looks like you have a rom from John Lewis. I'd confirm that the SeaVGABIOS in the rom is relatively recent as there were some changes ("leal" emulation) that are known to work better on the *BSDs.
Correct. I installed the ROM from John Lewis about 2 weeks ago.
If SeaVGABIOS is recent, then I think the next step would be to see if you can replace SeaVGABIOS with an Intel VGABIOS.
-Kevin
P.S. it should be possible to implement a SeaVGABIOS with support for mode switching on Intel graphics adapters. That should solve these problems (at least on Intel hardware), but it's a bit of work as I find the Intel graphics manuals to be basically indecipherable. :-(
Does this explain why there is only one mode available. Other resolutions could be added, but since there is no support for mode switching, we don't have the ability to change back and forth from any of them, even if we tried.
-
edward wandasiewicz -
John Lewis -
Kevin O'Connor