The attached patch adds a register table for the IT8500 embedded controller.
Here is a sample of the output:
superiotool r5679
Found ITE IT8500 (id=0x8500, rev=0x1) at 0x2e
Register dump:
idx 20 21 22 23 25 2d 2e 2f 30
val 85 00 01 01 00 00 00 00 01
def 85 00
On 8/10/10 4:26 AM, donald.hu...@ite.com.tw wrote:
The attached patch adds a register table for the IT8500 embedded
controller. Here is a sample of the output:
superiotool r5679
[..]
Signed-off by: Donald Huang (donald.hu...@ite.com.tw
mailto:donald.hu...@ite.com.tw)
Signed-off by:
On 8/9/10 11:41 PM, David Hendricks wrote:
Some chips do not require enter/exit sequences. This causes them to be
detected and printed multiple times in probe_idregs_* functions where
a simple series of enter -- probe/print -- exit calls are made.
This patch adds a simple check after each
Dear Stefan,
OK!
Please see the attached file.
BR,
Donald
From: Stefan Reinauer [mailto:stefan.reina...@coresystems.de]
Sent: Tuesday, August 10, 2010 2:47 PM
To: Donald Huang (黃麒豪)
Cc: coreboot@coreboot.org; dhend...@google.com; yj...@google.com
ljmp $ROM_CODE_SEG, $protected_stage0
Where is the definition of the symbol, protected_stage0?
Thank you to read my message.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 8/10/10 3:24 PM, ali hagigat wrote:
ljmp $ROM_CODE_SEG, $protected_stage0
Where is the definition of the symbol, protected_stage0?
Thank you to read my message.
The file you are looking at, src/arch/i386/init/entry.S is unused. The
file was supposed to replace
On Tue, Aug 10, 2010 at 5:43 AM, Oskar Enoksson e...@lysator.liu.se wrote:
Myles Watson wrote:
On Mon, Aug 9, 2010 at 8:16 AM, Myles Watson myle...@gmail.com wrote:
On Sat, Aug 7, 2010 at 9:57 AM, Oskar Enoksson e...@lysator.liu.se wrote:
Ok, I'm able to hotswap the BIOS chip, burn it and
update:
dongle.py -c /dev/term/1 $(obj)/coreboot.rom EOF
What was dongle.py in top makefile?
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On 8/10/10 5:06 PM, ali hagigat wrote:
update:
dongle.py -c /dev/term/1 $(obj)/coreboot.rom EOF
What was dongle.py in top makefile?
It's the program controlling this: http://www.coreboot.org/FlexyICE
Unless you have one of those you don't need to worry.
Stefan
--
coreboot
Am 10.08.2010 17:06, schrieb ali hagigat:
update:
dongle.py -c /dev/term/1 $(obj)/coreboot.rom EOF
What was dongle.py in top makefile?
dongle.py is a utility to control the Artec FlexyICE dongle (hence the
name of the tool). The dongle serves as a PLCC emulator, with cuts down
on
My main questions are not answered!
Starting from top makefile, what is first rule that is executed?
How this makefile causes other makefiles inside the subdirectories are
called? Please mention the line which does this.
Thank you.
On Tue, Aug 10, 2010 at 7:41 PM, Patrick Georgi
ali hagigat wrote:
Starting from top makefile, what is first rule that is executed?
I think this depends on which target you are building. Why do you
ask?
How this makefile causes other makefiles inside the subdirectories
are called? Please mention the line which does this.
It's not one
do a make and watch what gets executed. There's no substitute for
observation and interaction with the tool.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Tue, Aug 10, 2010 at 8:43 AM, ali hagigat hagigat...@gmail.com wrote:
My main questions are not answered!
Starting from top makefile, what is first rule that is executed?
How this makefile causes other makefiles inside the subdirectories are
called? Please mention the line which does this.
That IPMI stuff is a huge pain in the neck. You can try to disable it
as I did on the Dell.
src/mainboard/dell/s1850/romstage.c
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Tue, Aug 10, 2010 at 9:03 AM, ron minnich rminn...@gmail.com wrote:
On Tue, Aug 10, 2010 at 8:43 AM, ali hagigat hagigat...@gmail.com wrote:
My main questions are not answered!
Starting from top makefile, what is first rule that is executed?
How this makefile causes other makefiles
Am 10.08.2010 22:40, schrieb David Hendricks:
There's no recursive make.
if only ;-)
The only recursive make in coreboot is when you use the scanbuild
feature. In which case the toplevel Makefile calls itself, wrapped in
scan-build.
Everything else is iterative inclusion of makefile
On Mon, Aug 9, 2010 at 11:47 PM, Stefan Reinauer
stefan.reina...@coresystems.de wrote:
On 8/10/10 4:26 AM, donald.hu...@ite.com.tw wrote:
The attached patch adds a register table for the IT8500 embedded
controller. Here is a sample of the output:
superiotool r5679
[..]
Signed-off
Author: hailfinger
Date: Wed Aug 11 01:34:51 2010
New Revision: 5690
URL: https://tracker.coreboot.org/trac/coreboot/changeset/5690
Log:
Superiotool support for the IT8500 embedded controller.
Signed-off-by: Donald Huang donald.hu...@ite.com.tw
Signed-off-by: Yung-chieh Lo yj...@google.com
On 10.08.2010 10:10, donald.hu...@ite.com.tw wrote:
On 8/10/10 4:26 AM, donald.hu...@ite.com.tw wrote:
The attached patch adds a register table for the IT8500 embedded controller.
Here is a sample of the output:
Signed-off by: Donald Huang (donald.hu...@ite.com.tw)
Signed-off by:
Hi, all
Amd rs780 feature Lane reversal is tested.
Please see the attachment
Thanks
--
Regards
Kerry She kerry@amd.com
amd_rs780_gfx_lane_reversal.patch
Description: amd_rs780_gfx_lane_reversal.patch
--
coreboot mailing list: coreboot@coreboot.org
21 matches
Mail list logo
