Gerd Hoffmann wrote:
> A 2G 32-bit bar simply can't be mapped anywhere on x86. It must be
> below 4G,
Agree..
> and it must be 2G-aligned.
..but I can't find this requirement. Why do you say?
The one mention of alignment in PCI 3.0 is for the Expansion ROM BAR,
where *the device* can indicate
Hi Christopher,
christopherericlento...@gmail.com wrote:
> tom Firmware
>
> while using the SeaBios payload with MrChromebox's SMM variable
> in coreboot. This is required even if we are booting off of a
> USB, since it will give MMC errors in Linux and Windows 10
> and 11 won't see it, though I
Hi Paul,
Paul Edwards wrote:
> I have a new variation on this problem.
>
> I have a Chromebook with seabios loaded.
>
> But the Chromebook doesn't have a serial port.
>
> I could get a USB to com port adapter.
>
> But I would like seabios to drive this so that I can use int 14h in my os.
>
>
Paul Menzel wrote:
> Do you have any ideas regarding the USB issues with a dedicated GPU
> device with integrated USB Type-C port plugged in [1]?
Only speculation:
Maybe multiple xHCI controllers trip up the SeaBIOS xHCI driver?
Two tests would be useful, the latter can be performed by anyone:
Kevin O'Connor wrote:
> > SeaBIOS can be used for booting legacy OS and also Linux is still using
> > CMOS address 0x10 to configure floppy controller. Under these assumptions
> > it makes sense to allow boot from CMOS defined floppy drives.
>
> There was never really a standard for the layout of
Kevin O'Connor wrote:
> > Also Intel ICH7 Family Datasheet, chapter 5.8 states:
> >
> > Programming the counter to anything other than Mode 2 will result in
> > undefined behavior for the REF_TOGGLE bit.
> >
> > Failing to have the timer 1 configured indeed causes affected OSes to
> > freeze
Igor Mammedov wrote:
> +++ b/src/fw/pciinit.c
..
> @@ -819,12 +825,13 @@ static int pci_bus_hotplug_support(struct pci_bus *bus,
> u8 pcie_cap)
> */
> u16 slot_implemented = pcie_flags & PCI_EXP_FLAGS_SLOT;
>
> -return downstream_port && slot_implemented;
> +
Hi Paul,
Paul Edwards wrote:
> >> > Sure. Implement a driver for that redirection which behaves as an
> >> > int14h handler and place the address of its entry point at address
> >> > :0080. (14h*4)
> >>
> >> > The method works with any BIOS.
> >>
> >> I would like it to work with any OS that
Hi Paul,
Paul Edwards wrote:
> Resending ... I thought I was subscribed, but apparently
> I am not.
Okay, including you directly in this reply then.
> > Sure. Implement a driver for that redirection which behaves as an
> > int14h handler and place the address of its entry point at address
> >
Hi Paul,
Paul Edwards wrote:
> INT 14H is designed to read/write to a serial port.
>
> I would like my software (OS) that uses this interface
> to, on a machine that doesn't have a serial port, be
> directed to some other device, like bluetooth to my
> phone or Wifi to my router.
>
> Is this
Hi,
Gerd Hoffmann wrote:
> Note that the linux kernel's in-kernel interfaces are explicitly *not*
> backward compatible though.
..
> I fail to see the problem. seabios is part of the firmware,
So that's important, I hope to help create some understanding:
coreboot and SeaBIOS are cleanly
Hi Gerd,
Gerd Hoffmann wrote:
> > > This breaks compatibility with very old coreboot build (build before
> > > fb5d5b16 "2015-07-14, cbtable: describe boot media").
> >
> > Is that really acceptable in SeaBIOS master at some random time?
>
> As far I know there is no policy on that written down
Arthur Heymans wrote:
> This breaks compatibility with very old coreboot build (build before
> fb5d5b16 "2015-07-14, cbtable: describe boot media").
Is that really acceptable in SeaBIOS master at some random time?
At the very least I would expect a flag day with advance publicity.
One way of
Kevin O'Connor wrote:
> Update the documentation to be explicit about the signed-off-by
> convention.
FWIW I'm against that convention, and would rather see it abandoned,
than the project submitting to arbitrary and ridiculous requirements
set by legal departments in US corporations. *shrug*
Rafael Send wrote:
> I actually had NOT come across mkelfimage!
I see. The old wiki pages I linked to in a previous mail show it
being used. It's a very old tool from LinuxBIOS v1 times, since
replaced by functionality built into cbfstool.
Rafael Send wrote:
> I had already testes the coreboot + Linux kernel without SeaBIOS,
> that works fine.
That's a great start! So did you look into what happens under the
hood when you do that, to learn?
The original common case for coreboot payloads was also ELF files, so
there is much overlap
Mike Banon wrote:
> "Loading vmlinuz...CHS: Error 0101 reading sector 18277 (8/59/6) ---
Don't spend too much time on the arcane CHS concept, it is really
obsolete and that's for the better.
You're trying to hack a data structure and interface to do what you
want, which is something I can
Rafael Send wrote:
> Alternatively, would it be possible to create an ELF file out of a Linux
> kernel+initrd / bootable image?
Sure, and I find it far more attractive than arcane floppies, charming
as they are.
Build your kernel to include your initramfs, the kernel config option
is
Kevin O'Connor wrote:
> it's a little odd to have a C function sometimes return a dynamically
> allocated string and sometimes return a constant string.
Gerd, please don't do that. Sure, maybe nothing is ever free()d, but
that's still very poor practice. Don't spread it.
//Peter
Gerd Hoffmann wrote:
> +++ b/src/optionroms.c
> @@ -193,6 +193,11 @@ run_file_roms(const char *prefix, int isvga, u64
> *sources)
> file = romfile_findprefix(prefix, file);
> if (!file)
> break;
> +if (strcmp(file->name, "vgaroms/sgabios.bin") == 0 &&
> +
Zoran Stojsavljevic wrote:
> Did not understand... I must admit! As of my best interpretation
> SeaBIOS has 5 functions which makes BIOS legacy:
>
> get and set variables, get and set real time clock, reset.
>
> Or maybe, something changed.
SeaBIOS implements a whole bunch of legacy BIOS
Gerd Hoffmann wrote:
> * Initializing all pci devices (placing bars in address space and
>programming them) can probably be skipped and left to the linux
>kernel to handle.
When the coreboot project started out, in 1999, that turned out not
to be the case. I don't know if the situation
Blibbet wrote:
> It sounds like some Chromebooks have SeaBIOS with TPMv1
As far as I know all Chromebooks use their own payload which
implements verified boot. The root of trust is the write-protected
SPI flash. It is very well documented on the chromium website, you
would only have to do very
Marcel Apfelbaum wrote:
>> Given the bus number register is 8bit I'm wondering whenever this is a
>> valid hardware configuration in the first place?
>
> For sure no :), however we do have a possible endless loop
> and maybe is cleaner to panic. (no matter who is "responsible")
I would prefer
Kevin O'Connor wrote:
> SeaBIOS is careful to always disable IRQs while running C code to
> prevent this issue, but disabling normal IRQs does not disable NMIs.
> So, I believe this issue is specific to the nature of NMIs.
Would a dedicated NMI handler stack be a good solution?
//Peter
Kevin O'Connor wrote:
> > Doesn't it effectively take the same amount of wall clock time?
..
> If you're asking if current state vs unregistering/delaying would take
> the same wall time - thinking about that now, it might be true.
Right - that's what I meant. I think it will, because ..
> I
Kevin O'Connor wrote:
> Once the device is recognized as USB3, the controller disconnects
> it from USB2, but by that point SeaBIOS has already fully registered
> it and isn't even checking the connection status. The device is
> then fully detected as a USB3 device, which is why the duplicate
>
Kevin O'Connor wrote:
> > Would checking the connection status for each device after all
> > devices have been registered be able to filter the USB2 device out?
>
> Yes, but there isn't a way to "unregister" the drive once it's been
> registered.
Oh - why not?
If this has to do with e.g. BBS
Kevin O'Connor wrote:
> > > +static u32
> > > +read_stclear_flags(char *buf, int buf_len)
> > > +{
> > ..
> > > +if (rc || returnCode)
> > > +goto err_exit;
> > ..
> > > +err_exit:
> > > +dprintf(DEBUG_tcg, "TCGBIOS: TPM malfunctioning (line %d).\n",
> > > __LINE__);
> >
> > I
Stefan Berger wrote:
> +++ b/src/tcgbios.c
> +static u32
> +read_stclear_flags(char *buf, int buf_len)
> +{
..
> +if (rc || returnCode)
> +goto err_exit;
..
> +err_exit:
> +dprintf(DEBUG_tcg, "TCGBIOS: TPM malfunctioning (line %d).\n", __LINE__);
I can't help but think that it
Sorry, should have sent all in one email.
Stefan Berger wrote:
> +if (enable)
> +dprintf(DEBUG_tcg, "Return code from TPM_PhysicalEnable = 0x%08x\n",
> +*returnCode);
> +else
> +dprintf(DEBUG_tcg, "Return code from TPM_PhysicalDisable = 0x%08x\n",
> +
Nice series!
Kevin O'Connor wrote:
> The only three three callers
Typo ^
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Kevin O'Connor wrote:
> The 1.9.0 version of SeaBIOS has now been released.
Do we want to bump the coreboot stable version? Maybe someone already did..
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
Zheng Bao wrote:
Yes. Need test by our validation dept.
Thank you for working on this!
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Stefan Hajnoczi wrote:
Hi,
qboot (https://github.com/bonzini/qboot) is a stripped down firmware
providing only what is needed to boot a Linux kernel on x86.
Incredible, you have re-invented coreboot!
Well, maybe not, it is Red Hat after all.
How about putting your efforts into the existing
Kevin O'Connor wrote:
+++ b/vgasrc/vgaentry.S
@@ -64,6 +64,7 @@ x86emu_fault:
// This macro implements a call while avoiding instructions
// that old versions of x86emu have problems with.
.macro VGA_CALLL cfunc
+#if CONFIG_VGA_FIXUP_ASM
// Make sure leal
Kevin O'Connor wrote:
+++ b/vgasrc/vgaentry.S
@@ -64,6 +64,7 @@ x86emu_fault:
// This macro implements a call while avoiding instructions
// that old versions of x86emu have problems with.
.macro VGA_CALLL cfunc
+#if CONFIG_VGA_FIXUP_ASM
//
Kevin O'Connor wrote:
(Specifically, the leal instruction is not properly implemented.)
Unfortunately, there isn't much that can be done about this on the vga
bios side.
Really? Impossible to save flags, use other opcodes, and restore flags?
lea isn't used in vgasrc/ besides in the trap
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?
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
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
___
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
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
刘俊峰 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.
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
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
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:
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
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
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
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
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.
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
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
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
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
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
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
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
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
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:
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
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.
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
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
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
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
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
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.
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
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:
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'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
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:
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
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
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
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:
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
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
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
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
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
1 - 100 of 138 matches
Mail list logo
