Hi..
Thanks for your reply
We have tried like this,we have copied original BIOS(PM49FL004) content in
the filename feb6 and tried to flash on
SST49LF004B flashrom chip and then we followed this steps .
[EMAIL PROTECTED] ~]# /usr/sbin/flashrom -E
Calibrating delay loop... OK.
I see a big improvement in boot time. The only remaining issue is the
scan for LAR entries in empty space.
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Feb 6, 2008 12:08 AM, Corey Osgood <[EMAIL PROTECTED]> wrote:
> On Jan 29, 2008 9:37 AM, Uwe Hermann <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > On Tue, Jan 29, 2008 at 11:46:42AM +0100, Carl-Daniel Hailfinger wrote:
> > > On 28.01.2008 23:16, Urbez Santana Roma wrote:
> > > > Ok. The changes
On Jan 29, 2008 9:37 AM, Uwe Hermann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Tue, Jan 29, 2008 at 11:46:42AM +0100, Carl-Daniel Hailfinger wrote:
> > On 28.01.2008 23:16, Urbez Santana Roma wrote:
> > > Ok. The changes are done. Here the attachments.
> > >
> >
> > Great, thanks! I'd like to have t
On 06.02.2008 03:38, Marc Jones wrote:
> For completeness here is the patch with the acks.
> r573
Thanks. Qemu/x86 compilation fixed in r574.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Author: hailfinger
Date: 2008-02-06 04:12:53 +0100 (Wed, 06 Feb 2008)
New Revision: 574
Modified:
coreboot-v3/mainboard/emulation/qemu-x86/stage1.c
Log:
Fix compilation for qemu/x86 by renaming pre_payload() to
mainboard_pre_payload() in mainboard/emulation/qemu-x86/stage1.c.
Signed-off-by: Ca
Author: hailfinger
Date: 2008-02-06 04:12:53 +0100 (Wed, 06 Feb 2008)
New Revision: 574
Modified:
coreboot-v3/mainboard/emulation/qemu-x86/stage1.c
Log:
Fix compilation for qemu/x86 by renaming pre_payload() to
mainboard_pre_payload() in mainboard/emulation/qemu-x86/stage1.c.
Signed-off-by: Ca
On 06.02.2008 02:09, Carl-Daniel Hailfinger wrote:
> On 04.02.2008 22:04, Chris Lingard wrote:
>
>> I recently found someone who could do the work of modifying the
>> motherboard, Harald kindly posted me the chip.
>>
>> The machine came back and it would not boot with the switch up
>>
>> I then
For completeness here is the patch with the acks.
r573
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
Cache the ROM to speed up stage2 and payload decompression.
Due to some problems with PCI transactions, Geode
Author: mjones
Date: 2008-02-06 03:36:50 +0100 (Wed, 06 Feb 2008)
New Revision: 573
Modified:
coreboot-v3/arch/x86/Makefile
coreboot-v3/arch/x86/ldscript.ld
coreboot-v3/arch/x86/stage1.c
coreboot-v3/include/arch/x86/amd_geodelx.h
coreboot-v3/mainboard/adl/msm800sev/stage1.c
coreb
Author: mjones
Date: 2008-02-06 03:36:50 +0100 (Wed, 06 Feb 2008)
New Revision: 573
Modified:
coreboot-v3/arch/x86/Makefile
coreboot-v3/arch/x86/ldscript.ld
coreboot-v3/arch/x86/stage1.c
coreboot-v3/include/arch/x86/amd_geodelx.h
coreboot-v3/mainboard/adl/msm800sev/stage1.c
coreb
On 06.02.2008 02:44, ron minnich wrote:
> On Feb 5, 2008 5:38 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
>
>
>> Correct, but I foresee other non-Geode platforms needing a call just
>> prior to the payload running but I am flexible on this.
>> Do others have an opinion?
>>
>
> yes. I think we
Carl-Daniel Hailfinger wrote:
> On 06.02.2008 02:38, Marc Jones wrote:
>
>> Carl-Daniel Hailfinger wrote:
>>
>>>
>>> pre_payload() is not board specific, but Geode LX-specific.
>>> geodelxinit.c may be a more appropriate location.
>>>
>>>
>>>
>> Correct, but I foresee other non-Ge
On 2008-02-05 19:41, yhlu wrote:
> if replace the co-processor with opteron, does the cold reset work?
I did not try 2 processors. With a single processor alone it does not work.
Roman
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 06.02.2008 02:38, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>> On 05.02.2008 00:27, Marc Jones wrote:
>>>
>>> /**
>>> * TODO.
>>> Index: coreboot-v3/mainboard/adl/msm800sev/stage1.c
>>> ===
>>> --- coreboot-v3.orig/main
On Feb 5, 2008 5:38 PM, Marc Jones <[EMAIL PROTECTED]> wrote:
> Correct, but I foresee other non-Geode platforms needing a call just
> prior to the payload running but I am flexible on this.
> Do others have an opinion?
yes. I think we'll need this. And I would like, in the future, to get
the sta
On Feb 5, 2008 5:19 PM, Roman Kononov <[EMAIL PROTECTED]> wrote:
> On 2008-02-05 19:06, yhlu wrote:
> > then cold reset and warm reset all work?
>
> These things are still the same. Warm reset works. Cold reset does not.
> After the cold reset sequence the CPU hangs, only the push button or power
>
Carl-Daniel Hailfinger wrote:
> On 05.02.2008 00:27, Marc Jones wrote:
>
>> ron minnich wrote:
>>
>>> Why can't we shadow?
>>>
>> We could.
>>
>
> Even at the top of the 4G address range? If that is possible, I'd vote
> to shadow the bootblock only to save RAM.
>
> Some comments
Chris: Try this patch against latest flashrom, please. It will not
detect your chip, but id1/id2 output should change. I need full output
from flashrom -V with that patch to proceed further.
Handle JEDEC JEP106W continuation codes in SPI RDID. Some vendors like
Programmable Micro Corp need this.
B
On 2008-02-05 19:06, yhlu wrote:
> then cold reset and warm reset all work?
These things are still the same. Warm reset works. Cold reset does not.
After the cold reset sequence the CPU hangs, only the push button or power
switch can revive it. Is it supposed to work or there are secrets somewhe
On 04.02.2008 22:04, Chris Lingard wrote:
> I recently found someone who could do the work of modifying the
> motherboard, Harald kindly posted me the chip.
>
> The machine came back and it would not boot with the switch up
>
> I then probably made a mistake, I used the BIOS itself to dump the
>
On Feb 5, 2008 3:29 PM, Roman Kononov <[EMAIL PROTECTED]> wrote:
> On 2008-02-05 09:48, Roman Kononov wrote:
> > I have a co-processor.
> >
> > The sequence I hope to have:
> >
> > 1) Power up. Power-on reset. The co-processor takes long time to become
> > alive (~500s). By this time the CPU thinks
Carl-Daniel, you could never irritate me, your comments are too
incredibly useful for that!
let's forget I said anything.
Marc, your proposed patch (pre-payload) is
Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]>
let's try it out.If you can commit I will test tonight or tomorrow night.
ron
--
I'm sorry.
I just reread my mail and realized the tone didn't come out right. I
wish to apologize if this caused any irritation.
Regards,
Carl-Daniel
On 06.02.2008 01:21, Carl-Daniel Hailfinger wrote:
> On 05.02.2008 23:44, ron minnich wrote:
>
>> An assumption on v3 going on was that we could
On 05.02.2008 00:27, Marc Jones wrote:
> ron minnich wrote:
>> Why can't we shadow?
>
> We could.
Even at the top of the 4G address range? If that is possible, I'd vote
to shadow the bootblock only to save RAM.
Some comments on the patch:
> Cache the ROM to speed up stage2 and payload decompress
On 05.02.2008 23:44, ron minnich wrote:
> An assumption on v3 going on was that we could run out of ROM, and be
> fast, since caches are our friend.
>
> That assumption is not working out. Here is another possible design.
>
> stage 0, running in ROM, turns on CAR and runs initram in the LAR.
>
> in
On 2008-02-05 09:48, Roman Kononov wrote:
> I have a co-processor.
>
> The sequence I hope to have:
>
> 1) Power up. Power-on reset. The co-processor takes long time to become
> alive (~500s). By this time the CPU thinks that the HT link is dead.
> 2) CPU issues another reset.
> 3) The CPU re-in
I think it is buildtarget that creates the make file. I haven't looked
for it yet.
-Original Message-
From: Marc Jones [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 05, 2008 2:19 PM
To: Clay Jones
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] Build error with top of tree V2
Cla
Carl-Daniel Hailfinger wrote:
> On 05.02.2008 18:23, Marc Jones wrote:
>> Carl-Daniel Hailfinger wrote:
>
> Thanks for the explanation. So this final cleanup need not be applied
> for stage2, only for the real payload because we don't know what the
> payload may do.
>
>
Correct. That was what m
An assumption on v3 going on was that we could run out of ROM, and be
fast, since caches are our friend.
That assumption is not working out. Here is another possible design.
stage 0, running in ROM, turns on CAR and runs initram in the LAR.
initram disables car, copies ALL of LAR to top of memor
Hi Clay,
On 05.02.2008 20:00, Clay Jones wrote:
> I am getting the following error when building the
> Serengeti_cheetah_fam10 target:
>
> gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld
> crt0.o
> nm -n coreboot | sort > coreboot.map
> objcopy --gap-fill 0xff -O binary coreb
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer "myles" checked in revision 3090 to
the coreboot source repository and caused the following
changes:
Change Log:
This patch changes all rom names that aren't coreboot.rom in Config.lb files.
I think tha
On 05.02.2008 18:23, Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>> On 05.02.2008 07:31, ron minnich wrote:
>>> I think this is fine but I'd like to fit it into the "stage"
>>> nomenclature, so the numbering fits.
>>>
>>> So which stage is this? I am not sure, I feel like the stage numbering
Clay Jones wrote:
> I found the problem. The wrong ar command was being used because the
> make file does not have " $(CROSS_COMPILE)" in front of the ar command.
>
Good catch! Which file or can you send a patch?
Thanks,
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailt
I found the problem. The wrong ar command was being used because the
make file does not have " $(CROSS_COMPILE)" in front of the ar command.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Clay Jones
Sent: Tuesday, February 05, 2008 1:08 PM
To: Marc Jones
Author: myles
Date: 2008-02-05 22:53:15 +0100 (Tue, 05 Feb 2008)
New Revision: 3090
Modified:
trunk/coreboot-v2/targets/agami/aruma/Config.lb
trunk/coreboot-v2/targets/agami/aruma/Config1M.lb
trunk/coreboot-v2/targets/amd/db800/Config.lb
trunk/coreboot-v2/targets/amd/norwich/Config.lb
Author: myles
Date: 2008-02-05 22:53:15 +0100 (Tue, 05 Feb 2008)
New Revision: 3090
Modified:
trunk/coreboot-v2/targets/agami/aruma/Config.lb
trunk/coreboot-v2/targets/agami/aruma/Config1M.lb
trunk/coreboot-v2/targets/amd/db800/Config.lb
trunk/coreboot-v2/targets/amd/norwich/Config.lb
On 05/02/08 14:20 -0700, Myles Watson wrote:
> This patch changes all rom names that aren't coreboot.rom in Config.lb files.
>
> I think that since the directory specifies the architecture and the
> board, it is redundant information to name it something else, and it
> makes it more difficult to a
This patch changes all rom names that aren't coreboot.rom in Config.lb files.
I think that since the directory specifies the architecture and the
board, it is redundant information to name it something else, and it
makes it more difficult to automate the build process (buildrom).
In buildrom we s
I am using buildrom and have built with the following tools on centos
4.4 (redhat):
gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
GNU Make 3.80
GNU ld version 2.15.92.0.2 20040927
GNU objcopy 2.15.92.0.2 20040927
-Original Message-
From: Marc Jones [mailto:[EMAIL PROTECTED]
Sent: Tuesday,
Luc Verhaegen.
SUSE/Novell X Driver Developer.
Flashrom: Add board enable for VIA EPIA SP.
Signed-off-by: Luc Verhaegen <[EMAIL PROTECTED]>
Index: board_enable.c
===
--- board_enable.c (revision 3089)
+++ board_enable.c (wor
On 2008-02-05 14:18, yhlu wrote:
> I don't think there are hundreds of vendors for that.
>
> DRC computer?
They offer only socket 940.
> you don't need cold reset.
>
> at that case even cold reset doesn't work.
After "HT Cold Reset" (PWROK deasserted and SYSRST asserted) the CPU
reinitializes
On Feb 5, 2008 11:13 AM, Roman Kononov <[EMAIL PROTECTED]> wrote:
>
> On 2008-02-05 11:45, yhlu wrote:
> > On Feb 5, 2008 7:48 AM, Roman Kononov <[EMAIL PROTECTED]> wrote:
> >> On 2008-02-05 00:48 yhlu said the following:
> >>
> >>> On Feb 4, 2008 9:29 PM, Roman Kononov <[EMAIL PROTECTED]> wrote:
>
On 2008-02-05 13:29, Myles Watson wrote:
> Isn't there supposed to be a way to use ldtstop to reinitialize the HT link
> without a cold reset? It seems like I read that it is faster.
No, ldtstop does not fully reinitialize the link. If the CPU detects a dead
link after the cold reset, it will ne
>From the datasheet:
"In the LAN controller the D0 state is partitioned into two substates, D0
Uninitialized (D0u) and D0 Active (D0a). [...] Initialization of the CSR,
Memory, or I/O Base Registers in the PCI Configuration space switches the
LAN controller D0u state to the D0a state."
and
"The
Clay Jones wrote:
> Hi,
>
> I am getting the following error when building the
> Serengeti_cheetah_fam10 target:
>
>
> gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld
> crt0.o
> nm -n coreboot | sort > coreboot.map
> objcopy --gap-fill 0xff -O binary coreboot coreboot.str
> On 2008-02-05 11:45, yhlu wrote:
> > On Feb 5, 2008 7:48 AM, Roman Kononov <[EMAIL PROTECTED]> wrote:
> >> On 2008-02-05 00:48 yhlu said the following:
> >>
> >>> On Feb 4, 2008 9:29 PM, Roman Kononov <[EMAIL PROTECTED]> wrote:
> I have difficulty cold-resetting Tyan s2912, which has mcp55.
On 2008-02-05 11:45, yhlu wrote:
> On Feb 5, 2008 7:48 AM, Roman Kononov <[EMAIL PROTECTED]> wrote:
>> On 2008-02-05 00:48 yhlu said the following:
>>
>>> On Feb 4, 2008 9:29 PM, Roman Kononov <[EMAIL PROTECTED]> wrote:
I have difficulty cold-resetting Tyan s2912, which has mcp55.
Th
hello,
first, thanks for your work. i'am very interested in your project and want to
install coreboot with a kernel as payload on my tyan s2895 and using a addon
graphiccard(geforce 6600 gt). my current system is running gentoo (kernel
2.6.24 x64). i read the amd64 doc and want to start. i only
Hi,
I am getting the following error when building the
Serengeti_cheetah_fam10 target:
gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld
crt0.o
nm -n coreboot | sort > coreboot.map
objcopy --gap-fill 0xff -O binary coreboot coreboot.strip
cp ../payload.elf payload
./buildrom
On Feb 5, 2008 7:48 AM, Roman Kononov <[EMAIL PROTECTED]> wrote:
> On 2008-02-05 00:48 yhlu said the following:
>
> > On Feb 4, 2008 9:29 PM, Roman Kononov <[EMAIL PROTECTED]> wrote:
> >> I have difficulty cold-resetting Tyan s2912, which has mcp55.
> >>
> >> The sequence
> >> outb(0x2,0xcf9);
ron minnich wrote:
> On Feb 5, 2008 4:00 AM, Carl-Daniel Hailfinger
> <[EMAIL PROTECTED]> wrote:
>
>> Remember that we load stage 2 like a payload, so we'd have execution
>> order stage 0,1,3,4,5,2,3,4,5,realpayload.
>
> Not if the stage definition is in main. I realized some time ago that
> ar
Carl-Daniel Hailfinger wrote:
> On 05.02.2008 07:31, ron minnich wrote:
>> I think this is fine but I'd like to fit it into the "stage"
>> nomenclature, so the numbering fits.
>>
>> So which stage is this? I am not sure, I feel like the stage numbering
>> never quite got finished :-)
>>
>> possib
On Tue, Feb 05, 2008 at 10:51:39AM -0500, [EMAIL PROTECTED] wrote:
> So I found this in the ICH4 datasheet:
>
> The LAN controller enters Wake on LAN mode after reset if the Wake
> on LAN bit in the EEPROM is set *(which it is)*.
You could try changing this bit in the EEPROM before running
corebo
On Feb 5, 2008 4:00 AM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
>
> Remember that we load stage 2 like a payload, so we'd have execution
> order stage 0,1,3,4,5,2,3,4,5,realpayload.
Not if the stage definition is in main. I realized some time ago that
arch/x86/stage1.c is misnamed (my f
So I found this in the ICH4 datasheet:
The LAN controller enters Wake on LAN mode after reset if the Wake on
LAN bit in the EEPROM is set *(which it is)*. At this point, the LAN
controller is in the D0u state. When the LAN controller is in Wake on
LAN mode:
? The LAN controller scans incomin
On 2008-02-05 09:48 Roman Kononov said the following:
> On 2008-02-05 00:48 yhlu said the following:
>> On Feb 4, 2008 9:29 PM, Roman Kononov <[EMAIL PROTECTED]> wrote:
>>> I have difficulty cold-resetting Tyan s2912, which has mcp55.
>>>
>>> The sequence
>>> outb(0x2,0xcf9);
>>> outb(0x6
On 2008-02-05 00:48 yhlu said the following:
> On Feb 4, 2008 9:29 PM, Roman Kononov <[EMAIL PROTECTED]> wrote:
>> I have difficulty cold-resetting Tyan s2912, which has mcp55.
>>
>> The sequence
>> outb(0x2,0xcf9);
>> outb(0x6,0xcf9);
>> is a warm reset. It does not reset the HyperTransp
On 05.02.2008 07:31, ron minnich wrote:
> I think this is fine but I'd like to fit it into the "stage"
> nomenclature, so the numbering fits.
>
> So which stage is this? I am not sure, I feel like the stage numbering
> never quite got finished :-)
>
> possibly stage 3 is load payload, stage 4 is pr
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer "hailfinger" checked in revision 3089 to
the coreboot source repository and caused the following
changes:
Change Log:
Factor out print_conf() from Geode LX mainboard directories. The
following mainboard
Author: hailfinger
Date: 2008-02-05 10:21:46 +0100 (Tue, 05 Feb 2008)
New Revision: 3089
Modified:
trunk/coreboot-v2/src/mainboard/amd/db800/mainboard.c
trunk/coreboot-v2/src/mainboard/amd/norwich/mainboard.c
trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/mainboard.c
trunk/core
Author: hailfinger
Date: 2008-02-05 10:21:46 +0100 (Tue, 05 Feb 2008)
New Revision: 3089
Modified:
trunk/coreboot-v2/src/mainboard/amd/db800/mainboard.c
trunk/coreboot-v2/src/mainboard/amd/norwich/mainboard.c
trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/mainboard.c
trunk/core
62 matches
Mail list logo
