Stefan Reinauer [EMAIL PROTECTED] writes:
I have thought about this a while back and have wanted to make a
change. Disabling CAR should fixup the stack etc but for performance
reasons we should setup/leave ROM and RAM caching enabled on the BSP.
If you are interested in looking at that I think
Add support for W83977EF Super-IO chip.
This is based on w83977tf code and on earlier support for this chip in
superiotool.
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
---
As trivial change as it was I still managed to make a couple of mistakes
(not all files renamed, one old resource
Well,
In a normal world you would use a debugger on the host, but because the
malware creators are introducing more and more debugger detection
techniques, obfuscation and so on, I was thinking of bypassing some of them
but just placing access on the memory at a lower level.
Is it possible to
It seems that romcc with -mcpu=p3 -O produces incorrect code for
cpu/x86/16bit/reset16.inc. -mpcu=p2 -O does work fine.
I will try to provide more hard data later but it looks like the
following code is compiled into an (slightly) incorrect jump which
breaks things terribly, of course.
Hi all,
I'm trying to play with coreboot to flash my bios on my PC, with no success.
here are the computer hardware information followed by the commands I'm
trying to execute.
INFO BEGIN
cpu: Socket370 Intel Pentium III Celeron
northbridge:Intel 82810E
southbridge:Intel 8281AA
Hi,
The latest svn revisions of filo and libpayload (r83 and r3708) conspire
to add the video console driver twice to the console_out list. This
causes the list to become circular, with the effect that device_putchar
spins in a loop printing the first character it is given. (F.)
Trivial patch
Hi Elia,
On 30.10.2008 11:45, Elia Yehuda wrote:
I'm trying to play with coreboot to flash my bios on my PC, with no success.
here are the computer hardware information followed by the commands I'm
trying to execute.
cpu: Socket370 Intel Pentium III Celeron
northbridge:Intel
Hello,
Maybe you should look at hardware assisted virtualization,
so that the debugger is on the host OS, and can't (almost?)
be circumvanted by malware in the guest OS...
You can then imagine a solution where your host OS +
debugger + etc... run with coreboot from a big flash.
I hope that this
On 29.10.2008 22:23, Myles Watson wrote:
I'm running with a very minimalized dts (attached) to try to get to the
point where a device gets matched correctly and disabled. I think devices
that should be disabled are causing me grief in SimNOW.
This is a snippet of the log file that has me
On 29.10.2008 09:02, Corey Osgood wrote:
Attached patches for cn700, vt8237(r/s), and the mainboard, Jetway J7F2,
along with a boot log. Currently, we're stuck in a reboot loop and I have no
idea why, seems to be related to CAR disabling (this wasn't happening when
disable_car was a noop).
here is the output you've requested :
INFO BEGIN
Calibrating delay loop... 366M loops per second, 100 myus = 350 us. OK.
No coreboot table found.
Found chipset Intel ICH, enabling flash write...
BIOS Lock Enable: disabled, BIOS Write Enable: enabled, BIOS_CNTL is 0x1
OK.
Probing for AMD
In northbridge/intel/i440bx/raminit.c:sdram_set_spd_registers all PAM
registers are programmed for RAM R/W access (0x33).
When SeaBIOS searches for option ROMs (including VGA ROM) it doesn't do
anything about PAM, so it sees empty memory instead of the ROMs.
I am not sure what is the best
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Andriy Gapon
Sent: Thursday, October 30, 2008 8:25 AM
To: Coreboot
Subject: [coreboot] coreboot.v2+seabios on 440bx: option roms not found
In
on 30/10/2008 16:34 Myles Watson said the following:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Andriy Gapon
Sent: Thursday, October 30, 2008 8:25 AM
To: Coreboot
Subject: [coreboot] coreboot.v2+seabios on 440bx: option roms not found
In
-Original Message-
From: Carl-Daniel Hailfinger [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2008 6:55 AM
To: Myles Watson
Cc: Coreboot
Subject: Re: [coreboot] Serengeti dts
On 29.10.2008 22:23, Myles Watson wrote:
I'm running with a very minimalized dts (attached) to
On 30.10.2008 15:47, Myles Watson wrote:
-Original Message-
From: Carl-Daniel Hailfinger [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2008 6:55 AM
To: Myles Watson
Cc: Coreboot
Subject: Re: [coreboot] Serengeti dts
On 29.10.2008 22:23, Myles Watson wrote:
I'm
-Original Message-
From: Andriy Gapon [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2008 8:43 AM
To: Myles Watson
Cc: 'Coreboot'
Subject: Re: [coreboot] coreboot.v2+seabios on 440bx: option roms not
found
on 30/10/2008 16:34 Myles Watson said the following:
On 30/10/08 08:38 -0600, Jordan Crouse wrote:
On 30/10/08 13:14 +0100, Arne Georg Gleditsch wrote:
Hi,
The latest svn revisions of filo and libpayload (r83 and r3708) conspire
to add the video console driver twice to the console_out list. This
causes the list to become circular, with
-Original Message-
From: Carl-Daniel Hailfinger [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2008 8:49 AM
To: Myles Watson
Cc: 'Coreboot'
Subject: Re: [coreboot] Serengeti dts
On 30.10.2008 15:47, Myles Watson wrote:
-Original Message-
From: Carl-Daniel
Author: stepan
Date: 2008-10-30 15:57:35 +0100 (Thu, 30 Oct 2008)
New Revision: 84
Modified:
trunk/filo/main/filo.c
Log:
Patch from Arne Georg Gleditsch
The latest svn revisions of filo and libpayload (r83 and r3708) conspire
to add the video console driver twice to the console_out list.
Jordan Crouse [EMAIL PROTECTED] writes:
My bad - they are using a custom entry point (see i386/switch.S in filo).
So, they do need to call console_init() and lib_get_sysinfo(). Your
patch is correct.
Yes, I verified that console_out was NULL when entering filo.c's init().
Acked-by: Jordan
Is it a feature that the device scan depends on the order that the devices
are listed in in the dts?
What I'm saying is that if you list the HT tunnel before the PCI bridge you
get different results than if you list the bridge first. Is this by
design? Is the dts supposed to be ordered as if it
on 30/10/2008 16:52 Myles Watson said the following:
-Original Message-
From: Andriy Gapon [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2008 8:43 AM
To: Myles Watson
Cc: 'Coreboot'
Subject: Re: [coreboot] coreboot.v2+seabios on 440bx: option roms not
found
on 30/10/2008
Author: uwe
Date: 2008-10-30 16:41:39 +0100 (Thu, 30 Oct 2008)
New Revision: 3709
Modified:
trunk/util/nvramtool/cmos_lowlevel.c
trunk/util/nvramtool/common.h
Log:
Allow nvramtool to build and work on FreeBSD. Tested on FreeBSD 7.
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
Acked-by: Uwe
On Wed, Oct 29, 2008 at 03:14:46PM +0200, Andriy Gapon wrote:
Allow nvramtool to build and work on FreeBSD.
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
Thanks, r3709, with some changes though.
The patch you posted was breaking the build on Linux for me.
Index: cmos_lowlevel.c
AFAIK, flashrom is broken for most ICHx.
-Corey
On Thu, Oct 30, 2008 at 9:57 AM, [EMAIL PROTECTED] wrote:
here is the output you've requested :
INFO BEGIN
Calibrating delay loop... 366M loops per second, 100 myus = 350 us. OK.
No coreboot table found.
Found chipset Intel ICH, enabling
On 30/10/08 13:14 +0100, Arne Georg Gleditsch wrote:
Hi,
The latest svn revisions of filo and libpayload (r83 and r3708) conspire
to add the video console driver twice to the console_out list. This
causes the list to become circular, with the effect that device_putchar
spins in a loop
On Wed, Oct 29, 2008 at 12:29 PM, [EMAIL PROTECTED] wrote:
Author: rminnich
Date: 2008-10-29 19:29:19 +0100 (Wed, 29 Oct 2008)
New Revision: 963
Modified:
coreboot-v3/device/device.c
coreboot-v3/device/root_device.c
Log:
Make it so that read_resources only reads resources.
It's
Andriy Gapon wrote:
on 30/10/2008 16:52 Myles Watson said the following:
-Original Message-
From: Andriy Gapon [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2008 8:43 AM
To: Myles Watson
Cc: 'Coreboot'
Subject: Re: [coreboot] coreboot.v2+seabios on 440bx: option roms not
Myles Watson wrote:
get_fx_devs() was called very few places, and it wasn't needed except
the first call. I combined them.
Signed-off-by: Myles Watson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Looks good to me.
Acked-by: Marc Jones [EMAIL PROTECTED]
--
Marc Jones
Senior Firmware Engineer
any plans on fixing the issue or using alternative? is there a way i can
assist?
On Oct 30, 2008 5:47pm, Corey Osgood [EMAIL PROTECTED] wrote:
AFAIK, flashrom is broken for most ICHx.
-Corey
On Thu, Oct 30, 2008 at 9:57 AM, [EMAIL PROTECTED] wrote:
here is the output you've requested :
on 30/10/2008 17:46 Uwe Hermann said the following:
On Wed, Oct 29, 2008 at 03:14:46PM +0200, Andriy Gapon wrote:
Allow nvramtool to build and work on FreeBSD.
Signed-off-by: Andriy Gapon [EMAIL PROTECTED]
Thanks, r3709, with some changes though.
Thanks a lot!
The patch you posted was
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer uwe checked in revision 3709 to
the coreboot source repository and caused the following
changes:
Change Log:
Allow nvramtool to build and work on FreeBSD. Tested on FreeBSD 7.
Signed-off-by: Andriy
I don't have any hardware to poke at right now :(
-Corey
On Thu, Oct 30, 2008 at 11:57 AM, [EMAIL PROTECTED] wrote:
any plans on fixing the issue or using alternative? is there a way i can
assist?
On Oct 30, 2008 5:47pm, Corey Osgood [EMAIL PROTECTED] wrote:
AFAIK, flashrom is broken for
Vincent,
what do you mean exactly by hardware assisted virtualization ?
I prefer to stay away of virtualization because malware tend to implement
techniques to detect if they are running on VMs.
thx
---
Jean-François Agneessens
--
coreboot mailing list:
David,
SMM/SMI seem to be a possible solution. If it is undetectable by the OS, I
am wondering why OSes can still detect it : Windows/Linux define an SMI
Timeout within which SMM Handlers should complete their job and return
control back to OS normal operations. Otherwise the OS will crash.
-Original Message-
From: Marc Jones [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2008 9:57 AM
To: Myles Watson
Cc: Coreboot
Subject: Re: [coreboot] get_fx_devs
Myles Watson wrote:
get_fx_devs() was called very few places, and it wasn't needed except
the first call.
Myles Watson wrote:
-Original Message-
From: Marc Jones [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 30, 2008 9:57 AM
To: Myles Watson
Cc: Coreboot
Subject: Re: [coreboot] get_fx_devs
Myles Watson wrote:
get_fx_devs() was called very few places, and it wasn't needed except
Hi,
+ * (C)2008 LiPPERT Embedded Computers GmbH, released under the GNU GPLv2
+ *
+ * Based on cache_as_ram_auto.c from AMD's DB800 and DBM690T mainboards.
Please use the usual license header format for further patches, see:
autoboot_delay.diff (changes filo.c):
Fixes compile error if AUTOBOOT_DELAY=0.
fs_arch.diff (changes ext2fs.c, fat.c):
#if ARCH == 'i386'
results in a compile warning: multi-character character constant and
the condition ARCH=='i386' is mis-evaluated as FALSE, eventually choking
the assembler on
I prefer to stay away of virtualization because malware tend to implement
techniques to detect if they are running on VMs.
And disable themselves ? Maybe that would be a fine solution for the
problem then ;-)
Yeah I know, this is indeed a good way to prevent malware going bad :-) If
you
On 30.10.2008 16:57, [EMAIL PROTECTED] wrote:
any plans on fixing the issue or using alternative? is there a way i
can assist?
Your flash chip is not supported. I'll add code for it.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
--
coreboot mailing list: coreboot@coreboot.org
Author: uwe
Date: 2008-10-30 20:34:44 +0100 (Thu, 30 Oct 2008)
New Revision: 3710
Added:
trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/
trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/Config.lb
trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/Options.lb
Hi Jens,
On Thu, Oct 30, 2008 at 06:16:10PM +0100, Jens Rottmann wrote:
Is there a reason to encode this in an u16? You could also use a struct
like this, which is more readable IMHO:
const struct foo {
u8 data;
u8 index;
} foo_table[] = {
{0x07,
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer mjones checked in revision 3711 to
the coreboot source repository and caused the following
changes:
Change Log:
Here's a patch towards r3690 upping the ROM size for the S2912 Fam10 target to
1M.
Both
Uwe Hermann wrote:
The wiki doesn't say much about this topic. There is a nice diagram to
show where the images are stored and how big they are, but it doesn't
say what they're needed for. And what the heck is the difference
between fallback and failover??
Good question ;)
Author: mjones
Date: 2008-10-30 22:31:54 +0100 (Thu, 30 Oct 2008)
New Revision: 3712
Modified:
trunk/coreboot-v2/targets/tyan/s2912_fam10/Config-abuild.lb
Log:
Increased the size of the failover and normal ROM_IMAGE_SIZE so abuild will
pass with toolsets that compile larger images. (trivial)
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer mjones checked in revision 3712 to
the coreboot source repository and caused the following
changes:
Change Log:
Increased the size of the failover and normal ROM_IMAGE_SIZE so abuild will
pass with
Arne Georg Gleditsch wrote:
Stefan Reinauer [EMAIL PROTECTED] writes:
I have thought about this a while back and have wanted to make a
change. Disabling CAR should fixup the stack etc but for performance
reasons we should setup/leave ROM and RAM caching enabled on the BSP.
If you are
Author: mjones
Date: 2008-10-30 23:13:51 +0100 (Thu, 30 Oct 2008)
New Revision: 3713
Modified:
trunk/coreboot-v2/targets/tyan/s2912_fam10/Config-abuild.lb
Log:
Leave room for ROM growth and for the payload. (trivial)
Signed-off-by: Marc Jones [EMAIL PROTECTED]
Acked-by: Marc Jones [EMAIL
On 30.10.2008, at 15:03, Marc Jones [EMAIL PROTECTED] wrote:
I think that this is in all K8 and fam10 disable_car code.
The copy to memory is probably good. Running from the rom and
decompressing from the rom is going to thrash. It may affect some
cpu/chipset combinations more than others.
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer mjones checked in revision 3713 to
the coreboot source repository and caused the following
changes:
Change Log:
Leave room for ROM growth and for the payload. (trivial)
Signed-off-by: Marc Jones [EMAIL
Stefan Reinauer wrote:
On 30.10.2008, at 15:03, Marc Jones [EMAIL PROTECTED] wrote:
I think that this is in all K8 and fam10 disable_car code.
The copy to memory is probably good. Running from the rom and
decompressing from the rom is going to thrash. It may affect some
cpu/chipset
On 30.10.2008 23:33, Marc Jones wrote:
Stefan Reinauer wrote:
On 30.10.2008, at 15:03, Marc Jones [EMAIL PROTECTED] wrote:
I think that this is in all K8 and fam10 disable_car code.
The copy to memory is probably good. Running from the rom and
decompressing from the rom is going to thrash.
On 29.10.2008 09:02, Corey Osgood wrote:
Attached patches for cn700, vt8237(r/s), and the mainboard, Jetway J7F2,
along with a boot log. Currently, we're stuck in a reboot loop and I have no
idea why, seems to be related to CAR disabling (this wasn't happening when
disable_car was a noop).
debug log attached.
Thanks,
Corey
On Thu, Oct 30, 2008 at 8:09 PM, Carl-Daniel Hailfinger
[EMAIL PROTECTED] wrote:
On 29.10.2008 09:02, Corey Osgood wrote:
Attached patches for cn700, vt8237(r/s), and the mainboard, Jetway J7F2,
along with a boot log. Currently, we're stuck in a reboot
Author: uwe
Date: 2008-10-31 06:40:04 +0100 (Fri, 31 Oct 2008)
New Revision: 3714
Added:
trunk/util/nvramtool/nvramtool.8
Removed:
trunk/util/nvramtool/nvramtool.1
Modified:
trunk/util/nvramtool/Makefile
Log:
Move the nvramtool manpage to section 8 (as it's only really usable as root),
57 matches
Mail list logo
