Hi SeaBios,
Since almost all OS distributions are released as ISO images, either setup CD or Live CD. Normally we need to burn the ISO image to optical disk or USB disk, but CD drives are die out and USB disk may not be compatible for a successful boot up. It will be extremely good if user can boot computer from any of these CD images with great ease. I know GRUB can load an ISO file, but once the OS on it takes over the CPU the CD no longer exists, you know, this have many restrictions . What we want is a virtual CD drive comparable to that provided by a virtual machine software(e.g. VirtualBox). So I wonder whether a virtual CD drive implemented at BIOS level can persist even after OS is boot up?
Thanks,
Junfeng
The series fixes some issues when more than one root primary bus is present.
First patch scans all the bus range to find the extra root buses.
Second patch extends memory and IO mapping for found buses.
Marcel Apfelbaum (2):
fw/pci: scan all buses if extraroots romfile is present
fw/pci: map memory and IO regions for multiple pci root buses
src/fw/pciinit.c | 123 +++++++++++++++++++++++++++++++++++++++----------------
1 file changed, 88 insertions(+), 35 deletions(-)
--
1.9.3
On Fri, Nov 21, 2014 at 08:03:29PM +0000, Pandey, Sunil K wrote:
> > Is this the only thing preventing compilation on the Intel compiler?
> Yes, this is the only problem for Intel compiler.
>
> I can directly use from git checkout but issue is, SeaBios is
> indirectly included in many other open source applications which is
> based on SeaBios release tag. Anytime, when I try to compile other
> open source applications (i.e. Xen), indirectly it try to compile
> SeaBios and Intel Compiler fail because of this issue.
Okay. We're likely a couple of months out from the next major
release. It may be a candidate for the stable branch, which Gerd
maintains.
Can you confirm the patch below on top of rel-1.7.5.1 fixes the issue
for you?
-Kevin
--- a/scripts/layoutrom.py
+++ b/scripts/layoutrom.py
@@ -175,10 +175,7 @@ def doLayout(sections, config, genreloc):
# Determine 16bit positions
li.sections16 = getSectionsCategory(sections, '16')
textsections = getSectionsPrefix(li.sections16, '.text.')
- rodatasections = (
- getSectionsPrefix(li.sections16, '.rodata.str1.1')
- + getSectionsPrefix(li.sections16, '.rodata.__func__.')
- + getSectionsPrefix(li.sections16, '.rodata.__PRETTY_FUNCTION__.'))
+ rodatasections = getSectionsPrefix(li.sections16, '.rodata')
datasections = getSectionsPrefix(li.sections16, '.data16.')
fixedsections = getSectionsPrefix(li.sections16, '.fixedaddr.')
@@ -191,10 +188,7 @@ def doLayout(sections, config, genreloc):
# Determine 32seg positions
li.sections32seg = getSectionsCategory(sections, '32seg')
textsections = getSectionsPrefix(li.sections32seg, '.text.')
- rodatasections = (
- getSectionsPrefix(li.sections32seg, '.rodata.str1.1')
- + getSectionsPrefix(li.sections32seg, '.rodata.__func__.')
- + getSectionsPrefix(li.sections32seg, '.rodata.__PRETTY_FUNCTION__.'))
+ rodatasections = getSectionsPrefix(li.sections32seg, '.rodata')
datasections = getSectionsPrefix(li.sections32seg, '.data32seg.')
li.sec32seg_start, li.sec32seg_align = setSectionsStart(
On Fri, Nov 21, 2014 at 07:04:47PM +0000, Pandey, Sunil K wrote:
> Hi Kevin,
>
> Thanks for response. Following are specific change I'm talking
> about. Compilers are not expected to create .rodata.str1.1,
> .rodata.__func__ and .rodata.__PRETTY_FUNCTION__. If compiler
> decide to use some other .rodata__ suffix name in place of __func__,
> __PRETTY_FUNCTION__ or str1.1, it breaks the compilation.
>
> As you can see someone already taken out that check from SeaBios
> mainline, but 1.7.5.1 still has. As a result of this assumption,
> whenever I try to build SeaBios with Intel Compiler it Fail because
> Intel compiler uses some other character in place of
> __PRETTY_FUNCTION__ and __func__. It will be great if you can
> incorporate this fix in released version.
I made that change as part of commit e5749978. The change was part of
a feature enhancement (compiling with -fno-merge-constants).
Is this the only thing preventing compilation on the Intel compiler?
Typically a feature enhancement such as e5749978 would go into the
next release, and we're likely a month or so out from the next
release.
As Peter mentioned in another email, it should be possible to checkout
a git version using the hash instead of a tag name in the interim (eg,
"git checkout 9f505f71").
-Kevin
On Wed, Nov 12, 2014 at 09:20:22PM +0000, Pandey, Sunil K wrote:
> Hello,
>
> I'm looking for a fix in
> http://code.coreboot.org/p/seabios/source/tree/master/scripts/layoutrom.py
> file. Apparently 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.
>
> Can you please create a new tag from master so that I can use it in
> my project? I'm trying to compile seabios code with Intel compiler,
> but it keep failing because of layoutrom.py file __func__ check.
Can you post the error that you are seeing?
We just tagged rel-1.7.5.1 and it included all the build bug fixes
that I know of. There are changes to scripts/layoutrom.py between
rel-1.7.5.1 and the current master branch, but none of those changes
were thought to be bug fixes.
-Kevin
PS - please post in just plain text (no html) in the future.
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
According to Google
https://www.google.bg/?#q=most+popular+screen+resolution
most popular screen resolution since 2010 is 1366x786
despite 1366 is not dividable to 8.
And my laptop has it
http://support.lenovo.com/us/en/products/laptops-and-netbooks/ideapad-y-s...
Thanks
Божан
>-------- Оригинално писмо --------
>От: Michael Tokarev mjt(a)tls.msk.ru
>Относно: Re: [SeaBIOS] resolution 1366x768
>До: Bozhan Boiadzhiev <bozhan(a)abv.bg>, seabios(a)seabios.org
>Изпратено на: Понеделник, 2014, Ноември 17 14:07:15 EET
> 14.11.2014 15:24, Bozhan Boiadzhiev wrote:
> > Hi,
> > i have a laptop with resolution 1366x768 and SeaBIOS doesn't have such.
> > Please, if it is possible, someone who can, to add this resolution to vgasrc/bochsvga.c.
>
> It is not sufficient to just add that resolution to seabios list.
> I mean, it is not only bios which should have support for it.
>
> For example, qemu/kvm will not work with it.
>
> The problem here is that 1366 is not dividable by 8. In other words,
> each line on the screen does not end at a byte boundary in memory.
> This is a very weird resolution. Most devices which actually implement
> it use 1368x768 and just crop two vertical one-pixe-wide lines on both
> sides.
>
> > According to this page https://en.wikipedia.org/wiki/Display_resolution,
> > resolution 1366x768 is used by 26% from Web users,
> > based on stats from http://gs.statcounter.com/#resolution-ww-monthly-201401-201404-bar
>
> This does not look real. Being a very weird resolution, with very
> few devices available in stores all around, it can't be real.
>
> But even if it _is_ real, it does not make this resolution any
> less weird.
>
> Thanks,
>
> /mjt, who added it once to seabios (not a rocket science to add 3 lines
> to vgasrc.c) just to discover that qemu crashes once (windows)
> guest tries to switch to it
Hi,
I'm busy preparing a 1.7.5.1 stable release for seabios, to be released
within the next few days, so we can include it into the upcoming qemu
2.2 release.
Currently the 1.7.5-stable branch has these patches (git shortlog):
Hannes Reinecke (1):
megasas: read addional PCI I/O bar
Kevin O'Connor (5):
boot: Change ":rom%d" boot order rom instance to ":rom%x"
vgabios: Return from handle_1011() if handler found.
Don't enable thread preemption during S3 resume vga option rom
execution.
build: Avoid absolute paths during "whole-program" compiling.
ehci: Fix bug in hub port assignment
Marcel Apfelbaum (1):
hw/pci: reserve IO and mem for pci express downstream ports with
no devices attached
Markus Armbruster (1):
boot: Fix boot order for SCSI target, lun > 9
Anyone has requests / suggestions for additional patches being
cherry-picked from master?
cheers,
Gerd
