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.
//Pe
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
Descri
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 documentati
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
SeaBIOS@sea
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 t
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
, fix spellings in commit message ]
>
> Signed-off-by: Gerd Hoffmann
Acked-by: Peter Stuge
___
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
Gerd Hoffmann wrote:
> > and pass down the
> > tables to the firmware (through a now unspecified interface -- perhaps
> > the tables could even be installed at this point).
>
> As far I know coreboot can add more stuff such as acpi tables to cbfs at
> runtime and seabios able to access cbfs too an
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
http
Paul Menzel wrote:
> I would like to know how much time, SeaBIOS takes to execute
tools/readserial.py
pgp1U_PU8pU5D.pgp
Description: PGP signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
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 >
> /hom
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 othe
Gerd Hoffmann wrote:
> > -pci_config_maskw(bdf, PCI_COMMAND, 0, PCI_COMMAND_MASTER);
> > +pci_config_maskw(bdf, PCI_COMMAND, 0, PCI_COMMAND_MASTER |
> > PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
>
> I think that should go in. If we need it, we better make sure it
> is enabled
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
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) {
> +}
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
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 n
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
init
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
pgpQrleoTZt7n
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 initia
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 c
刘俊峰 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:
> 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
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 wou
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
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
___
SeaBI
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
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.
>>
>>
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 approa
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 tra
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 sur
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_AS
Kevin O'Connor wrote:
> If the new "VERSION=" parameter is not provided then the default build
> version remains unchanged.
I prefer Alex' patch, because it defaults to reproducible but
provides more information if the tree has been modified, all
automatically.
A user parameter like your VERSION
Kevin O'Connor wrote:
> > > If the new "VERSION=" parameter is not provided then the default build
> > > version remains unchanged.
> >
> > I prefer Alex' patch, because it defaults to reproducible but
> > provides more information if the tree has been modified, all
> > automatically.
> >
> > A u
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
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
Kevin O'Connor wrote:
> > Depends on the packaging tool, not the distro,
..
> > So there shouldn't be *that* many different cases.
>
> Well, there's also Arch and likely others. If someone wants to send a
> patch then we can take a look. My initial thought is that it seems a
> bit complex.
Yes.
Kevin O'Connor wrote:
> > > +`make EXTRAVERSION="-${RPM_PACKAGE_RELEASE}"`
> >
> > That'll work, but 'make EXTRAVERSION="-%{release}"' is the shorter and
> > more common way to say this.
>
> In the context of an example, however, the ${RPM_PACKAGE_RELEASE}
> seems a little more descriptive. That
John Lewis wrote:
> Just a heads up - I'm compiling master with the only changes being to
> Kconfig
What changes do you have exactly?
> and it's being treated like a dirty build.
How is it being marked as dirty?
Since you are essentially creating releases using a known environment
I would en
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
http://www.seabios.org/mailman/listinfo/seabio
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
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 woul
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",
> +
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 can
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
> sh
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 the
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?
> >
> >
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 gue
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
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 SeaB
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 bas
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 ha
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 servi
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 &&
> +
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
___
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 CONFIG_INITR
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 respect
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
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.
https://review.coreboot.org/cgit/coreboot.git/tree/util/c
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*
//P
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 acc
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
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 separa
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 pos
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
> > 0
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 u
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;
> +re
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 duri
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
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:
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.
>
>
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
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
101 - 181 of 181 matches
Mail list logo