On Fri, Oct 02, 2009 at 12:36:06AM +0200, Rudolf Marek wrote:
Hello,
I made some fix for xmmstack.c found in SerialICE.
leal (%esp), %ecx
I was looking at xmmstack - it's a neat hack! However, as near as I
can tell, it only fixes up %esp references. If gcc were to copy %esp
to %ecx and
Joseph Smith wrote:
On 10/02/2009 08:37 AM, Stefan Reinauer wrote:
On Oct 2, 2009, at 4:11, Joseph Smith j...@settoplinux.org wrote:
[r...@smitty5m SerialICE-1.0]# make
Install a cross compiler from util/crossgcc or drop the cross
definitions from the Makefile
Ok after playing with the
Carl-Daniel,
It sounds like there is a whole lot of overlap in what coreboot and
tianocore are trying to enable.
The key difference is that tianocore is focused on enabling the UEFI
interfaces within platforms.
OS loaders in UEFI are UEFI applications, and therefore just like in
the case of the
On Fri, Oct 2, 2009 at 14:39, Carl-Daniel Hailfinger
c-d.hailfinger.devel.2...@gmx.net wrote:
[Adding the coreboot list to CC. Please ignore the moderation messages,
your addresses will be whitelisted ASAP.]
On 02.10.2009 20:53, Anthony Liguori wrote:
Carl-Daniel Hailfinger wrote:
Given that
Hi,
there were a couple of copies of vgabios.c that looked for the option
rom image at fixed addresses (usually begin of flash), which is not the
supported way of doing things anymore.
As this patch removes the non-CBFS capability, I'd commit it right after
the removal of non-CBFS support this
On Fri, Oct 02, 2009 at 11:39:50PM +0200, Carl-Daniel Hailfinger wrote:
I'll bite, what's the advantage of doing coreboot + SeaBIOS vs.
SeaBIOS alone? Forget about EFI for the moment, should be considering
switching to coreboot + SeaBIOS for 0.12?
Advantages:
- Code coverage increase:
Patrick Georgi wrote:
Hi,
there were a couple of copies of vgabios.c that looked for the option
rom image at fixed addresses (usually begin of flash), which is not the
supported way of doing things anymore.
As this patch removes the non-CBFS capability, I'd commit it right after
the
Author: uwe
Date: 2009-10-03 17:34:08 +0200 (Sat, 03 Oct 2009)
New Revision: 4711
Modified:
trunk/coreboot-v2/src/mainboard/a-trend/atc-6220/Kconfig
trunk/coreboot-v2/src/mainboard/a-trend/atc-6240/Kconfig
trunk/coreboot-v2/src/mainboard/abit/be6-ii_v2_0/Kconfig
Peter Stuge wrote:
ron minnich wrote:
Why is the port/directory named S1850 instead of 1850 though? Just to
have a letter as first character, or is the board _actually_ called
S1850? If so, do you have a more correct vendor website we can link to?
It say s1850 on the front I
ron minnich wrote:
BTW, THANKS for the note. I was hoping for a note from an expert :-)
That leading bytes sure looked like SPD but my obsolete JDEC docs threw me
off.
Now I wonder why I only see one SPD ... but that's grist for another
note in little bit.
Thanks
ron
What other
Carl-Daniel Hailfinger wrote:
On 02.10.2009 11:54, Patrick Georgi wrote:
We need to have access to CMOS before CAR or raminit, or anything
interesting happens, really. And I'm not sure if our code supports
this everywhere already.
IMHO access to CMOS before CAR is unnecessarily
On Sat, Oct 03, 2009 at 05:50:22PM +0200, Stefan Reinauer wrote:
This one?
http://gtk.no/images/bim/server/bim2.jpg
It could simply be that the board name can't be all numbers. I don't
know if we actually have that restriction?
what about renaming it to pe1850?
Or
Author: oxygene
Date: 2009-10-03 18:27:48 +0200 (Sat, 03 Oct 2009)
New Revision: 4713
Modified:
trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/realmode/vgabios.c
trunk/coreboot-v2/src/mainboard/via/epia-m/vgabios.c
trunk/coreboot-v2/src/northbridge/via/cn400/vgabios.c
Carl-Daniel Hailfinger wrote:
IMHO access to CMOS before CAR is unnecessarily painful
Why?
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Carl-Daniel Hailfinger wrote:
Given that flashrom already has a generic image layout feature, I
propose to have cbfstool spit out an image layout file which is
then read by flashrom. This makes flashrom independent of CBFS and
that's a good thing (think upgrade).
This is trivial to implement
Uwe Hermann wrote:
what about renaming it to pe1850?
Or poweredge_1850 if we're going to rename, so dirnames match the
actual board name.
pe is a quite familiar abbreviation for Dell servers, I'd prefer
that. But Ron said it's not the same machine as on the picture -
we should find out
On Thu, Oct 01, 2009 at 01:15:52PM +0200, Stefan Reinauer wrote:
Myles Watson wrote:
High Tables Base is 1fff.
Copying Interrupt Routing Table to 0x000f... done.
Copying Interrupt Routing Table to 0x1fff... done.
Wrote the mp table end at: 000f0410 - 000f0568
Wrote the mp
actually it's all meaningless in a sense. We have ten 1850s that have
utterly different motherboards than the other 128. They can't even
properly netboot as the other 128 do. They all look the same outside.
Vendor names on the outside tell you nothing about the inside.
ron
--
coreboot mailing
I'll poll the whole smbus monday. One problem is it doesn't seem to
work at all under factory bios -- Linux can't get to it. I expect the
BMC is, once again, getting in the way.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 03.10.2009 18:08, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 02.10.2009 11:54, Patrick Georgi wrote:
We need to have access to CMOS before CAR or raminit, or anything
interesting happens, really. And I'm not sure if our code supports
this everywhere already.
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI
coreboot payload based on the tianocore.org code.
I believe it might have been done already.
http://www.coreboot.org/File:Tianocoreboot.png
//Peter
--
coreboot mailing list: coreboot@coreboot.org
Hi Gleb,
Gleb Natapov wrote:
So for me real 440BX hardware support of coreboot is actually
disadvantage. QEMU don't have real 440BX hardware and there is not
point in having one. It is possible to implement 440BX-qemu support
in coreboot of course if there are other advantages worth having.
On 03.10.2009 18:34, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
IMHO access to CMOS before CAR is unnecessarily painful
Why?
Because you either introduce a dependency on ROMCC or you need
additional assembler code. mmxstack/xmmstack+GCC is not an option here
because a
I use qemu for a lot of coreboot work. I really depend on qemu for
many things I do, not just coreboot related. The qemu target in
coreboot has been very heavily used by us to test out new ideas.
That said, I don't see a compelling need to augment seabios with
coreboot on qemu *in the standard
Carl-Daniel Hailfinger wrote:
IMHO access to CMOS before CAR is unnecessarily painful
Why?
Because you either introduce a dependency on ROMCC or you need
additional assembler code.
I love Patrick's idea about generating macros from cmos.layout. With
that, the additional assembler code
On Sat, Oct 03, 2009 at 10:40:35AM -0700, ron minnich wrote:
I use qemu for a lot of coreboot work. I really depend on qemu for
many things I do, not just coreboot related. The qemu target in
coreboot has been very heavily used by us to test out new ideas.
That said, I don't see a compelling
[adding flash...@flashrom.org to CC]
On 03.10.2009 18:40, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
Given that flashrom already has a generic image layout feature, I
propose to have cbfstool spit out an image layout file which is
then read by flashrom. This makes flashrom
On 03.10.2009 19:15, Uwe Hermann wrote:
On Thu, Oct 01, 2009 at 01:15:52PM +0200, Stefan Reinauer wrote:
Myles Watson wrote:
High Tables Base is 1fff.
Copying Interrupt Routing Table to 0x000f... done.
Copying Interrupt Routing Table to 0x1fff... done.
Wrote the mp
ron minnich wrote:
actually it's all meaningless in a sense. We have ten 1850s that
have utterly different motherboards than the other 128. They can't
even properly netboot as the other 128 do. They all look the same
outside.
Ok, then it would be nice to find out more about the actual boards
Gleb Natapov wrote:
Exactly. I am glad to hear that coreboot has support for QEMU,
but seabios does the job already, so why add more layers?
If SeaBIOS does not need any code at all for QEMU machine init I
agree there's no point in considering coreboot.
If QEMU machine specific init is in fact
Am Samstag, den 03.10.2009, 20:03 +0200 schrieb Peter Stuge:
Because you either introduce a dependency on ROMCC or you need
additional assembler code.
I love Patrick's idea about generating macros from cmos.layout. With
that, the additional assembler code would amount to maybe 15
Patrick Georgi wrote:
What I don't know is, do we require any chipset setup to _reach_
CMOS?
It's not generally in the CPU, so some setup may be needed. On the
other hand, maybe 70/71 are decoded correctly on power up, just like
flash access?
//Peter
--
coreboot mailing list:
On Sat, Oct 03, 2009 at 08:30:30PM +0200, Peter Stuge wrote:
Gleb Natapov wrote:
Exactly. I am glad to hear that coreboot has support for QEMU,
but seabios does the job already, so why add more layers?
If SeaBIOS does not need any code at all for QEMU machine init I
agree there's no point
On Sat, Oct 03, 2009 at 08:30:30PM +0200, Peter Stuge wrote:
Gleb Natapov wrote:
Exactly. I am glad to hear that coreboot has support for QEMU,
but seabios does the job already, so why add more layers?
If SeaBIOS does not need any code at all for QEMU machine init I
agree there's no point
Hi,
attached patch moves the failover configuration symbols to a global
file, defined as bool, defaulting to false.
Given that Kconfig doesn't support failover, there hardly will be a
reason to enable it, and if there is, they can still be enabled as
needed.
Signed-off-by: Patrick Georgi
On Saturday 03 October 2009 22:29:32 Harald Gutmann wrote:
There is one Problem with the patch, but I'm not able to track that down.
I've really no idea what causes Kconfig to put all those warnings out with
my patch. As this patch causes quite a massive amount of warnings, and I
wasn't able
On Saturday 03 October 2009 22:29:32 Harald Gutmann wrote:
Hello,
here is my new patch which adds the Kconfig support for m57sli from
gigabyte.
The changes in devicetree.cb are just whitespace fixes and I removed some parts
Kind regards,
Harald
--
coreboot mailing list:
Patrick Georgi wrote:
attached patch moves the failover configuration symbols to a global
file, defined as bool, defaulting to false.
Given that Kconfig doesn't support failover, there hardly will be a
reason to enable it, and if there is, they can still be enabled as
needed.
Author: oxygene
Date: 2009-10-03 23:04:13 +0200 (Sat, 03 Oct 2009)
New Revision: 4714
Modified:
trunk/coreboot-v2/src/Kconfig
trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig
trunk/coreboot-v2/src/mainboard/dell/s1850/Kconfig
Am Samstag, den 03.10.2009, 22:55 +0200 schrieb Peter Stuge:
Acked-by: Peter Stuge pe...@stuge.se
Thanks, r4714
+config HAVE_FAILOVER_BOOT
+config USE_FAILOVER_IMAGE
Could we simplify to config FAILOVER or even further? Maybe something
to look into when implementing it for CBFS.
They are
Author: oxygene
Date: 2009-10-03 23:06:53 +0200 (Sat, 03 Oct 2009)
New Revision: 4715
Added:
trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Kconfig
trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Makefile.inc
Modified:
trunk/coreboot-v2/src/mainboard/gigabyte/Kconfig
Author: oxygene
Date: 2009-10-03 23:13:36 +0200 (Sat, 03 Oct 2009)
New Revision: 4716
Modified:
trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/Kconfig
Log:
Remove another FAILOVER variable. (trivial)
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Acked-by: Patrick Georgi
On Sat, Oct 3, 2009 at 10:30, Peter Stuge pe...@stuge.se wrote:
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI
coreboot payload based on the tianocore.org code.
I believe it might have been done already.
http://www.coreboot.org/File:Tianocoreboot.png
Am Samstag, den 03.10.2009, 14:49 -0700 schrieb Jordan Justen:
On Sat, Oct 3, 2009 at 10:30, Peter Stuge pe...@stuge.se wrote:
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI
coreboot payload based on the tianocore.org code.
I believe it might
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 10:30, Peter Stuge pe...@stuge.se wrote:
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI
coreboot payload based on the tianocore.org code.
I believe it might have been done already.
On Sat, Oct 3, 2009 at 10:40, ron minnich rminn...@gmail.com wrote:
I use qemu for a lot of coreboot work. I really depend on qemu for
many things I do, not just coreboot related. The qemu target in
coreboot has been very heavily used by us to test out new ideas.
That said, I don't see a
Am Samstag, den 03.10.2009, 15:13 -0700 schrieb Jordan Justen:
I'll admit that this is a fairly dumb argument to make while we are
talking about a QEMU release only a few months from now. But, as UEFI
seems to be gaining ground in the industry, I think the sooner QEMU
can get this support,
On Sat, Oct 3, 2009 at 15:02, Stefan Reinauer ste...@coresystems.de wrote:
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 10:30, Peter Stuge pe...@stuge.se wrote:
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a UEFI
coreboot payload based on the tianocore.org
Jordan Justen wrote:
I'm not going to take a side on this matter. But, I think what will
be more important is what is used in the majority of OS's and systems.
This is why we still put the 16-bit legacy BIOS as the #1 priority
after ~30 years. But, like I mention, I think there are signs
Peter Stuge wrote:
Patrick Georgi wrote:
What I don't know is, do we require any chipset setup to _reach_
CMOS?
It's not generally in the CPU, so some setup may be needed. On the
other hand, maybe 70/71 are decoded correctly on power up, just like
flash access?
It's not like there is a spec
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 15:02, Stefan Reinauer ste...@coresystems.de wrote:
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 10:30, Peter Stuge pe...@stuge.se wrote:
Jordan Justen wrote:
Anyway, it sounds like a useful project might be to develop a
On Sat, Oct 3, 2009 at 15:19, Patrick Georgi patr...@georgi-clan.de wrote:
Am Samstag, den 03.10.2009, 15:13 -0700 schrieb Jordan Justen:
I'll admit that this is a fairly dumb argument to make while we are
talking about a QEMU release only a few months from now. But, as UEFI
seems to be
On Sat, Oct 3, 2009 at 16:03, Stefan Reinauer ste...@coresystems.de wrote:
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 15:02, Stefan Reinauer ste...@coresystems.de wrote:
Jordan Justen wrote:
On Sat, Oct 3, 2009 at 10:30, Peter Stuge pe...@stuge.se wrote:
Jordan Justen wrote:
Anyway,
53 matches
Mail list logo
