[SeaBIOS] Re: Large 32 bit BAR's
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 its required alignment. So why couldn't a 2G BAR be mapped at 1G? If must size-align after all then there is at minimum one creative solution achieved by dividing the one 2G BAR into two 1G BARs, that can then be mapped at 1G and 2G. This could probably be hidden from the rest of the device by the bus interface. Just be prepared that firmware can map the two BARs in any order! //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] Fix Bay Trail Chromebook Bootup on MrChromebox's Cus...
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 didn't test 11, It would most > likely do it since all Linux versions I tried did the same. I'm merely a community member here but neither your commit message nor the comments you add to source files explain to me what is being done and why - only what the outcome is and that actually this problem is much larger than your patch addresses and that your patch is only applicable in certain circumstances (and harmful in others?). That will likely not be accepted into the codebase. It's completely okay to post the patch on this list anyway. But if you want the problem you experience to actually be fixed correctly/thoroughly then I think this issue needs much more work. Is that your ambition? Thanks and kind regards //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: INT 14H
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. > > Is that something that exists or could be added? Maybe. Like Bluetooth, USB is also non-trivial. But SeaBIOS does already have USB infrastructure and does already implement something in principle similar to what you want for int 13h and USB storage devices - that's both precedent and a reference. > I found that USB to serial port adapters are not standardized. That is true but there aren't all that many popular manufacturers of chips for such products, and if I understand correctly you can at least to some degree make recommendations on specific hardware to replicate the setup you're aiming for, so maybe it's okay to also pick one particular USB-to-serial chip and recommend products using that? > So instead, what about adding NDIS to do USB tethering plus a tcpip > stack to create a virtual modem that would allow you to do: Since SeaBIOS has no TCP/IP stack that would require far larger development effort, and introduce significant complexity to SeaBIOS for a very rare use case that so far only one person requests while at the same time not signalling readiness to provide long-term maintenance effort of source code - making it unlikely to manifest. > Would most of this be able to use existing code? A USB-to-serial adapter would allow pretty good reuse. I prefer the CP210x family of chips because the USB protocol and cost is sane (unlike FTDI, which fails massively on those points) and because they have always been very reliable for me, although e.g. CP2102N rev A01 chips have a whole bunch of serious errata. If you pick a CP2102N-based product then make sure to get ones using revision A02 chips. (This will be hard to find out! But: Other manufacturers have other issues, sometimes even undocumented.) Less complexity in SeaBIOS would probably only be achievable with a custom USB device. I asked before about the broader picture of your project but never got much of an answer. If it would be acceptable to provide instructions for programming some microcontroller development board to replicate your success as opposed to providing product recommendation for a particular USB-to-serial adapters then you could essentially make your own USB-to-serial adapter with firmware and thereby USB protocol optimized for the in-SeaBIOS use case. That may sound like over-engineering but the BIOS environment is special enough that it could be a reasonable design, if outside parameters and requirements permit. Hope this helps //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: USB keyboard not detected with dGPU with USB Type-C port
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: 1. Connect the keyboard to the graphics card USB port (try with and without a hub) 2. On any mainboard with coreboot and SeaBIOS (maybe even qemu), connect multiple xHCI host controllers (PCIe cards) and see what the logs say. Kind regards //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] floppy: Support CMOS setting outside QEMU
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 CMOS nor for the > encoding of floppy type. Ralf Brown's interrupt list disagrees: --8<-- CMOS.LST --R10 CMOS 10h - IBM - FLOPPY DRIVE TYPE Note: a PC having a 5 1/4 1.2 Mb A: drive and a 1.44 Mb B: drive will have a value of 24h in byte 10h. With a single 1.44 drive: 40h. Bitfields for floppy drives A/B types: Bit(s) Description (Table C0007) 7-4first floppy disk drive type (see #C0008) 3-0second floppy disk drive type (see #C0008) (Table C0008) Values for floppy drive type: 00hno drive 01h360 KB 5.25 Drive 02h1.2 MB 5.25 Drive - note: not listed in PS/2 technical manual 03h720 KB 3.5 Drive 04h1.44 MB 3.5 Drive 05h2.88 MB 3.5 drive 06h-0Fh unused SeeAlso: #C0007 -->8-- > Currently, SeaBIOS doesn't use CMOS for anything when configured for > coreboot mode and I think we should keep it that way. The first either 15 or 48 bytes are explicitly reserved on all coreboot mainboards and coreboot checksums bytes 16-45 when built to use an option table. > If you have a machine with a floppy drive that you'd > like to use with coorboot+SeaBIOS then you can set the "etc/floppy0" > or "etc/floppy1" cbfs files to activate support in SeaBIOS. That's fine, but why reject the de-facto standard method? Kind regards //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] timer: Configure timer1 to a standard settings
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 during the boot. > > Thanks. In general, I don't see an issue with initializing standard > hardware. While I agree that this change is needed somewhere, doesn't PIT initialization actually belong in coreboot? > However, a change like this could have a subtle impact on existing > installations. I don't think it will. Counter 1 should be running but is not. Programs that expect it to be running currently hang. Per the ICH6 datasheet, counter 1 output is not connected to any interrupt controller input, although I do vaguely remember using IRQ 1 interrupts which occured at a higher rate than IRQ 0 on AT hardware. ICH6 datasheet also says "A new initial count may be written to a counter at any time without affecting the counter's programmed mode. Counting is affected as described in the mode definitions." So any programs that would reconfigure the RAM refresh request signal counter (I think highly unlikely) don't care if it's already running. > Finally, have you found any documents that describe how timer1 is > intended to be configured on legacy systems? Hm, what qualifies as legacy systems? The ICH7 datasheet was quoted, ICH6 datasheet concurs. Yet another reference is Ralf Brown's interrupt list, mentioning XT and AT: --8<-- PORTS.LST --P0040005F-- PORT 0040-005F - PIT - PROGRAMMABLE INTERVAL TIMER (8253, 8254) Notes: XT & AT use ports 40h-43h; PS/2 uses ports 40h, 42h-44h, and 47h the counter chip is driven with a 1.193 MHz clock (1/4 of the original PC's 4.77 MHz CPU clock) SeeAlso: PORT 0044h,PORT 0048h 0040 RW PIT counter 0, counter divisor (XT, AT, PS/2) Used to keep the system time; the default divisor of (1)h produces the 18.2Hz clock tick. 0041 RW PIT counter 1, RAM refresh counter (XT, AT) don't set below 3 on PCs (default 12h), and don't mess with this counter at all unless you really know what you're doing -->8-- Kind regards //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH v3 2/2] pci: let firmware reserve IO for pcie-pci-bridge
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; > +return downstream_port && slot_implemented ? > +HOTPLUG_PCIE : HOTPLUG_NO_SUPPORTED; > } > > check_shpc: > shpc_cap = pci_find_capability(bus->bus_dev->bdf, PCI_CAP_ID_SHPC, 0); > -return !!shpc_cap; > +return !!shpc_cap ? HOTPLUG_SHPC : HOTPLUG_NO_SUPPORTED; Maybe remove !! here. //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: INT 14H
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 uses INT 14H > >> (regardless of how many of those exist), rather than > >> any BIOS. > > > It works both with any BIOS (int 14h provider) and any OS (that uses > > int 14h), so is a very general approach. > > Ok, the main thing is I don't want my OS to have to load > this, I want it loaded before the OS is loaded. I understood that, and an option ROM satisfies this. > >> For now I am happy if it only works with SeaBIOS, and > >> I will simply buy a PC that allows me to flash SeaBIOS > >> onto it. > > > PC Engines apu hardware comes with coreboot and SeaBIOS, but may or > > may not fit your application. > > This seems to be a kit. The bare board only needs power to run, everything is onboard. Some resellers may offer the board mounted in a case. > Does this imply most computers don’t allow their firmware to be > flashed with SeaBIOS? You can flash it, but the computer will no longer start. SeaBIOS doesn't perform hardware initialization of e.g. RAM and PCI busses. SeaBIOS was created to be a coreboot payload when a system with coreboot needed a BIOS to start the OS. > If that is the case, is there someone else I should be negotiating with? Good question - it probably depends on the bigger picture of your project. What do you want to accomplish in the end? Is this a one-off thing or high volume, how deterministic must it be in which environment etc.? > > Think of an option ROM as a modular expansion to any BIOS. > > This sounds promising. So perhaps manufacturers allow > option ROMs to be flashed, but just not the entire > BIOS to be replaced? Option ROMs traditionally exist primarily on option cards. SeaBIOS is cleverer and can also run option ROMs in the boot flash. A proprietary BIOS or UEFI will not likely run an option ROM from the boot flash. > > Here's an open source option ROM: https://github.com/alson/sgabios > > > It's x86 real mode assembly; the typical BIOS environment. > > I took a look thanks. But actually I am hoping all of this will > be in C. I was expecting INT 14H to be minimal x86 real > mode that switched to UEFI C code, Oh, UEFI.. You may know, but interrupt services such as int 14h are a BIOS interface, as provided by traditional BIOS implementations. UEFI implementations do not provide interrupt services, but a CSM can. > the same as CSM does (right?). I don't think UEFI mandates /how/ a CSM implements the interrupt services, I'd expect that a CSM can do what it wants without calling into UEFI, but depending on what it needs to do it may /want/ to call into UEFI. > I read that SeaBIOS supports CSM. SeaBIOS can act as CSM, at a minimum in VMs, I don't know what the situation is with UEFI implementations on hardware. > > A virtual graphics adapter is fairly complicated so I guess that your > > end result will be much simpler than SGABIOS is. > > Ok, for the specific case of converting INT 14H into Bluetooth - > I assume that much Bluetooth hardware is proprietary. Bluetooth is one of the most, if not the most, proprietary contemporary technologies. I think it may be the original case of a quasi-open standardization process coupled with fierce intent to keep any implementations as closed as possible. > But I know that libbluetooth exists. What does libbluetooth refer to, exactly? If you mean the shared library (.so file) on Linux systems then that isn't relevant for your idea. > Basically is it possible to flash libbluetooth onto an option ROM, > add 100 lines of x86 assembler to switch to long mode from INT 14H, > call libbluetooth, and call it a day? No way. > Or approximately how many lines of x86 assembler and C > code are required in addition to what SeaBIOS + libbluetooth > already provide? Or is there some technical problem > prohibiting this solution? The latter. libbluetooth.so is a mere fraction of the software involved in using BT on a Linux system. The majority exists in the Linux kernel and uses lots of kernel infrastructure, so can not run standalone. You very likely don't want to get into developing a BT stack, especially not one running in a BIOS environment. I strongly recommend to keep all BT parts of this project in separate hardware outside of the x86 system and to choose/design that hardware such that it's comfortable to use in your int 14h handler. Since the apu board has two serial ports (one internal on a header) its BIOS may already provide int 14h services for those ports, then you could just connect a transparent BT UART and be done, no software needed at all for that. //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to
[SeaBIOS] Re: INT 14H
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 > > :0080. (14h*4) > > > The method works with any BIOS. > > I would like it to work with any OS that uses INT 14H > (regardless of how many of those exist), rather than > any BIOS. It works both with any BIOS (int 14h provider) and any OS (that uses int 14h), so is a very general approach. > For now I am happy if it only works with SeaBIOS, and > I will simply buy a PC that allows me to flash SeaBIOS > onto it. PC Engines apu hardware comes with coreboot and SeaBIOS, but may or may not fit your application. > > If suitable for your hardware you could do all of it in an option ROM. > > I'm not familiar with this terminology. Is this something > that goes into SeaBIOS? I'm expecting it to be something > that is set up (and even configured by the end user in the > BIOS) before my OS is even loaded. Think of an option ROM as a modular expansion to any BIOS. Any BIOS discovers all option ROMs in a system and then runs them one at a time - indeed late-ish before loading the OS. There's really no limit to what an option ROM can do to the system. Some are interactive, others aren't, others still are completely invisible. Some option ROMs you may have come across could be a PXE ROM on a network card, a RAID configuration ROM on a SCSI adapter and the VGA BIOS option ROM on a graphics card. Here's an open source option ROM: https://github.com/alson/sgabios It's x86 real mode assembly; the typical BIOS environment. That code does also interact with int 14h, but pretty much does the opposite of what you want; SGABIOS provides a virtual graphics adapter on a serial port, while you want to provide a virtual serial port doing something specific. A virtual graphics adapter is fairly complicated so I guess that your end result will be much simpler than SGABIOS is. Hope this helps //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: INT 14H
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 possible? 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) I'd suggest to save the original int14h entry point address into your code and first call into that e.g. when queried by int14h users, appending your fake serial port to the results. If suitable for your hardware you could do all of it in an option ROM. The method works with any BIOS. //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] fw/coreboot.c: Use coreboot table to find cbfs
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 separated. This separation compares quite well to the clean separation between Linux kernel and the many applications you mention which depend on kernel APIs. I agree that coreboot should also pull weight to maintain compatibility here, but now and then all the burden falls on payloads. :\ > users are not going to freely mix and match versions. You do recognize that this is a self-fulfilling prophecy, I hope? They're certainly not going to do it if it was made impossible! > So if you are stuck with an old coreboot version for whatever reason, > just continue using an old seabios version. I find that attitude absolutely obnoxious, which is why I question whether SeaBIOS indeed wants to proceed with such an offensive change. Boards are removed from coreboot in most every release so "getting stuck" is a real thing. Announcing a deprecation flag day in the next SeaBIOS release to give people not reading every patch on this list an opportunity to engage is an easy ask. Why the rush? > It's not like seabios does see heavy development, and the changes > going in are mostly for new hardware support (recent example is nvme) > which doesn't buy you much on old machines. This just sounds like privilege, especially given Volker's recent threading/interrupt bugfix. That's a perfect example of a significant improvement which should be available also with older coreboot. Could of course create some SeaBIOS branches for backports and release master to move fast and break stuff, but I don't think that's the best option here. > > Firmware is not QEMU. > > Note that coreboot apparently considers 5 years of backward > compatibility enough. They supported both old and new method > for finding cbfs that long. Do you mean within the coreboot codebase? I agree with you if you suggest that coreboot should not remove backwards compatibility in the payload interface willy-nilly! But I assume that's off the table, so SeaBIOS can only decide how it wants to behave. //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] fw/coreboot.c: Use coreboot table to find cbfs
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 somewhere. In > general we try avoid breaking backward compatibility (and thus requiring > lockstep updates). But maintaining backward compatibility has a cost > too, so this isn't set in stone. Sure, but backwards compatibility is highly valuable, so will offset quite some cost. See Windows or the Linux kernel ABI. Here we are talking about a firmware compatibility, arguably even more valuable than a kernel ABI, because firmware often, and ironically this is probably no less true for coreboot than IBV products, simply can not be updated. I expect payloads to value backwards compatibility quite high. > > > Keeping backward compatibility with the "cbfs master header" would > > > complicate the code. > > > > Obviously, but is undeniably valuable, even if not to you. > > Well, maintaining compatibility with a version released more than five > years ago isn't that valuable IMHO, but comes with the cost of adding > compatibility code which most likely will never ever be actually used. I know that five years is forever in QEMU, and perhaps in particular at Red Hat. Firmware is not QEMU. At a minimum please at least announce a flag day a month or two out, to give those not on this list a chance. Thanks //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] fw/coreboot.c: Use coreboot table to find cbfs
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 accomplishing that would be to include a notice of this change with the next SeaBIOS release and if at all only delete backwards compatibility in the release after. > Keeping backward compatibility with the "cbfs master header" would > complicate the code. Obviously, but is undeniably valuable, even if not to you. Proper advance notice of a breaking change allows others to invest effort into coming up with a compatibility solution. //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: [PATCH] docs: Add developer-certificate-of-origin
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* //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: Custom-sized, large floppy images?
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/cbfstool/cbfs-payload-linux.c //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: Custom-sized, large floppy images?
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 with what you want to achieve. You probably already noticed the tool mkelfimage in the pages I linked to. Did you look into what it does, and why it's needed in the first place? (Hint: Linux is a bit needy.) > But I do want the rest of the boot menu presented by SeaBIOS > because I usually use Windoze as well. SeaBIOS creates a BIOS environment when there isn't one. That is its key feature. This is a coffin for Windows to lie in. BIOS environments are just inadequate in general, and supremely ill equipped in particular for what you want to accomplish. Consider using SeaBIOS exclusively for what it was made; Windows coffin. Consider another payload before (time wise) SeaBIOS to provide the menu. > Even if I put the initrd inside the kernel, that can't be loaded by > SeaBIOS unless the whole thing is an ELF file, right? I guess so. The true-to-form BIOS way would probably be to put FreeDOS, loadlin.exe, kernel and initramfs into a disk image. So please don't do that. If you really want to, please be rational: Ask yourself why you want to first start the wrong OS in order to then start the right OS. > How would that step go (vmlinuz -> ELF)? I'd recommend to study what coreboot does. It's not trivial, but also not super complicated. The key point is that Linux needs a loader stub (code and data) to be generated. It's not possible to just jump right into the kernel and have it start. Unfortunately. //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: Custom-sized, large floppy images?
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 and appreciate. But it's important to still choose battles wisely, and I think this particular battle is better won by asymmetry; don't bother trying to play by the rules of the CHS game - instead play another game, or even change the game, to make the rules fit you. Ideally you will move beyond BIOS and interrupt services. (Not to UEFI.) But at the very least focus on LBA instead of CHS. Please. Thank you. //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
[SeaBIOS] Re: Custom-sized, large floppy images?
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_INITRAMFS_SOURCE. Then use that kernel as payload. This page may be useful: https://www.coreboot.org/Payloads#Linux Note that using Linux as payload was the very origin of coreboot. This may also be useful, though AFAIK nobody has confirmed that it works: https://www.coreboot.org/Initramfs //Peter ___ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-le...@seabios.org
Re: [SeaBIOS] [PATCH] pretty boot menu entry for cdrom drives
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Ignore sgabios rom in case sercon is enabled.
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 &&
> +CONFIG_SERCON && romfile_loadint("etc/sercon-port", 0)) {
> +dprintf(1, "sercon: is enabled, not loading sgabios rom.\n");
> +continue;
> +}
This heuristic isn't very reliable. Is there nothing in the sgabios.bin
option ROM itself that can be used instead?
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
https://mail.coreboot.org/mailman/listinfo/seabios
Re: [SeaBIOS] [coreboot] How does SeaBIOS transition to Linux?
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 services, including option ROM processing and the BBS. > Where I see e820 table which is to be passed to OS, in order OS to > understand what memory it can use. But I did not find explicitly these > 5 functions. So I need a little help here. Where are these functions? I don't really know what you are refering to, but it doesn't matter.. > Now... How GRUB2 replaces all of these functionalities? It doesn't and is not supposed to. It is only used to load the operating system, not to create a BIOS environment. If you need a legacy BIOS or UEFI then you do not use GRUB2 as (only) payload. > who/what entity is replacing missing SeaBIOS functionalities? None. With GRUB2 as payload, no legacy BIOS environment is present, and that's a good thing. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org https://www.coreboot.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v2 00/12] Guest startup time optimization
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 has improved since then. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org https://www.coreboot.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS security feature roadmap?
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 basic research to find it, which makes it very difficult for anyone to take your effort seriously. Please move along. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] pci: panic when out of bus numbers
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 SeaBIOS to discard invalid requests and boot anyway. >> In case it isn't I think qemu should throw an error instead if you try >> to create a vm with more than 255 pci busses. > > I suppose it could go into QEMU too, I'll give it a try. Please do, I think the check should be in both places. I think QEMU should throw an error if the user requests an invalid hardware configuration. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH] SeaBios: Fix reset procedure reentrancy problem on qemu-kvm platform
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
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 guess the implementaiton and how things like CONFIG_THREADS=n are > handled would determine that. .. by the time the menu is shown and/or SeaBIOS boots automatically there is only one thread running anyway, right? (Or is this where I am missing something?) Thanks //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
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 > shows up. > > I don't have a good way to fix that. Would checking the connection status for each device after all devices have been registered be able to filter the USB2 device out? //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
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 then maybe first register internally during probing, then filter disconnected devices out, *then* register "for real" ? //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 3/3] tpm: Add a menu for TPM configuration
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't help but think that it would be significantly more useful to
> > turn the "goto err_exit" into a macro everywhere. Something like:
> >
> > #define malfunc_err_exit() do { \
> > dprintf(DEBUG_tcg, "TCGBIOS: TPM malfunctioning (line %d).\n", __LINE__);
> > \
> > goto err_exit; \
> > } while (0)
> >
> > ..so that the line number of the actual problem is output.
>
> I find goto's out of macros to be confusing, so would prefer to
> avoid that.
Fine, there are other ways to accomplish the same thing.
> If there is a desire to shrink the number of error messages
There is a desire to make error messages more useful.
The original patch outputs the line number at the error label, ie.
always the same line number for a function, regardless of what caused
the error.
My suggestion instead outputs the line number at/before the goto. I
should also have added %s __func__ there.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 3/3] tpm: Add a menu for TPM configuration
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 would be significantly more useful to
turn the "goto err_exit" into a macro everywhere. Something like:
#define malfunc_err_exit() do { \
dprintf(DEBUG_tcg, "TCGBIOS: TPM malfunctioning (line %d).\n", __LINE__); \
goto err_exit; \
} while (0)
..so that the line number of the actual problem is output.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 3/3] tpm: Add a menu for TPM configuration
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",
> +*returnCode);
Maybe simplify this to one string with %s + enable ? "Enable" : "Disable" ?
> +err_exit:
> +if (enable)
> +dprintf(DEBUG_tcg, "TCGBIOS: Enabling the TPM failed.\n");
> +else
> +dprintf(DEBUG_tcg, "TCGBIOS: Disabling the TPM failed.\n");
Same here.
> +dprintf(DEBUG_tcg, "TCGBIOS: TPM malfunctioning (line %d).\n", __LINE__);
See last email. This dprintf() seems a bit redundant with the error
in the lines above.
> +if (pf.flags[PERM_FLAG_IDX_DISABLE]) {
> +if (verbose)
> +printf("TPM must first be enable.\n");
Typo: enabled
> +tpm_process_cfg(const tpm_bios_cfg *cfg, int verbose, u32 *returnCode)
..
> +if (rc)
> +printf("Op %d: An error occurred: 0x%x TPM return code: 0x%x\n",
> + cfg->op, rc, *returnCode);
Maybe add a %s __func__ or some word about where this happened.
> +show_tpm_menu(int state, int next_scancodes[7])
Are scancodes really 32-bit? If you use a fixed size that's
presumably to save a bit of memory. I would prefer next_scancodes to
be dynamically sized according to some number of possible scancodes
in an enum or somesuch which is known at compile time, and for it to
be an array of unsigned char/uint8_t or uint16_t, as appropriate for
the hardware. IIRC scancodes are 8 bit?
> +if (state & TPM_STATE_ENABLED)
> +printf(" Enabled");
> +else
> +printf(" Disabled");
I'd use %s ? : for these but that's a matter of taste.
> +void
> +tpm_menu(void)
> +{
..
> +printf("The Trusted Platform Module (TPM) is a hardware device in "
> + "this machine.\n"
This is not universally true. I believe that the ME implements TPM in
software on recent platforms.
In this patch there is also an msleep(2000) call. Please avoid adding
unneccessary delays to the code.
Thanks!
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 4/7] tpm: Open code tpm_ipl() into callers
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
Re: [SeaBIOS] [coreboot] [ANNOUNCE] SeaBIOS 1.9.0
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/seabios
Re: [SeaBIOS] : USB 3.0 port failed if a USB 3.0 device is attached when power up (Summary: not final fixed yet)
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
Re: [SeaBIOS] Reducing SeaBIOS kernel entry time
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 project instead, that way you can also draw on the significant experience within that project. If you want to optimize for the Linux special case then you should not be using anything BIOS-related at all. Try coreboot with kernel as payload. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 1/2] vgabios: Add config option for assembler fixups
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 instruction works. Isn't the logic backwards here? Very nice work on this patchset! :) //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 1/2] vgabios: Add config option for assembler fixups
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 instruction works. Isn't the logic backwards here? Are you pointing out the trap only being enabled when CONFIG_VGA_FIXUP_ASM is on? Right. The trap is only useful if doing asm fixups Isn't that backwards? The trap is most important if *not* doing fixups? (Because then the generated binary may have known problems. Trapping them in that case would be nice.) as some x86emu versions do support leal, but will silently crash on other instructions (such as calll). In case the trap is important also when doing fixups, why not just always enable it? I only expect CONFIG_VGA_FIXUP_ASM to be off for those debugging something. If you say so.. But the always-on trap was helpful in this case. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] FreeBSD VESA console not working with SeaBIOS
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 that triggers the fault. In src/romlayout.S lea is used in two places to bump esp before calls. If those code paths are used also by SeaVGABIOS then maybe they could be rewritten with simpler instructions? //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 1/2] Add an option to only execute option ROMs contained in CBFS
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 appealing more and more to me. It's a good way to know that the system will stay as it was when flashed. Runtime setting - the argument there would be that if someone can change the flash contents to create a new CBFS file they could also replace the SeaBIOS payload, right? It is sortof true, but it *is* slightly easier to write data into erased flash than to erase existing and then write something new. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Add option to only execute CBFS option ROMs
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 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 instead is probably very quick. Pretty please? :) (Ultimately Kevin will decide, but maybe he also likes a blacklist.) The proposed patch also allows the user to have a completely blob-free system if desired. More general wins over fan(boy|girl) idealistic every time with me. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Add option to only execute CBFS option ROMs
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 instead is probably very quick. Pretty please? :) (Ultimately Kevin will decide, but maybe he also likes a blacklist.) I can try. I am nowhere near as familiar with SeaBIOS as I am with coreboot so this might take longer than expected. Fair enough! I think there will be a lot of reusable code in SeaBIOS already. For accessing a CBFS file try: git grep romfile_loadfile For parsing file into a string array see loadBootOrder() in src/boot.c. (Not so pretty, basically open-coding strtok(), but gets the job done.) The proposed patch also allows the user to have a completely blob-free system if desired. More general wins over fan(boy|girl) idealistic every time with me. There are reasons to want a blob-free system, including security. Agreed. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Add option to only execute CBFS option ROMs
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] build: remove hardcoded timestamp
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). During development cycles, it helps verify that test runs are executed with the expected code. 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. It should be possible to force a static version with make VERSION='xyz', but I'd ask that that not be done for production builds as it makes handling trouble reports harder. I would recommend to use `git describe --tags --dirty` output, which tells if there are any local modifications. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] build: remove hardcoded timestamp
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 found though, and that's a much harder problem. Do you mean code generation? Reproducible builds are created using the same particular compiler version everywhere. I recommend this presentation for more information: https://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-_saal_g_-_201412271400_-_reproducible_builds_-_mike_perry_-_seth_schoen_-_hans_steiner.html For direct video download links: https://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-_saal_g_-_201412271400_-_reproducible_builds_-_mike_perry_-_seth_schoen_-_hans_steiner.html#download It should be possible to force a static version with make VERSION='xyz', but I'd ask that that not be done for production builds as it makes handling trouble reports harder. I would recommend to use `git describe --tags --dirty` output, which tells if there are any local modifications. git describe is already there - see my recent email to Ian. It's important that there's nothing additional in the string that changes depending on transient things outside of the source code. I.e. it needs to be nothing but describe output, and I think it would be nice if it were the default, so as to support reproducible builds out of the box. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] vgabios - seabios breaks (my) 16-bit applications
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 VGA BIOS write its data? //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] vgabios - seabios breaks (my) 16-bit applications
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
Re: [SeaBIOS] Is it possible to implement a virtual CD drive in SeaBIOS and boot computer from an ISO image?
刘俊峰 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. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] new tag request for seabios
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 change your code to reference the commit with the fix instead of the tag you are currently using. Unrelated to using a commit id maybe someone will add a tag. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] No graphics with QEMU, coreboot, SeaBIOS und SeaVGABIOS
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 initialized it. Does coreboot successfully initialize the graphics? If not, start working on that instead. //Peter pgpneHv9YI5nR.pgp Description: PGP signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [coreboot] [solved] i945: AHCI timeout with Crucial m4 SSD 2.5 in SeaBIOS on cold boot
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.pgp Description: PGP signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [coreboot] i945: AHCI timeout with Crucial m4 SSD 2.5 in SeaBIOS on cold boot
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 initialized correctly. That's probably an SSD firmware bug. //Peter pgpj7Wz54FRnw.pgp Description: PGP signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] vgabios: Make the qemu vgabioses selectable when building for coreboot.
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
Re: [SeaBIOS] [PATCH] vgabios: Make the qemu vgabioses selectable when building for coreboot.
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 into two separate projects? //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] vgabios: Make the qemu vgabioses selectable when building for coreboot.
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 needing to reconfigure in between? It does make sense to me to have two repos for what seems to be two mostly different codebases resulting in very different binaries. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 2/2] Allow using full io region on q35
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 (sum pci_io_low_end - 0x1000) {
/* use the larger region at 0x1000 */
r_io-base = 0x1000;
} else {
-/*
- * Not enougth io address space - error out.
- *
- * TODO: on q35 we can move PORT_ACPI_PM_BASE out of
- * the way, then use the whole 1000 - region.
- */
+/* Not enougth io address space - error out. */
Typo here ---^
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Experiences with link time optimization?
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 (not very) and on the code it is asked to optimize... //Peter pgpRmQr7L9OrF.pgp Description: PGP signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 0/7] vgabios improvements
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. But especially if you are touching the command register anyway, SeaBIOS should perhaps not. That's not so clear to me however. :) //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [coreboot] SeaVGABIOS with native vga init (Need testers)
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 developers reviewed and finally submitted, without spotting bugs present in some commits and with talking to me, will be reverted because they're nowhere near ready for inclusion in the repository. There is a lot more work required for us to have a maintainable implementation of native graphics init for i945 platforms. We'll get there eventually, but the code that many people consider works is an incredibly fragile proof of concept at very best. //Peter pgpsT517z4zSD.pgp Description: PGP signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [coreboot] Setting up build environment
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 /home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.off Traceback (most recent call last): File ./tools/acpi_extract.py, line 221, in module for line in fileinput.input(): File /usr/lib/python2.7/fileinput.py, line 252, in next line = self.readline() File /usr/lib/python2.7/fileinput.py, line 344, in readline self._file = open(self._filename, self._mode) IOError: [Errno 2] No such file or directory: '/home/idwer/tmp/coreboot.fresh/build/seabios/out/acpi-dsdt.lst' The path isn't mangled in any way so the problem must be a dependency in the Makefile. Perhaps there's a pattern substitution which doesn't do greedy patterh matching where that's what would be needed. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 2/2] vgabios: Limit the range of the VBE number of pages parameter.
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://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
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 to the hardware, and is very much an integral part of all hardware, to the point where the firmware is one of the most prominent downloads made available by all hardware vendors. Don't make the mistake of thinking that firmware for a virtual machine has less to do with the machine just because it's virtual. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] What's the impact of enlarging IDE_TIMEOUT ?
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
Re: [SeaBIOS] KVM call agenda for 2013-05-28
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 lot like coreboot. qvmloader could be committed into the QEMU repo and maintained there. If QEMU really doesn't want anything besides quacking like a PC with BIOS or UEFI (such as quacking like a PC *without* a particular firmware) it makes perfect sense to me to put the complete firmware code into the QEMU repo and never reuse anything else. After all, that's how the proprietary firmware products are managed. Jordan Justen wrote: Why is updating the ACPI tables in seabios viewed as such a burden? I don't know about burden but to me it just doesn't make any sense to generate ACPI in one component (SeaBIOS) based on configuration for another component (QEMU). ACPI bytes are obviously a function of QEMU configuration. QEMU configuration can be changed through a great many channels, so it makes sense to me that QEMU itself would take care of generating correct ACPI, rather than exporting it's own data structures and pushing the ACPI problem onto the firmware, especially considering the desire for multiple independent firmware implementations. There's some code for dynamic ACPI generation in coreboot already, maybe that can be reused in QEMU to save some effort.. On the flip side, why is moving the ACPI tables to QEMU such an issue? Maybe because it is such a steaming pile that even the place where it belongs doesn't really want it.. I think overall I prefer the tables being built in the firmware, despite the extra thrash. That doesn't make sense to me. :\ Keep in mind: there is firmware and there is firmware.. Some things, such as the addresses where devices are configured at are re-programmable in QEMU, so a firmware can decide to use a different address, and thus invalidate the address qvmloader had set in the tables. ..there is now talk about a first-stage firmware (qvmloader) which does only hardware init, and then jumps into a second-stage firmware (SeaBIOS) which starts the operating system. I don't expect that anyone would argue for the second-stage firmware to generate ACPI tables if the first-stage firmware would be shared across different second-stage implementations. The above is by the way *exactly* the model coreboot uses since 14 years. Please make an ernest effort to *look into and try to reuse* what *is already there* .. The fear of coreboot is truly amazing. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v3] config: allow DEBUG_IO for !QEMU
Gerd Hoffmann wrote: Allow selecting DEBUG_IO for non-qemu configurations, which is useful when running coreboot+seabios on qemu. [ v2: QEMU_HARDWARE is even better as DEBUG_IO default value ] [ v3: make QEMU_HARDWARE usage consistent with other config options, fix spellings in commit 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
Re: [SeaBIOS] How to modify qemu-kvm bios.bin?
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 there are no options to enter e.g. a splash filename then probably there is no support. SeaBIOS also runs only for a rather short time, so splash support is not very meaningful. I think it would barely be noticeable when the VM starts. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] src/Kconfig: Add note that boot interface is needed
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: PGP signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] src/Kconfig: Add note that boot interface is needed
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 Description: PGP signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] VGA Option ROM not set up correctly when loaded by coreboot and not SeaBIOS
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 and/or code should be improved, so that no assumption is needed. not that Linux does not find the ROM at all. If that is a known issue, a note should be added to the Kconfig description It's quite natural since coreboot is not equipped to run option ROMs; it does not have any BIOS interrupt services, which option ROMs typically rely on, since option ROMs are a BIOS concept. or if coreboot is chosen as a target, then the Option ROM option should be enabled automatically, right? Which option ROM option are you talking about? Please be specific, use the CONFIG_ name. And since discussion now covers both coreboot and SeaBIOS it helps further if you specify which project the particular option is in. There are use cases both for coreboot running option ROMs and SeaBIOS running option ROMs, regardless of how SeaBIOS was started. I tend to agree that coreboot should default to not run option ROMs, and possibly the SeaBIOS configuration generated by the coreboot build files should enable SeaBIOS running the option ROM in that case, but it's not trivial to find a way that makes sense for every case. Feel free to think about it and propose an improvement, it can probably be better than it is at the moment. //Peter pgpxtLDJoL80L.pgp Description: PGP signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] src/Kconfig: Add note that boot interface is needed
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@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] src/Kconfig: Add note that boot interface is needed
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 those are quite different, right? //Peter pgpeWjl5h3i5l.pgp Description: PGP signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] src/Kconfig: Add note that boot interface is needed
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 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 0/2][RFC] Reduce mptable code dependencies
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
Re: [SeaBIOS] [PATCHv2] acpi: make default DSDT optional
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. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [Qemu-stable] problems with freeBSD
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 they're by no means the only, or even best, methods. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [Qemu-stable] problems with freeBSD
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 system which although not used much does allow distributed testing. Maybe it could be replicated for SeaBIOS. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] problems with freeBSD
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 target, so I understand that it happens. For coreboot we recommend to build a vanilla toolchain using known good versions. We also have a script to do that. (The script is at util/crossgcc/buildgcc in the coreboot repo.) //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [coreboot] i915 status on x60.
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 list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
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 programming. That. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
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 hardware description from QEMU and use that either as input to a table generator, or even have the read data be the tables themselves. It might or might not be easier and/or make more sense to generate tables in coreboot rather than in QEMU - that's unclear so far. From the quick look it seems they do *not* generate the dsdt dynamically, only the other tables (simliar to seabios). So switching to coreboot probably doesn't help to remove the dsdt patching code we have in seabios. Is there something inherent to the AML generator code in coreboot which makes it suck for the purpose of also generating a DSDT? //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
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 complexity into coreboot makes sense: 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. 2. Having (many!) hypervisor-specific special cases in SeaBIOS seems wildly schizophrenic without bringing any significant benefits, compared to factoring all of that out into a codebase which *already does many of the needed things*. I understand that noone really cares about those arguments as long as I don't do their work for them, but I'm afraid I will not stop complaining as long as SeaBIOS grows with more and more stuff that has nothing to do with a BIOS environment but has to do with lower level platform init. Maybe someday someone will actually get the point.. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU
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. Yes, really. Virtual hardware can be reconfigured in ways which is impossible on real hardware. This is (party) where the complexity we have in seabios wrt. acpi comes from. Yes. And the more flexibility is required the more complex the code gets. It sounds like there will soon be need for a more generic PCI resource allocator, which is another thing that coreboot already has. 2. Having (many!) hypervisor-specific special cases in SeaBIOS seems wildly schizophrenic without bringing any significant benefits, compared to factoring all of that out into a codebase which *already does many of the needed things*. It's a tradeoff. On one hand letting coreboot handle hardware initialialization would reduce the amout of code in seabios we have to maintain. On the other hand adding coreboot as middle man between qemu and seabios would add some complexity to the whole mix. What complexities have you run into? coreboot can of course be improved further, but as you may know SeaBIOS gets built by default by the coreboot build process already, so using coreboot wouldn't even add extra steps for a manual build. I'm not convinced using coreboot is a clear win, especially with EFI coming. Can coreboot run tianocore as payload? Work is ongoing to make edk2 a good coreboot payload. It already works for some values of works, but more work is needed. Progress has been fast the last month or so, thanks to efforts by David and Patrick Georgi. ACPI not working at all in linux guests when using coreboot with seabios payload doesn't exactly encourage exploring that option btw. Then the way the QEMU mainboard does ACPI in coreboot needs fixing, which is quite possible because I don't know if someone has actually implemented ACPI at all for QEMU, and if so it is not likely using the more modern facilities but likely to have static ASL. The point is not what is already there, the point is that adding this stuff into SeaBIOS or QEMU for that matter would mean re-inventing *yet another* wheel which is *already* finished in coreboot. but I'm afraid I will not stop complaining as long as SeaBIOS grows with more and more stuff that has nothing to do with a BIOS environment but has to do with lower level platform init. Well, *this* discussion is about moving stuff *out* of seabios. Good point, but it seems to be about moving stuff into each respective hypervisor, when in fact much of that code could probably be common in coreboot without significant effort. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [edk2] (PAM stuff) reset doesn't work on OVMF + SeaBIOS CSM
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 pgpMQ0HWnQzGc.pgp Description: PGP signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 0/5][RFC] Simultaneous multi-platform support
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 http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Problems booting FreeBSD9 under SeaBIOS as CSM
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 SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Next release
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 communicate directly with the hardware and overwrite whatever sectors it wants. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Next release
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 != PCI_DEVICE_ID_LSI_SAS1078 || -pci-device != PCI_DEVICE_ID_LSI_SAS1078DE || -pci-device != PCI_DEVICE_ID_LSI_SAS2108 || -pci-device != PCI_DEVICE_ID_LSI_SAS2108E || -pci-device != PCI_DEVICE_ID_LSI_SAS2004 || -pci-device != PCI_DEVICE_ID_LSI_SAS2008 || -pci-device != PCI_DEVICE_ID_LSI_VERDE_ZCR || -pci-device != PCI_DEVICE_ID_DELL_PERC5 || -pci-device != PCI_DEVICE_ID_LSI_SAS2208 || -pci-device != PCI_DEVICE_ID_LSI_SAS3108) -continue; -init_megasas(pci); +if (pci-device == PCI_DEVICE_ID_LSI_SAS1064R || +pci-device == PCI_DEVICE_ID_LSI_SAS1078 || +pci-device == PCI_DEVICE_ID_LSI_SAS1078DE || +pci-device == PCI_DEVICE_ID_LSI_SAS2108 || +pci-device == PCI_DEVICE_ID_LSI_SAS2108E || +pci-device == PCI_DEVICE_ID_LSI_SAS2004 || +pci-device == PCI_DEVICE_ID_LSI_SAS2008 || +pci-device == PCI_DEVICE_ID_LSI_VERDE_ZCR || +pci-device == PCI_DEVICE_ID_DELL_PERC5 || +pci-device == PCI_DEVICE_ID_LSI_SAS2208 || +pci-device == PCI_DEVICE_ID_LSI_SAS3108) +init_megasas(pci); } switch () would be nice. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] SEABIOS and DOS compatibility
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 help if you could do that. I just mentioned them as they are DOS 6.22 bootdisks, which was mentioned. So I assumed they would be useful for reproducing the problem. Unfortunately assumptions aren't helpful. Kevin already mentioned that the 6.22 he has doesn't show the problem. It would be great if you can help create a testcase! //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [coreboot] USB Problems geode lx800
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
Re: [SeaBIOS] great things are coming your way :-)
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 didn't expect the regression caused by:
commit eb129bbcb654d90c331b7898222d64f769c08437
Author: Patrick Georgi patr...@georgi-clan.de
Date: Wed May 9 21:07:17 2012 +0200
Update SeaBIOS URL
We have a http accessible SeaBIOS mirror at review.coreboot.org.
Use it.
Apparently our http accessible SeaBIOS mirror isn't getting updated,
so the SeaBIOS 1.7.1 release does not exist in what gets cloned.
If the above commit is reverted:
git revert eb129bbcb654d90c331b7898222d64f769c08437
..and the build/seabios directory is deleted, then the build will
work again. I am not sure that this is the right fix however.
I would prefer to have a reliable HTTP URL rather than reverting.
Here is an nginx snippet that allows to serve git http: from the
same virtual host as a gitweb:
location ~* ^/[^/]*\.git {
alias /usr/libexec/git-core/git-http-backend;
include /etc/nginx/fastcgi_params;
fastcgi_param DOCUMENT_ROOT /var/lib/git;
fastcgi_param GIT_PROJECT_ROOT /var/lib/git;
fastcgi_pass
unix:/var/run/spawn-fcgi/git-http;
}
And here's the fcgiwrap start script, to create that FastCGI socket.
All goes on one line of course.
#!/bin/sh
exec spawn-fcgi -n -s /var/run/spawn-fcgi/git-http -u gitweb -U nginx
-d /var/lib/git -f /usr/bin/fcgiwrap
Maybe it can help make direct HTTP access available for the actual
repository. Please let's not mess with mirroring. If nginx+fastcgi
does not fit the current hosting then I guess it will be Apache or
lighttpd, in which case the interwebs should have some snippets
equivalent to the above.
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] add F11 shortcut for network boot
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 (pos-type IPL_TYPE_CBFS)
+break;
+}
+
+printf(Press %sF12 for boot menu.\n\n
+ , pos ? F11 for network boot, or : );
This printf is not the prettiest code I've seen. Maybe there is a
nicer way to accomplish the same output?
-if (scan_code != 0x86)
+if (scan_code != 0x86 (scan_code != 0x85 || !pos))
/* not F12 */
return;
Did you read the comment? After your change the comment is extremely
confusing. Why don't you also change the comment when you change the
code.
+if (scan_code == 0x85) {
How about using switch() ?
+// Prioritize BEV/BCV entries
+struct bootentry_s **pprev = BootList, **pprev_new = BootList;
+while ((pos = *pprev) != NULL) {
+if (pos-type IPL_TYPE_CBFS) {
+*pprev = pos-next;
+pos-next = *pprev_new;
+*pprev_new = pos;
+pos-priority = 0;
+pprev_new = pos-next;
+} else {
+pprev = pos-next;
+}
+}
The above could be written as a very nice and readable for () loop
instead. Handle the uninteresting case with continue.
+// Get key press
+for (;;) {
+scan_code = get_keystroke(1000);
+if (scan_code = 1 scan_code = maxmenu+1)
+break;
+}
+printf(\n);
+if (scan_code == 0x01)
+// ESC
+return;
Maybe it's time to refactor some of this code at this point, instead
of copypasting it.
Thanks
//Peter
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] great things are coming your way :-)
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 error: Your local changes to the following files would be overwritten by checkout: src/acpi-dsdt.hex Please, commit your changes or stash them before you can switch branches. Aborting fatal: A branch named 'coreboot' already exists. make[1]: *** [checkout] Error 128 make: *** [seabios] Error 2 I've seen this happen. The coreboot Makefile stuff that builds SeaBIOS assumes that there are never uncommitted changes in the SeaBIOS directory, and you get the above error when there are. It is easy to forcefully overwrite any uncommitted changes in the SeaBIOS build directory, but I am not sure if we want to do that. I would very much appreciate an explanation why the src/acpi-dsdt.hex file gets modified as part of the build. It is in the src/ directory, but .hex does not suggest that it is in a source format? It's confusing why it has been added to the repo if it is not a source file. Can someone explain, so that we can fix the build commands? Thanks! //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] great things are coming your way :-)
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 is really sane. I need to know why the file is being modified during SeaBIOS build. I tend to think that it should just be removed from the SeaBIOS repository, then the error goes away, and users' modifications will not silently be deleted by building coreboot. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] great things are coming your way :-)
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 the src/acpi-dsdt.hex file gets modified as part of the build. It no longer does. The ACPI file is now generated on each build. This should be in the v1.7.1 release - maybe you're on an old version? coreboot has SeaBIOS stable at commit a0263083cb4cda172832fbc916dc1417ee930574 which is by now rather old. Would you suggest bumping what coreboot uses as stable commit to 1.7.1? //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] great things are coming your way :-)
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 http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] VideoBios question
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 http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] How much RAM is required?
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 of RAM. Good point. I disagree actually. It is not an invalid point, but please optimize for the common case and let's deal with microscopic corner cases if they actually happen. Could SeaBIOS fail more cleanly when it detects insufficient RAM? What would you propose? //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] How much RAM is required?
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 PC-like machine with less than 1MB of memory. I don't believe one has ever existed. Don't know if its possible to make QEMU use an UEFI or OpenFirmware image instead, or if such an image exists. Sure, but UEFI rather requires 1GB than 1MB. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] UHCI on US15W: Crazy stuff happening
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 think it's what SeaBIOS is thinking it is... USB Keyboard is working. Woohoo! Yay! Please send a patch. It may not go in as-is, but it's a good help for looking deeper into the issue. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Stance on TPM?
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 http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] IEEE 1394 interface booting
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 mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
