Hello Kevin,
I hooked up an external USB 3.0 WD hard drive and found that this wasn't supported by SeaBIOS as this used 4K blocks.
Do you have plans to support this in the future in some way? Or will this simply be incompatible without plans for support. (This isn't a problem but it's good to know what the plans are).
I haven't seen any devices like that - I was under the impression the 4K drives emulated 512 byte blocks. It should be possible to support them though. Can you send an email to the mailing list (and include a debug log)?
BR, Wim
I was originally planning for a 1.9.0 release on Nov 6th. However, a
couple of issues were raised this past week (python2.7 dependency in
buildversion.py, USB3 failures, reboot race condition). As a result,
I think we should push back the release a week (target Nov 16th).
Here are my draft release notes for 1.9.0:
* The default boot menu key is now the ESC key (instead of F12)
* Initial support for Trusted Platform Module (TPM) hardware and BIOS calls
* Initial support for chain loading SeaBIOS from Grub (via multiboot
support)
* virtio 1.0 device support
* The build will no longer include the build hostname or build time on
"clean" builds. This makes the build binaries more "reproducible".
* SeaVGABIOS improvements:
* Improved support for old versions of x86emu (the "leal"
instruction is now emulated)
* Several bug fixes and code cleanups
Comments?
-Kevin
This series enables seabios to run on some Baytrail CPU based
chromebooks. At least some of these machines do not support routing
of legacy interrupts and at least some have SDHCI controllers that do
not appear as regular PCI devices. This series is mainly a hack to
get some minimal support on the hardware.
This series is also available at:
https://github.com/KevinOConnor/seabios/tree/baytrail-testing
-Kevin
Kevin O'Connor (3):
Add minimal support for machines without hardware interrupts
ps2: Eliminate "etc/ps2-poll-only"; use CONFIG_HARDWARE_IRQ instead
sdcard: Allow sdcard addresses to be specified in CBFS files
docs/Runtime_config.md | 2 +-
src/Kconfig | 13 ++++++++++++-
src/clock.c | 31 +++++++++++++++++++++++++------
src/hw/pic.c | 14 ++++++++++++++
src/hw/pic.h | 4 ++++
src/hw/ps2port.c | 16 ++++++----------
src/hw/sdcard.c | 48 ++++++++++++++++++++++++++++++++++++------------
src/hw/timer.c | 2 ++
src/stacks.c | 5 ++++-
src/util.h | 1 +
10 files changed, 105 insertions(+), 31 deletions(-)
--
1.9.3
Ccing Seabios community.
On 2015/11/3 14:58, Xulei (Stone, Euler) wrote:
> On qemu-kvm platform, when I reset a VM through "virsh reset", and coincidently
> the VM is in process of internal rebooting at the same time. Then the VM will
> not be successfully reseted any more due to the reset reentrancy. I found:
> (1)SeaBios try to shutdown the VM after reseting it failed by apm_shutdown().
> However, apm_shutdown() does not work on qemu-kvm platform;
> (2)I add 1s sleep in qemu_prep_reset(), then continuously reset the VM twice,
> aforementioned case must happen.
> This patch fixes this issue by letting the VM always execute the reboot
> routing while a reenrancy happenes instead of attempting apm_shutdown on
> qemu-kvm platform.
>
> Signed-off-by: Lei Xu <stone.xulei(a)huawei.com>
> ---
> roms/seabios/src/resume.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/roms/seabios/src/resume.c b/roms/seabios/src/resume.c
> index 1903174..96ff79e 100644
> --- a/roms/seabios/src/resume.c
> +++ b/roms/seabios/src/resume.c
> @@ -16,6 +16,7 @@
> #include "std/bda.h" // struct bios_data_area_s
> #include "string.h" // memset
> #include "util.h" // dma_setup
> +#include "fw/paravirt.h" //runningOnKVM
>
> // Handler for post calls that look like a resume.
> void VISIBLE16
> @@ -122,7 +123,11 @@ tryReboot(void)
> dprintf(1, "Unable to hard-reboot machine - attempting shutdown.\n");
> apm_shutdown();
> }
> - HaveAttemptedReboot = 1;
> + if (!runningOnKVM()) {
> + // Hard reboot has failed - try to shutdown machine.
> + HaveAttemptedReboot = 1;
> + }
> +
>
> dprintf(1, "Attempting a hard reboot\n");
>
> --
> 1.7.12.4
>
On Wed, Nov 04, 2015 at 07:40:12AM +0200, Kyösti Mälkki wrote:
> MMIO register space was off by 4 bytes, bottom bits of
> PCI BAR registers are not part of the address.
Thanks! I committed this patch.
-Kevin
Hi Simon,
On Mon, Oct 19, 2015 at 10:51 AM, Simon Glass <sjg(a)chromium.org> wrote:
> Hi Bin,
>
> On 10 October 2015 at 02:57, Bin Meng <bmeng.cn(a)gmail.com> wrote:
>> Hi Simon,
>>
>> On Sat, Oct 3, 2015 at 10:29 PM, Simon Glass <sjg(a)chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 29 September 2015 at 11:17, Bin Meng <bmeng.cn(a)gmail.com> wrote:
>>>> SeaBIOS is an open source implementation of a 16-bit X86 BIOS.
>>>> It can run in an emulator or natively on X86 hardware with the
>>>> use of coreboot. With SeaBIOS's help, we can boot some OSes
>>>> that require 16-bit BIOS services like Windows/DOS.
>>>>
>>>> As U-Boot, we have to manually create a table where SeaBIOS gets
>>>> system information (eg: E820) from. The table unfortunately has
>>>> to follow the coreboot table format as SeaBIOS currently supports
>>>> booting as a coreboot payload. No U-Boot native support there.
>>>>
>>>> Booting SeaBIOS is done via U-Boot's bootelf command.
>>>>
>>>> This is the initial attempt to support booting SeaBIOS from U-Boot.
>>>> If the basic concept is good, I can spend time working on follow-on
>>>> patches to enable BIOS tables as well as graphics support. One issue
>>>> is that U-Boot x86 does not has a ROM file system like coreboot.
>>>> This brings difficulities to pass PCI option ROM to SeaBIOS, if we
>>>> don't modify SeaBIOS's source codes. Maybe we should promote CBFS
>>>> in U-Boot x86?
>>>>
>>>> This is tested on an Intel Crown Bay board with VGA card, booting
>>>> SeaBIOS then chain loading a GRUB on a USB drive, then Linux kernel
>>>> finally.
>>>
>>> Looks good to me. I think it is OK to use CBFS if needed - are you
>>> thinking of an option to build u-boot.rom as a CBFS filesystem?
>>
>> If using CBFS, that means we may have to abandon ifdtool? Or maybe
>> mixed usage of both tools?
>
> So far I'm not sure of the best approach. At present we have the ROM
> offsets stored mostly in Kconfig, with the MRC area in the SPI flash
> device tree node. The environment is also in Kconfig.
>
> What sort of option ROMs do you want to support? What other options
> does seabios provide?
>
I believe SeaBIOS can run any kind of PCI option ROMs, but I have
never tested other than vgabios. Also per coreboot's documentation,
booting Windows needs SeaBIOS.
> What does SEA stand for?
I guess it's because most of SeaBIOS's source codes are written in
'C', thus a 'C' BIOS.
Regards,
Bin
