Myles Watson wrote:
I've never actually built s4882, but it should have worked. Can you build
Coreboot for any other boards?
I have not tried, but I have no other computers I want to run
continuously for main use in the next few months.
you could try buildrom if you want a simple way of
(Perhaps 'payload' should be in $target in the first place.)
Config.lb is used to build several Makefiles and they are in
further subdirectories of target/vendor/board/dir/
It is easy and reliable to use an absolute path to the payload.
Apparently that (in
ron minnich wrote:
On Mon, Feb 2, 2009 at 12:53 AM, Stefan Reinauer ste...@coresystems.de
wrote:
One thing I wonder though, do we want to call weak symbols
unconditionally, as in Rudolf's code? No if() clause catches the case
that the symbol isn't there. In a test program that call
Hi Peter,
Peter Stuge schrieb:
Hi Piotr,
Piotr Brostovski wrote:
..
Do anyone have an idea why this doesn't work?
Yes.
Instead, you can use mkelfImage. It isn't really maintained anymore
but we're making it available from the coreboot.org repo.
Refer to my other discussion:
2009/1/30 Peter Stuge pe...@stuge.se:
Peter Stuge wrote:
Can someone please review these register definitions? Thank you!
Attaching latest version also available at
http://stuge.se/mt.cs5536_pic_divil3.patch
const struct msrdef cs5536_msrs[] = {
+ /* 0x5148-0x514f per 33238G
David Melik wrote:
It is easy and reliable to use an absolute path to the payload.
I tried payload 'grub2' and './grub2'
Those are both relative paths, and because the v2 build system is
less than transparent I recommend using an absolute path to begin
with.
payload grub2
So here I would
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't
compatible with current gPXE releases?
mkelfImage is strictly for Linux.
Upstream gPXE can not be built for coreboot, but here is a web page
with some information that may still be useful:
On Tue, Feb 3, 2009 at 7:55 AM, Peter Stuge pe...@stuge.se wrote:
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't
compatible with current gPXE releases?
mkelfImage is strictly for Linux.
Upstream gPXE can not be built for coreboot, but here is a web
Hi Peter,
Peter Stuge schrieb:
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't
compatible with current gPXE releases?
mkelfImage is strictly for Linux.
ok, then i think we're kind of stuck ...
Upstream gPXE can not be built for coreboot, but
On 03.02.2009 16:55 Uhr, Peter Stuge wrote:
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't
compatible with current gPXE releases?
mkelfImage is strictly for Linux.
Upstream gPXE can not be built for coreboot, but here is a web page
with
On Tue, Feb 3, 2009 at 9:17 AM, Stefan Reinauer ste...@coresystems.de wrote:
On 03.02.2009 16:55 Uhr, Peter Stuge wrote:
Piotr Brostovski wrote:
I'm asking myself if it is possible that mkelfImage simply isn't
compatible with current gPXE releases?
mkelfImage is strictly for Linux.
I recently encountered a coreboot-v2 on Geode-LX issue similar to this
post: http://www.mail-archive.com/linuxb...@linuxbios.org/msg12055.html
The germane portion of that thread's serial dump is:
Unexpected Exception: 13 @ 10:00016765 - Halting
In the posted case, the code of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Committed revision 3928.
Thanks,
Rudolf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmIxLwACgkQ3J9wPJqZRNU+AwCgqcdQbmH9s97Og7nrwY0YuLyP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
Its in.
Committed revision 3929.
I wont have time for this until next Tuesday. I have in plan to tune up the
first patch as I discussed this with Carl-Daniel. If someone has time please do
that so.
Thanks,
Rudolf
-BEGIN PGP
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer ruik checked in revision 3928 to
the coreboot source repository and caused the following
changes:
Change Log:
Following patch adds missing CPU names. Please check
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I think gpxe works with following combination
Coreboot + SeaBIOS + gpxe.
Rudolf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Author: ruik
Date: 2009-02-03 23:25:51 +0100 (Tue, 03 Feb 2009)
New Revision: 3928
Modified:
trunk/coreboot-v2/src/cpu/amd/model_fxx/processor_name.c
Log:
Following patch adds missing CPU names. Please check
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/33610.pdf
if I
Author: ruik
Date: 2009-02-03 23:37:22 +0100 (Tue, 03 Feb 2009)
New Revision: 3929
Removed:
trunk/coreboot-v2/src/northbridge/amd/amdk8/ssdt.dsl
Modified:
trunk/coreboot-v2/src/mainboard/agami/aruma/acpi_tables.c
trunk/coreboot-v2/src/mainboard/amd/dbm690t/acpi_tables.c
I did that, then did not see Opterons listed in it or on
coreboot.org/buildrom/.
?
The current buildrom just
seems to omit Opteron 800 (or any) series, and that link omits s4882
from 'supported boards.'
I thought I read in the archives that someone patched coreboot for
Piotr Brostovski wrote:
http://whiterocker.com/gpxe/
i know the site, i made also an updated patch which works with
current gpxe and coreboot release.
But neither the new one, or the old do work on a bcom winnet p680
(corrupted vga output)
Getting graphics to work is the single most
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer ruik checked in revision 3929 to
the coreboot source repository and caused the following
changes:
Change Log:
Following patch converts the run-time SSDT patching via update_ssdt funtion to
new AML code
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer ruik checked in revision 3926 to
the coreboot source repository and caused the following
changes:
Change Log:
Following patch fixes VIA SPI (VT8237S). It needs to have opcodes
initialized same way as
Does anybody give some comments?
Joe
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Bao, Zheng
Sent: Monday, February 02, 2009 12:12 PM
To: Coreboot
Subject: [coreboot] [patch] flashrom: resending my patch about
SPI/LPCconflicts
The DBM690T/Pistachio DSDT has some issues in the memory management code:
- TOM is hardcoded to a fixed value and not updated.
- TOM2 is hardcoded as well.
- The TOM2!=0 case is commented out.
Fixes in this patch:
- Rename TOM to TOM1 and refer to the SSDT value with an External(TOM1)
clause.
-
Hi Zheng,
On 02.02.2009 05:12, Bao, Zheng wrote:
Signed-off-by: Zheng Bao zheng@amd.com
This patch is about flashrom running on dbm690t. It was sent several
months ago and hasn't got any response yet. Now it deals with 3
problems.
1. Fix the bug that the flashrom would hang if there is
Hello,
Bao, Zheng wrote:
This patch is about flashrom running on dbm690t.
It was sent several months ago and hasn't got any response yet.
Thanks for sending it, and thank you very much for the reminder!
I sometimes forget about patches on the mailing list. Sorry for
the delay.
Now it deals
Sorry for the delay.. Way too much to do and so little time..
Fixed the spotted issues and added 1ms delay to match the BKDG while waiting
for BAR+0xe to set its bits.
Dan Lykowski
Signed-off-by: Dan Lykowskilyko...@gmail.com
From: Li, Maggie
Hi,
About 2, we don't have to know where the board boots. If we assume the
cross-burning is not allowed, the flashrom can not detect the existence
of a SPI chip. Then it will not do any SPI action. Right?
Zheng
-Original Message-
From: coreboot-boun...@coreboot.org
Dan
I think you made a mistake. It should be “sm_dev =
dev_find_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_ATI_SB600_SM, 0);”, not
“sm_dev = pci_locate_device(PCI_ID(0x1002, 0x4385), 0);” in your file.
In my last letter, there is a writing error. We should say that dev_find_device
is more
Hi Dan,
sorry for chasing you around in circles on that issue.
On 04.02.2009 05:14, Li, Maggie wrote:
Dan
I think you made a mistake. It should be “sm_dev =
dev_find_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_ATI_SB600_SM, 0);”, not
“sm_dev = pci_locate_device(PCI_ID(0x1002, 0x4385), 0);”
Bao, Zheng wrote:
About 2, we don't have to know where the board boots.
I'm afraid we do.
If we assume the cross-burning is not allowed, the flashrom can not
detect the existence of a SPI chip. Then it will not do any SPI
action. Right?
The flashbus variable is used to control if and how
That is why I send the patch which removes code that unconditionally
enables SPI in the PM registers. If the SPI commands failed, it will go
on probing other chips. And then it will find the LPC flashchip which it
should work with.
Zheng
-Original Message-
From:
Hi,
Bao, Zheng wrote:
That is why I send the patch which removes code that
unconditionally enables SPI in the PM registers. If the SPI
commands failed, it will go on probing other chips. And then it
will find the LPC flashchip which it should work with.
SPI commands will hang if there is no
33 matches
Mail list logo
