Isaku Yamahata wrote:
IO port ends at 64K - 1. not 64K.
Is the parameter end of region, or size of region?
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Typo in subject.
Gleb Natapov wrote:
WHQL complains otherwise.
Is there something further that should be activated, to actually
allow the wakeup to work? Hm, isn't S4 hibernate?
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
Scott Duplichan wrote:
]1) When booting a DOS drive, a disk read error occurs at some point
]after autoexec executes.
The revised patch (attached) overcomes this problem. It turns out in
the latter stage of booting, DOS makes a couple of INT13 read requests
with a buffer that is not word
Scott Duplichan wrote:
Another possibility is splitting the request. The caller's buffer
could handle the bigger part, and a stack buffer could be used for
the remaining part.
I think this idea is by far the best!
//Peter
___
SeaBIOS mailing list
Ian Campbell wrote:
One problem I have with the first patch is that I'm lacking the
vocabulary to describe the configuration which is currently
represented by COREBOOT=n.
..
+++ b/src/Kconfig
@@ -4,12 +4,27 @@ mainmenu SeaBIOS Configuration
menu General Features
+choice
+
Stefan Berger wrote:
- enable configuration of SeaBIOS to be built with TCGBIOS extensions
depending on COREBOOT not being selected
Why is this neccessary?
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
Daniel Castro wrote:
out/code16.o: In function `process_op':
/home/daniel/workspace/seabios_patch/src/block.c:304: undefined
reference to `process_xen_op'
make: *** [out/rom16.o] Error 1
Linking out/rom16.o
out/code16.o: In function `xen_blk_op':
make: *** [out/rom16.o] Error 1
What
Ram Bhamidipaty wrote:
Hi - I am behind a corporate firewall and cannot directly access git
repositories. Is is possible to access the seabios git repository
via the http protocol?
Why not just try it?
$ git clone http://git.seabios.org/seabios.git
Cloning into seabios...
fatal:
Hi Fred,
Please remember to avoid top-posting. It makes mailing list
discussions incredibly awkward to follow.
Fred . wrote:
I am not a programmer.
But I looked at the specification and it looks short and simple, so it
looks like it would be quick and easy for a programmer to implement.
Fred . wrote:
Since we already have support for 32-bit PCI, then it would be great
if 64-bit PCI support could be added if it perhaps only require a
slight modification to the existing code.
You have misunderstood. The release notes refer to 32bit PCI BIOS,
in this case the CPU mode, and has
Fred . wrote:
A BIOS password would add an additional line of defense and protect
against booting from a removable device such as CD or USB.
Compile out those drivers.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
Fred . wrote:
In the Windows splash screen the Windows logo is glowing.
It would be nice if SeaBIOS supported animated splash screens.
As was mentioned, SeaBIOS doesn't run for very long. But sure,
anyone is free to send a patch and let's have a look. Maybe a nice
solution could be created
Fred . wrote:
I do not know low-level programming.
So I just come up with ideas that I posted here, and mention stuff
that needs to be documented.
And say that website needs to be improved.
Well my point is you can contribute also without programming. The
suggestions are good, but if you want
Fred . wrote:
Add to source tree.
bootsplash.bmp
I'm afraid that's not likely.
The file is 1.2 MB, which would grow the current repository size
over 30%. I find that unacceptable for a bootsplash file that most
will really notice or want.
Recall the discussion when you first brought up the
Kevin O'Connor wrote:
Testing is going to be the real challenge. I don't even know what (if
anything) actually uses some of the obscure vgabios calls.
See if you can locate a copy of SciTech Display Doctor.
//Peter
___
SeaBIOS mailing list
Gerd Hoffmann wrote:
and I doubt anyone runs a cirrus bios on non-virtual hardware ...
If the Cirrus support is exclusively for virtual machines then at the
very least please make that abundantly clear in the menuconfig
oneline description.
//Peter
Jan Kiszka wrote:
Well, the Linux kernel can also be built with practically any distro
out there.
Yeah. Maybe that gets tested more than building coreboot and SeaBIOS,
and so problems are discovered by those who introduce them.
Having a need for a separate toolchain for building x86 on x86
Fred . wrote:
Intel provides a Linux-ready Firmware Kit, available on a LiveCD
Yes.
I guess it can give us a idea of the quality of the BIOS.
So what were your results?
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
Julian Pidancet wrote:
Sorry for the noise. None of these emails got through to the
xorg-devel mailing list. Will retry later.
I would appreciate if you looked at the coreboot x86emu as well.
http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=src/devices/oprom/x86emu
//Peter
Kevin O'Connor wrote:
By my count, this would be the third rewrite of the PCI bar
initialization in the last 14 months.
This happens to be solved really well in coreboot already. I can not
understand the crazy duplicated effort.
//Peter
___
SeaBIOS
Kevin O'Connor wrote:
No status is put anywhere to indicate why the
controller stops updating the frame counter.
Your suggestions for what to try are excellent.
At this point it might be a good idea to look at CS5536 errata, if
there is anything concerning the OHCI.
//Peter
Luiz Capitulino wrote:
Using latest seabios makes it go away, didn't try re-building
1.6.3.1 though.
Try it, if your toolchain is not broken it should work.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
Igor Mammedov wrote:
not even sure we should halt at all. May be warn the user and continue
BIOSes usually stop in case of error
That doesn't mean that it's a good idea.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
Fred . wrote:
Why did the version jump from 0.6.2 to 1.6.3 ?
Who cares - it's just a number.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Srini Amble wrote:
SeaBIOS is the payload for coreboot in my case. Looking at the
source files I have for coreboot and SeaBIOS I do not see reference
to 'devicetree.cb' any where. Also, any pointer to how to disable
the device in 'devicetree.cb' is much appreciated.
In the coreboot source
Michael Tokarev wrote:
Maybe this Standard VGA should be named something like Old VGA?
IBM PC/XT/AT 128K VGA ?
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Kevin O'Connor wrote:
@@ -26,18 +27,18 @@ menu VGA ROM
config VGA_BOCHS
depends on !COREBOOT
-bool Bochs DISPI interface VGA BIOS
+bool QEMU/Bochs VBE SVGA
Maybe VESA ?
Either way:
Acked-by: Peter Stuge pe...@stuge.se
This has very little to do with technical properties, and is much
more about politics which obviously require a different approach
than technicalities.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
Fred . wrote:
How is SeaBIOS working towards the non-technical goals of the project?
This is not so clear. I'm not even sure that there are non-technical
goals for the project.
Competing with commercial BIOS products would require a company to
put a SeaBIOS-based PC firmware to market, quite
Fred . wrote:
And in terms of standards compliance?
The nature of BIOS is that there isn't a standard to comply with.
I know proprietary BIOS have advantage when it comes to SMBIOS due
to the implementation in SeaBIOS lagging behind several versions.
Do you know of concrete issues because
Alain Ribière wrote:
I also join two print screen of the same C-DOS utility. One with
Qemu 1.0 and SeaBIOS 1.7.0 and the other with Qemu 0.10.0. The
amount of memory is quite different between the versions.
It might be interesting to see even more verbose output, like from
the mem tool in
ron minnich wrote:
Perhaps it would be possible to set a reasonable optional timeout
and then have it reboot or, better, just redo the hardware scan
and try again.
That sounds like the best of both worlds.
//Peter
___
SeaBIOS mailing list
Kevin O'Connor wrote:
+// Unable to find bootable device - warn user and eventually retry.
+static void
+boot_fail(void)
+{
+printf(No bootable device.\n);
+// Wait for 60 seconds and then reboot.
+u32 end = calc_future_timer(60*1000);
I'd suggest printf(No bootable device
Kevin O'Connor wrote:
On Fri, May 11, 2012 at 09:09:22AM -0700, ron minnich wrote:
Let me know if this format is ok, this is the first in a series :-)
The format is okay. It's preferable if you can mail the output of
'git format-patch' directly, but it's also okay as an attachment. I
use
Gerd Hoffmann wrote:
standard IDE cdrom. That type of cdrom has been around for a long
time.
dos is even older though, it used to *not* ship with a standard ide
cdrom driver. mscdex alone isn't enougth to make it fly, it is some
kind if high level driver (basically handles iso9660
Fred . wrote:
when I tried it under QEMU it did not work
So what happens? What does the serial debug log look like? If you
don't provide details about the problem it is impossible to give
any advice.
Please read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
//Peter
Christian Gmeiner wrote:
I did some more research and came up with the following idea/plan:
* search for valid edid binary blob (maybe this can be done with cbfs
from coreboot)
* extend vgasrc/geodevga.c to make use of edid information's
* extend vgasrc/vbe.c to support edid calls (104f15)
Fred . wrote:
What is SeaBIOS stance on Trusted Platform Module (TPM) ?
I guess that there is no stance until you or someone else sends
patches that we can discuss.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
Fred . wrote:
Add support for booting from IEEE 1394 (aka FireWire) interface.
Same here - noone is likely to do this until they want to have it
themselves. When someone is doing an implementation we can talk about
details.
//Peter
___
SeaBIOS
Fred . wrote:
I see.
It should be added to an TODO list though.
Or things-you-work-on list.
TODO is for things that existing project participants plan to do.
FireWire and TPM is not neccessarily planned by anyone. If you plan
to do it, then please just send a patch which introduces something
Matthew Millman wrote:
This line in usb-uhci.c (reset_uhci()) broke it:
pci_config_writew(bdf, USBLEGSUP, USBLEGSUP_RWC);
According to the US15W datasheet, there is no register at this offset,
there does seem to be something there because it reads 0x0400 after that
write, but I don't
Markus Armbruster wrote:
SeaBIOS requires a minimum of 1Meg of ram. I didn't even know one
could request less than 1meg of ram from QEMU.
I'll cook up a QEMU patch to give it at least that much.
But QEMU may use other firmware/payload than SeaBIOS which might
require less than 1 MB
Fred . wrote:
No, I am not.
Ok, so there's only a hypothesis.
But I believe QEMU does have the functionality to load an arbitrary
firmware. So the firmware doesn't necessarily have to be SeaBIOS.
As you may know the 8086 reset vector is at 1MB-16 so it will be
really difficult to run a
Christian Gmeiner wrote:
What is the default state/video mode the VideoBios should enter
during/after init?
Traditional VGA BIOSes always init mode 3.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
ron minnich wrote:
next problem: If the seabios build fails, and you do a make again,
it fails with this kind of error
CC cbfs/fallback/coreboot_ram.debug
OBJCOPYcbfs/fallback/coreboot_ram.elf
Checking out SeaBIOS revision 385a7d0dec28841a05531cba96c62138c3959fef
ron minnich wrote:
we're going a tutorial at CISL here in buenos aires tomorrow,
so would be very cool if we can fix this before then :-)
It is simple to work around the modified src/acpi-dsdt.hex error, but
I don't know if blindly overwriting changed files including whatever
the user has done
Kevin O'Connor wrote:
Checking out SeaBIOS revision 385a7d0dec28841a05531cba96c62138c3959fef
error: Your local changes to the following files would be overwritten
by checkout:
src/acpi-dsdt.hex
..
I've seen this happen.
..
I would very much appreciate an explanation why
Kevin O'Connor wrote:
Would you suggest bumping what coreboot uses as stable commit to 1.7.1?
Yes.
OK. Ron, please see if that issue is fixed now.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
Paolo Bonzini wrote:
+++ b/src/boot.c
@@ -400,54 +400,75 @@ interactive_bootmenu(void)
while (get_keystroke(0) = 0)
;
-printf(Press F12 for boot menu.\n\n);
+wait_threads();
+struct bootentry_s *pos;
+for (pos = BootList; pos; pos = pos-next) {
+if
ron minnich wrote:
I don't even know what to say :-)
Checking out SeaBIOS revision 51755c3b5ed9dcdfdef8cee56631d68642bde416
Already on 'master'
fatal: reference is not a tree: 51755c3b5ed9dcdfdef8cee56631d68642bde416
Sorry for not testing more thoroughly, the checkout did work for me,
I
Christian Gmeiner wrote:
USB is finally working :) http://dpaste.com/815054/
Very nice!
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Fred . wrote:
Fred . wrote:
Anyone wishing to test this, can get a bootdisk from bootdisk.com.
http://bootdisk.com/bootdisk.htm
Did you verify that those bootdisks do in fact reproduce the problem?
Doing that would be a good way to help the project.
No, I did not.
It would
Hannes Reinecke wrote:
+++ b/src/megasas.c
@@ -382,18 +382,17 @@ megasas_setup(void)
if (pci-vendor != PCI_VENDOR_ID_LSI_LOGIC
pci-vendor != PCI_VENDOR_ID_DELL)
continue;
-if (pci-device != PCI_DEVICE_ID_LSI_SAS1064R ||
-pci-device !=
Fred . wrote:
I've seen other BIOS (Award, AMI) have a setting in the menu to enable
Boot sector protection.
Did you study what it actually does?
What would be possible in SeaBIOS to prevent overwrite boot sector,
mbr, partition tables?
Nothing, really. An operating system can always
David Woodhouse wrote:
seems to *stop* before displaying the 'Autoboot in 9 seconds
Sounds like a timer problem. The hardware interrupt somehow supports
that theory.
//Peter
pgp2EGQXOpjLv.pgp
Description: PGP signature
___
SeaBIOS mailing list
Fred . wrote:
I propose the name running_on_Xen()
The proper way to do that is to send a perfect patch, created using
git, with your commit on top of current seabios.git code.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
David Woodhouse wrote:
is it just that all PC BIOSes are written by crack-smoking hobos
that they drag in off the street, and this is just an artefact of
the rule anything they *can* get wrong and still boot Windows,
they *will* get wrong?
I wouldn't be surprised.
//Peter
Laszlo Ersek wrote:
I've made peace with generating AML in C source.
As it happens, coreboot has a good infrastructure for generating AML
at runtime since years already.
Of course static tables in coreboot are no better than static tables
elsewhere. There are two reasons why moving all this
Gerd Hoffmann wrote:
1. Significant amounts of code can quite likely be shared between
many different hypervisors, since coreboot already shares significant
code between many different hardware platforms, never mind the reuse
possible across *both* hypervisors and hardware.
Not really.
Gerd Hoffmann wrote:
gets. It sounds like there will soon be need for a more generic PCI
resource allocator, which is another thing that coreboot already has.
--verbose please.
Alex Williamson wrote:
It does make some sense that SeaBIOS initializes PCI, so should be
responsible for this
Gerd Hoffmann wrote:
Option one is to let qemu provide them, then both ovmf and seabios can
grab them via fw_cfg.
Option two is to use coreboot underneath
I don't think one should exclude the other, I think it would make
great sense to combine them. So have coreboot on QEMU read some
ron minnich wrote:
you need to get the physical frame buffer address from the hardware
and then mmap that in user mode.
Yes, that's what he has been doing. The BAR points to some address
which doesn't remember writes.
//Peter
___
SeaBIOS mailing
Laszlo Ersek wrote:
Going out on a limb, I suspect qemu commit 5f876756 instead.
..
I think the gcc version Anthony was using miscompiled SeaBIOS
Yeah, it is very common. Lots of distributions patch their
toolchains such that they don't compile firmware code correctly.
Firmware isn't a common
Aurelien Jarno wrote:
We probably want update the build process to build the blobs by default
Earlier in this thread it's been stated that this often produces
subtly broken blobs...
Would it be possible to have a testsuite to validate such blobs.
The coreboot project has a test
Kevin O'Connor wrote:
I don't believe that dictating one true compiler or one true
blob is necessary or desirable.
Sure. The point isn't to have only one correct way, but to have
reliable results in the common case.
A reference toolchain and a reference blob both help accomplish
that, but
Kevin O'Connor wrote:
Thoughts?
I wish this effort could go into coreboot instead, so that it could
benefit more than only one machine.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Michael S. Tsirkin wrote:
Also, in qemu I don't think we want to carry around code we never use.
I'm sure you know that the SeaBIOS world is a lot more than just QEMU,
so probably it makes sense to not change whatever the default was
before your change. I get the impression that you have.
Paul Menzel wrote:
I still do not understand how SeaBIOS uses the interfaces itself
and how SeaBIOS is of any use at all without being able to boot
something. At least I do not know of such a use case.
Payloads can also not be started without that option?
//Peter
pgpOPwSGiBmrd.pgp
Paul Menzel wrote:
http://www.coreboot.org/SeaBIOS#coreboot - do not load the vga
option rom in coreboot - do it in seabios.
Yes, thanks. Though I assumed »best results« would mean
Please don't assume. When something is unclear, creating an
opportunity for assumption, then documentation
Kevin O'Connor wrote:
Basically everything under the BIOS interfaces menu is low-level
and should not be changed without understanding the implications.
Maybe hide those behind a CONFIG_EXPERT option?
//Peter
___
SeaBIOS mailing list
Paul Menzel wrote:
Again as in the other thread this probably stems from the fact that I
have the (wrong(?)) assumption that BIOS interfaces are not needed for
GRUB or Linux.
GRUB needs BIOS interfaces. GRUB 2 as payload might not, but GRUB 2
on a random debian system does. It's clear that
Paul Menzel wrote:
I do not even know what the BIOS boot interface does and how it is
utilized. I guess I should read up about that.
Hundreds if not thousands of interrupt services and about a dozen
data structures.
//Peter
pgpIFHbM5p9U6.pgp
Description: PGP signature
Paul Menzel wrote:
it would be nice if it is clear for noobs like me, what certain
option do and what effects they have.
The good way to fix that is for you to send patches for the Kconfig
help messages. *After* you have researched what the options do.
//Peter
pgptDFHdnLwQL.pgp
Description:
li peter wrote:
maybe qemu-kvm use non-coreboot uses,
Correct. qemu-kvm unfortunately uses a special-case build of SeaBIOS
without coreboot.
How do I do to reach my goal？
I am not sure. If SeaBIOS also has bootsplash support then you should
see options in the SeaBIOS build configuration. If
message ]
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Acked-by: Peter Stuge pe...@stuge.se
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Kevin O'Connor wrote:
one possible way forward would be to split the current SeaBIOS rom
into two roms: qvmloader and seabios. The qvmloader would do
the qemu specific platform init (pci init, smm init, mtrr init, bios
tables) and then load and run the regular seabios rom.
qvmloader sounds a
Fred . wrote:
Sounds like something that should be commented in the source code.
Sounds like something that even you could send a patch for.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Anthony Liguori wrote:
However, with PCs, the ACPI tables are generated by/included in the
firmware. There's no question about that.
I think the key point is that the firmware is developed and delivered
by the hardware vendor, and not by an independent source.
The firmware is intimately tied
Paul Menzel wrote:
+if (pages 2)
+pages++;
Can pages be 0? If yes, it would be 0 again after substracting 1. Should
it be `pages = 1` instead of `pages++`?
pages=2;
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
Idwer Vollering wrote:
Actually, this happens when you clone coreboot into a dir where its
parent dir has a dot in it, and compile for any board without touching
the payload defaults:
python ./tools/acpi_extract.py
/home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.lst
Denis 'GNUtoo' Carikli wrote:
I've tested it like that:
* I've added it to my branch where I rebased the lenovo x60 native GPU
init patches left, and the rest that I want and that isn't in
coreboot yet.
The commits from your branch which you pushed with me as author and
which four other
H. Peter Anvin wrote:
Uh... seriously, robustness is a good thing, and it is not entirely
clear that this responsibility necessarily belongs in Coreboot.
It's clear to me. The coreboot (all lowercase please) code for QEMU
isn't neccessarily complete, and needs these kinds of improvements.
Paul Menzel wrote:
could some expert please comment, if `-fwhole-program` already
optimizes the code the best way possible for GCC and therefore
LTO is not going to reduce SeaBIOS’ binary size?
I think this is a moving target; how well the optimizer works depends
on how mature the optimizer is
Gerd Hoffmann wrote:
+++ b/src/fw/pciinit.c
...
@@ -721,16 +728,11 @@ static int pci_bios_init_root_regions_io(struct pci_bus
*bus)
if (sum 0x4000) {
/* traditional region is big enougth, use it */
r_io-base = 0xc000;
-} else if (sum 0x9000) {
+} else if
Kevin O'Connor wrote:
Although SeaVGABIOS is in the SeaBIOS git repo, it builds a totally
separate ROM.
How much source code overlap is there?
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Kevin O'Connor wrote:
Although SeaVGABIOS is in the SeaBIOS git repo, it builds a totally
separate ROM.
How much source code overlap is there?
It's basically debugging, pci config access, some simple string
functions, and coreboot table traversal.
Would it make sense to turn them
Kevin O'Connor wrote:
Would it make sense to turn them into two separate projects?
If you mean separate git repos, then that is an open question.
Right, that's what I meant.
I'd lean towards keeping them together right now.
Could another option be to allow building of both, without
Paul Menzel wrote:
I was told coreboot and SeaBIOS are too fast for the SSD and it
needs at least 500 ms for its initialization.
Though looking at the code in `src/hw/ahci.c`, it should have 32
seconds to initialize.
The SSD can probably not deal with any SATA activity until it has
Paul Menzel wrote:
Some message on the screen informing the user about a bad device could
be helpful,
It is a bad idea for SeaBIOS, or any software really, to try to guess
why hardware is not working. Reporting errors is good, pretending to
know what they mean is not.
//Peter
Paul Menzel wrote:
testing QEMU with coreboot built from commit a296f9e3 (Kconfig: Allow
native vga init to be selectable for SeaBIOS payload) [1] and SeaBIOS
and SeaVGABIOS (selected in coreboot’s Payload menu), SeaBIOS does not
display any graphics although the console says, it has
Pandey, Sunil K wrote:
the fix is already in the master, but it's hard for me to use
directly from master. Currently all existing tags are old and
doesn't reflect latest layoutrom.py changes.
Wherever you use a tag with git you can also provide a commit hash.
It should work well to simply
刘俊峰 wrote:
I wonder whether a virtual CD drive implemented at BIOS level can
persist even after OS is boot up?
Sure. Study System Management Mode. It can be used to virtualize
hardware of many kinds, including an optical PATA drive.
My guess is that you will have to implement it yourself.
Kevin O'Connor wrote:
Once this patch is applied it is possible to get reproducible builds of
Xens hvmloader.
I've found the version information to be quite helpful when we get
trouble reports - it helps indicate what was being run and who built
the code (eg, distribution or local).
Kevin O'Connor wrote:
What breaks if the version changes?
Reproducible builds; allowing to create a consensus that a particular
binary is indeed the correct binary for a particular source code.
That is useful. A solution for stabilizing gcc/binutils output would
also need to be
Timothy Pearson wrote:
Is there anything else that needs to be done before this can be merged?
Have you considered creating a more fine-grained control knob than
simply global on/off?
Maybe a BDF blacklist, perhaps stored in CBFS?
I might implement something like that in the future if I
Timothy Pearson wrote:
Maybe a BDF blacklist, perhaps stored in CBFS?
I might implement something like that in the future if I have
time/inclination, but for now the on/off switch is sufficient.
Sufficient sure, but it is certainly using a sledgehammer to pound a nail.
Adding a blacklist
Paolo Bonzini wrote:
I can think of a few options:
7 - use top of video memory as stack?
That would be pretty slow on KVM, since video memory is MMIO.
slow reliable fast unreliable
But worse, one could imagine that NTVDM blocks a-b as well.
I doubt that? Then how would the
Kevin O'Connor wrote:
I can think of a few options:
7 - use top of video memory as stack?
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Kevin O'Connor wrote:
This patch in particular guarantees that no matter what devices
are plugged in (e.g. long after the BIOS has been flashed) they
will not have their option ROMs executed.
That makes sense, but I think it needs to be a runtime setting.
Timothy's original approach is
Timothy Pearson wrote:
Is there anything else that needs to be done before this can be merged?
Have you considered creating a more fine-grained control knob than
simply global on/off?
Maybe a BDF blacklist, perhaps stored in CBFS?
//Peter
___
1 - 100 of 138 matches
Mail list logo
