Re: [coreboot] coreboot and MSM800BEV
On 1/15/10 12:57 AM, Peter Stuge wrote: Unfortunately, msrtool is not currently available as payload, but perhaps coreinfo can be used to display MSRs? (It would be nice to have msrtool diff mode available in coreinfo, using a file stored in cbfs for comparison!) I think a diff mode would be better implemented in msrtool itself -- If the machine is able to boot coreinfo, it's quite likely already that it can also boot a kernel. If not, you're stuck with printk debugging anyways. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Seabios problems
Hello, I wanted to upgrade my seabios version, but some troubles arrived. 0.5.0 : keyboard timeout problem (I think) error: ps2_recvbyte timeout keyboard self test failed (got e0 not 0xaa) 0.5.1 : same problem as 0.5.0 and Vista don't want to boot I don't have any problems with my previous version pre-0.4.3. I run coreboot rev5007 on my asus m2v-mx_se. Does anyone report those troubles before ? Thanks in advance for your help. Vous n’avez pas encore adressé vos voeux ? Retrouvez nos cartes sur http://carte-de-voeux.voila.fr -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Best way to use crossgcc
Hello, What is the best way to build programs using the crossgcc tool? I just added something like: export PATH=$PATH:/path/to/crossgcc/bin to my .bashrc in my home directory. It seems to work ok, but is that the best way to use it? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Best way to use crossgcc
Am 15.01.2010 15:44, schrieb Joseph Smith: Hello, What is the best way to build programs using the crossgcc tool? I just added something like: export PATH=$PATH:/path/to/crossgcc/bin to my .bashrc in my home directory. It seems to work ok, but is that the best way to use it? abuild and kconfig look for the crossgcc build in the coreboot-v2 directory. So if you're using these, they should pick up a built crossgcc automatically. Otherwise, your solution is the best in my opinion. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Trac reminder: list of new ticket(s)
Ticket Owner Status Description #154 carldani new Flashing BIOSes from Fujitsu/Siemens is not supported #153 stepan new resume from suspend on epia-m #152 carldani new v3 Geode cs5536 UART2 wrongly configured #150 somebody new AMD DB800 dev board PLL strapping leaves CPU and GLIU in non-optimal clock #149 somebody new AMD DB800 Hangs at "Decompressing Coreboot to Ram" #148 somebody new Component defaults to adlo for new tickets in the tracker #147 somebody new Linux kernel halts when scanning the PCI bus below 0:14.4 on RS690 #146 somebody new memalign faild with 4k boundary #145 somebody new Fix CMOS handling #144 somebody new TYAN S7012 support #143 oxygene new unify intel car for model_6[ef]x #142 somebody new remove #warnings in the code #141 somebody new flashrom: Warn the user when trying to read/write chips which are bigger than what the chipset can decode #140 somebody new flashrom: Consistently use stderr for error printing #139 somebody new flashrom: -c option should be case insensitive #135 new Flashrom deletes MAC addresses on Tyan Tomcat n3400B (S2925-E) #133 somebody new Create a typical failures FAQ #130 somebody new flashrom segfault (with backtrace) #129 stepan new Add support for high_tables_base for all chipsets that don't support it yet. #128 somebody new Improve email user interface for trac #125 somebody new BCM5785 / HT1000 reset functions #123 somebody new layout file #119 somebody new Winbond W39V040FBPZ is not written correctly by flashrom #113 somebody new flashrom -c does not accept vendor+chip name, only chip name #111 somebody new Add i18n support for translating strings e.g. for bayou / coreinfo #110 somebody new Allow for per-device subsystem IDs #108 somebody new Add int 10 VESA video driver to libpayload #104 stuge new flashrom: Partial operations; change flash drivers to not erase in the write function #101 stuge new flashrom: Remove pciutils check from Makefile #82 oxygene new Fix the memory map in coreboot v3 #77 somebody new hang on the "Jumping to coreboot" step on via epia-m with 4-chip 128Mbyte DDR module #76 rminnich new coreboot messages should be accessible in dmesg #65 uwe new Unify SuperIO code? #45 somebody new Enforce consistent coding style #43 stepan new Add graphics memory hole to e820 map #28 somebody new Finish Intel 440BX port #25 somebody new Clean up x86 emulator in the tree? #24 somebody new Remove all files which have a GPL-incompatible license #18 somebody new autoprobe apic cluster and application processors on K8 systems #17 stepan new clean up coreboot table handling #16 ollie new I2C driver and mainboard Config.lb #11 yhlu new pirq table automation #8 uwe new Fully support all components of the ITE Super I/Os #5 uwe new Add license header to all source files #2 somebody new Complete tables of supported motherboards -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Expresscard Booting Support
Gentlemen, Can Coreboot support multiple PCMCIA ExpressCards like an 8 raid setup. Will it support hot swap, hot plug-n-play and auto-configuration. Will it enable booting an OS from an Expresscard. Will it support advance Expresscard support. All other Bios Firmware makers are way behind in supporting the most underrated and versatile computer I/O known to man. Can coreboot be configured for this support or does it already support those feature? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [MSRTOOL][PATCH] Add Geode GX2 processor support.
Stefan, Thanks for the review and commit ! Nils. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5008 - trunk/util/msrtool
s...@coreboot.org wrote: Support for the AMD Geode GX2 Processors to Msrtool. It seems to work as it was tested Please do not accept it seems to work for new register descriptions, always review them against the available documentation. Thanks. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Piotr Piwko wrote:
./msrtool 0x20{18,19,1a,1b,1c,1d} 0x4c{0f,14}
OK, here is my output:
0x2018 = 0x100770144840
0x2019 = 0x18006a7332a3
0x201a = 0x130cd101
0x201b = 0x
0x201c = 0x00ff00ff
0x201d = 0x1000
0x4c0f = 0x83f100aa569603c4
0x4c14 = 0x049c07de000c
I am going to analyze it ...
If msrtool didn't decode these for you then that's a bug. Did you get
something similar to the following output?
# MC_CF07_DATA 0x2018 = 0x100770144840
# 63:60 D1_SZ DIMM1 Size = 0001: 8 MB
#56 D1_MB DIMM1 Module Banks = 0: 1 Module bank
#52 D1_CB DIMM1 Component Banks = 0: 2 Component banks
# 50:48 D1_PSZ DIMM1 Page Size = 111: DIMM1 Not Installed
# 47:44 D0_SZ DIMM0 Size = 0111: 512 MB
#40 D0_MB DIMM0 Module Banks = 0: 1 Module bank
#36 D0_CB DIMM0 Component Banks = 1: 4 Component banks
# 34:32 D0_PSZ DIMM0 Page Size = 100: 16 KB
# 29:28 MSR_BA Mode Register Set Bank Address = 00: Program the DIMM Mode
Register
#27 RST_DLL Mode Register Reset DLL = 0: Do not reset DLL
#26 EMR_QFC Extended Mode Register FET Control = 0: Enable
#25 EMR_DRV Extended Mode Register Drive Strength Control = 0: Normal
#24 EMR_DLL Extended Mode Register DLL = 0: Enable
# 23:8 REF_INT Refresh Interval = 72
# 7:4 REF_STAG Refresh Staggering = 4
# 3 REF_TST Test Refresh = 0
# 1 SOFT_RST Software Reset = 0
# 0 PROG_DRAM Program Mode Register in SDRAM = 0
# MC_CF8F_DATA 0x2019 = 0x18006a7332a3
# 63:56 STALE_REQ GLIU Max Stale Request Count = 24
# 52:51 XOR_BIT_SEL XOR Bit Select = 00: ADDR[18]
#50 XOR_MB0 XOR MB0 Enable = 0: Disabled
#49 XOR_BA1 XOR BA1 Enable = 0: Disabled
#48 XOR_BA0 XOR BA0 Enable = 0: Disabled
#41 TRUNC_DIS Burst Truncate Disable = 0: Bursts Enabled
#40 REORDER_DIS Reorder Disable = 0: Reordering Enabled
#33 HOI_LOI High / Low Order Interleave Select = 0: Low Order Interleave
#31 THZ_DLY tHZ Delay = 0
# 30:28 CAS_LAT Read CAS Latency = 110: 2.5
# 27:24 ACT2ACTREF ACT to ACT/REF Period. tRC = 10
# 23:20 ACT2PRE ACT to PRE Period. tRAS = 7
# 18:16 PRE2ACT PRE to ACT Period. tRP = 3
# 14:12 ACT2CMD Delay Time from ACT to Read/Write. tRCD = 3
# 11:8 ACT2ACT ACT(0) to ACT(1) Period. tRRD = 2
# 7:6 DPLWR Data-in to PRE Period. tDPLW = 2: 2
# 5:4 DPLRD Data-in to PRE Period. tDPLR = 2: 2
# MC_CF1017_DATA 0x201a = 0x130cd101
# 29:28 WR_TO_RD Write to Read Delay. tWTR = 1
# 26:24 RD_TMG_CTL Read Timing Control = 3
# 20:16 REF2ACT Refresh to Activate Delay. tRFC = 12
# 15:8 PM1_UP_DLY PMode1 Up Delay = 209
# 2:0 WR2DAT Write Command to Data Latency = 1: 1-clock delay for unbuffered
DIMMs
# MC_CFPERF_CNT1 0x201b = 0x
# 63:32 CNT0 Counter 0 = 0
# 31:0 CNT1 Counter 1 = 0
# MC_PERFCNT2 0x201c = 0x00ff00ff
#35 STOP_CNT1 Stop Counter 1 = 0
#34 RST_CNT1 Reset Counter 1 = 0
#33 STOP_CNT0 Stop Counter 0 = 0
#32 RST_CNT0 Reset Counter 0 = 0
# MC_CFCLK_DBUG 0x201d = 0x1000
#34 B2B_DIS Back-to-Back Command Disable = 0: Allow back-to-back commands
#33 MTEST_RBEX_EN MTEST RBEX Enable = 0: Disable
#32 MTEST_EN MTEST Enable = 0: Disable
#16 FORCE_PRE Force Precharge-all = 0: Disable
#12 TRISTATE_DIS TRI-STATE Disable = 1: Tri-stating disabled
# 9 MASK_CKE1 CKE1 Mask = 0: CKE1 output enable unmasked
# 8 MASK_CKE0 CKE0 Mask = 0: CKE0 output enable unmasked
# 7 CNTL_MSK1 Control Mask 1 = 0: DIMM1 CAS1# RAS1# WE1# CS[3:2]# output
enable unmasked
# 6 CNTL_MSK0 Control Mask 0 = 0: DIMM0 CAS0# RAS0# WE0# CS[1:0]# output
enable unmasked
# 5 ADRS_MSK Address Mask = 0: MA and BA output enable unmasked
# GLCP_DELAY_CONTROLS 0x4c0f = 0x83f100aa569603c4
#63 EN Enable = 1: Use value in bits [62:0]
#62 B_DQ Buffer Control for DQ DQS DQM TLA drive = 0: Quarter power
#61 B_CMD Buffer Control for RAS CAS CKE CS WE drive = 0: Quarter power
#60 B_MA Buffer Control for MA BA drive = 0: Half power
#59 SDCLK_SET SDCLK Setup = 0: Full SDCLK setup
# 58:56 DDR_RLE DDR read latch enable position = 3
#55 SDCLK_DIS SDCLK disable [1,3,5] = 1: SDCLK[0,2,4] output only
# 54:52 TLA1_OA TLA hint pin output adjust = 7
# 51:50 D_TLA1 Output delay for TLA1 = 0
# 49:48 D_TLA0 Output delay for TLA0 = 1
# 47:46 D_DQ_E Output delay for DQ DQM - even byte lanes = 0
# 45:44 D_DQ_O Output delay for DQ DQM - odd byte lanes = 0
# 41:40 D_SDCLK Output delay for SDCLK = 0
# 39:38 D_CMD_O Output delay for CKE CS RAS CAS WE - odd bits = 2
# 37:36 D_CMD_E Output delay for CKE CS RAS CAS WE - even bits = 2
# 35:34 D_MA_O Output delay for BA MA - odd bits = 2
# 33:32 D_MA_E Output delay for BA MA - even bits = 2
# 31:30 D_PCI_O Output delay for pci_ad IRQ13 SUSPA# INTA# - odd bits = 1
# 29:28 D_PCI_E Output delay for pci_ad IRQ13 SUSPA# INTA# - even bits = 1
# 27:26 D_DOTCLK Output delay for DOTCLK = 1
# 25:24 D_DRGB_O Output delay for DRGB[31:0]
Re: [coreboot] [commit] r5008 - trunk/util/msrtool
On 1/15/10 8:20 PM, Peter Stuge wrote: s...@coreboot.org wrote: Support for the AMD Geode GX2 Processors to Msrtool. It seems to work as it was tested Please do not accept it seems to work for new register descriptions, always review them against the available documentation. Thanks. I figured nobody has the time to check this, not even the author of msrtool. Should someone ever use this code on a Geode GX2 system again, the code is there and can be improved now. That's much better than annoying contributors and letting contributions going down the drain. Thank you. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5008 - trunk/util/msrtool
Stefan Reinauer wrote: Please do not accept it seems to work for new register descriptions, I figured nobody has the time to check this, not even the author of msrtool. Someone else using GX2 might hav been motivated (though they didn't speak up so far) or after the reminder maybe someone completely without experience in coreboot could use this as a way to get involved a little bit more. I tried to encourage this, but I could probably have been more clear. No doubt that it's difficult to have good quality reviews happen quickly enough when not many people seem to be interested. Should someone ever use this code on a Geode GX2 system again, the code is there and can be improved now. My point is that users of the tools should not have to start by reviewing them. The tools are much less useful if we developers haven't tried our best to make them correct. Especially something brain-damaging as copying register descriptions from a data sheet can really benefit from reviews. That's much better than annoying contributors and letting contributions going down the drain. This is also a good point. Thanks. The balance between strict code review and accomodating contributions+contributors is a hard one. Might it be useful to have a please-review branch, in addition to keeping track of submitted patches in patchwork? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [commit] r5008 - trunk/util/msrtool
On Fri, 15 Jan 2010 21:27:15 +0100, Stefan Reinauer ste...@coresystems.de wrote: On 1/15/10 8:20 PM, Peter Stuge wrote: s...@coreboot.org wrote: Support for the AMD Geode GX2 Processors to Msrtool. It seems to work as it was tested Please do not accept it seems to work for new register descriptions, always review them against the available documentation. Thanks. I figured nobody has the time to check this, not even the author of msrtool. Should someone ever use this code on a Geode GX2 system again, the code is there and can be improved now. That's much better than annoying contributors and letting contributions going down the drain. I have a AMD PIC with a GX2 on my todo list:-) -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AMD CAR questions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
While thinking how to implement the resume without memory hole I came cross
following piece of code in AMD CAR:
set_init_ram_access(); /* So we can access RAM from [1M, CONFIG_RAMTOP) */
print_debug(Copying data from cache to RAM -- switching to use RAM as stack...
);
memcopy((void *)((CONFIG_RAMTOP)-CONFIG_DCACHE_RAM_SIZE), (void
*)CONFIG_DCACHE_RAM_BASE, CONFIG_DCACHE_RAM_SIZE);
But! the memory is WB too. Therefore the memcopy _must_ evict some L1 to where?
Please note that this code is executed still with CAR enabled.
I answered this question using the Perf counters:
Dumping perf counters
- Eviction of L2 to system memory (writebacks to system)
1172 - Eviction of data L1 to L2 of all previous states (MOESI)
0b5f - L1 Data Cache Refills from System
Copying data from cache to RAM -- switching to use RAM as stack... Dumping perf
counters II
120b
0b6b
With bit of different counters:
Dumping perf counters
0039 - L2 fills from L1
07e2 - Eviction of data L1 to L2 of all previous states (MOES) - excluding
invalid
0d0f - L1 Data Cache Refills from System (excluding invalid)
Copying data from cache to RAM -- switching to use RAM as stack... Dumping perf
counters II
0143
080e
0d1c
It clearly shows that L2 is used for this kind of things. Was this intended? The
L2 I think contains also the cached ROM code... so situation is bit more
complicated than one can expect.
The patch for this kind of analysis is attached if anyone is interested.
Oh btw I had to add some clobbers to the inline assembly or GCC will not thing
the content of ECX has been changed by inline assembly...
Rudolf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAktQ4V0ACgkQ3J9wPJqZRNWiCACgy6jnD7m0yaj/oEjIUrdbYVkR
B3wAoOEE0t34Nkar21c+Am2PQq9DXcqm
=/D4r
-END PGP SIGNATURE-
Index: cpu/amd/car/post_cache_as_ram.c
===
--- cpu/amd/car/post_cache_as_ram.c (revision 5009)
+++ cpu/amd/car/post_cache_as_ram.c (working copy)
@@ -35,6 +35,7 @@
static void post_cache_as_ram(void)
{
+ msr_t msr;
#if 1
{
@@ -51,6 +52,7 @@
unsigned testx = 0x5a5a5a5a;
print_debug_pcar(testx = , testx);
+
/* copy data from cache as ram to
ram need to set CONFIG_RAMTOP to 2M and use var mtrr instead.
*/
@@ -60,6 +62,27 @@
set_init_ram_access(); /* So we can access RAM from [1M, CONFIG_RAMTOP) */
+ print_debug(Dumping perf counters\r\n);
+
+ msr = rdmsr(0xC0010004);
+ print_debug_hex32(msr.lo);
+ print_debug(\r\n);
+
+ msr = rdmsr(0xC0010005);
+ print_debug_hex32(msr.lo);
+ print_debug(\r\n);
+
+ msr = rdmsr(0xC0010006);
+ print_debug_hex32(msr.lo);
+ print_debug(\r\n);
+
+ msr = rdmsr(0xC0010007);
+ print_debug_hex32(msr.lo);
+ print_debug(\r\n);
+
+
+
+
// dump_mem(CONFIG_DCACHE_RAM_BASE+CONFIG_DCACHE_RAM_SIZE-0x8000, CONFIG_DCACHE_RAM_BASE+CONFIG_DCACHE_RAM_SIZE-0x7c00);
print_debug(Copying data from cache to RAM -- switching to use RAM as stack... );
@@ -89,14 +112,39 @@
/* We can put data to stack again */
+ __asm__ __volatile__ ( :
+ :
+ : cc, memory, %eax, %ebx, %ecx, %edx, %esi, %edi, %ebp);
+ print_debug(Dumping perf counters II\r\n);
+
+ msr = rdmsr(0xC0010004);
+ print_debug_hex32(msr.lo);
+ print_debug(\r\n);
+
+ msr = rdmsr(0xC0010005);
+ print_debug_hex32(msr.lo);
+ print_debug(\r\n);
+
+ msr = rdmsr(0xC0010006);
+ print_debug_hex32(msr.lo);
+ print_debug(\r\n);
+
+ msr = rdmsr(0xC0010007);
+ print_debug_hex32(msr.lo);
+ print_debug(\r\n);
+
+
+
+print_debug(Done\r\n);
+
/* only global variable sysinfo in cache need to be offset */
-print_debug(Done\r\n);
print_debug_pcar(testx = , testx);
print_debug(Disabling cache as ram now \r\n);
disable_cache_as_ram_bsp();
+
print_debug(Clearing initial memory region: );
clear_init_ram(); //except the range from [(CONFIG_RAMTOP) - CONFIG_DCACHE_RAM_SIZE, (CONFIG_RAMTOP))
print_debug(Done\r\n);
Index: mainboard/asus/m2v-mx_se/cache_as_ram_auto.c
===
--- mainboard/asus/m2v-mx_se/cache_as_ram_auto.c (revision 5009)
+++ mainboard/asus/m2v-mx_se/cache_as_ram_auto.c (working copy)
@@ -236,7 +236,43 @@
}
+ print_debug(Programming perf and clear counters\r\n);
+{
+ msr_t msr;
+ //PerfCtr0PerfCtr3 Registers C001_0004h, C001_0005h, C001_0006h, C001_0007h
+ //PerfEvtSel0PerfEvtSel3 Registers C001_h, C001_0001h,
+// C001_0002h, C001_0003h
+ msr.hi = 0;
+ msr.lo = 0;
+ wrmsr(0xC0010004, msr);
+ wrmsr(0xC0010005, msr);
+ wrmsr(0xC0010006, msr);
+ wrmsr(0xC0010007, msr);
+ msr.lo = (122) | (1 17) | 0x7f | (0x1 8);
+ wrmsr(0xC001, msr);
+ msr.lo = (122) | (1 17) | 0x44 | (0x1e
Re: [coreboot] #133: Create a typical failures FAQ
#133: Create a typical failures FAQ +--- Reporter: stuge| Owner: somebody Type: enhancement |Status: closed Priority: major| Milestone: Component: flashrom | Version: Resolution: fixed| Keywords: faq documentation debug Dependencies: | Patchstatus: there is no patch +--- Changes (by hailfinger): * status: new = closed * resolution: = fixed Comment: AFAICS the flashrom documentation about this is now good enough. -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/133#comment:2 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #123: layout file
#123: layout file +--- Reporter: viva...@…| Owner: somebody Type: defect |Status: closed Priority: major| Milestone: flashrom v1.0 Component: flashrom | Version: v2 Resolution: fixed| Keywords: layout address offset Dependencies: | Patchstatus: there is no patch +--- Changes (by hailfinger): * status: new = closed * resolution: = fixed -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/123#comment:2 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #119: Winbond W39V040FBPZ is not written correctly by flashrom
#119: Winbond W39V040FBPZ is not written correctly by flashrom -+-- Reporter: charles.hern...@… | Owner: somebody Type: enhancement| Status: new Priority: minor | Milestone: flashrom v1.1 Component: flashrom |Version: v2 Keywords: W39V040FBPZ| Dependencies: Patchstatus: there is no patch | -+-- Comment(by hailfinger): Something I noticed just now: Charles, you mentioned W39V040FB (FWH) in the summary, but your log says W39V040B (LPC). We did fix one critical timing error for the W39V040B, so this may be solved in current flashrom from svn. A retest would be appreciated. -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/119#comment:6 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #103: flashrom: Add -T to test all operations in one invocation (was: flashrom: Don't exit() after successful erase; enable testing all operations in one invocation)
#103: flashrom: Add -T to test all operations in one invocation -+-- Reporter: stuge | Owner: hailfinger Type: enhancement| Status: new Priority: major | Milestone: flashrom v1.0 Component: flashrom |Version: Keywords: testing| Dependencies: #117 Patchstatus: there is no patch | -+-- Changes (by hailfinger): * keywords: erase exit testing = testing * owner: stuge = hailfinger * patchstatus: patch needs work = there is no patch * status: assigned = new Comment: Given that chips now support multiple erase functions, testing is way more complicated. We need a separate -T, everything else will only give us incomplete test reports. -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/103#comment:12 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #106: flashrom: Add -T to automatically test all flash chip operations
#106: flashrom: Add -T to automatically test all flash chip operations +--- Reporter: stuge| Owner: somebody Type: enhancement |Status: closed Priority: major| Milestone: flashrom v1.0 Component: flashrom | Version: Resolution: duplicate| Keywords: testing Dependencies: | Patchstatus: there is no patch +--- Changes (by hailfinger): * status: reopened = closed * resolution: = duplicate Comment: Flashrom now has a partial test infrastructure (among others, it can generate test patterns for write). The rest of this ticket is indeed a dup of #103. -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/106#comment:6 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD CAR questions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for the analysis. I can see it being useful for other things too.
Ok.
My understanding was that CAR refers to L2. As long as nothing gets
replaced from the L2, everything is as it should be. ROM contents can
always be fetched again, so that's not critical for correctness.
This is OK, but L2 CAR is in more detail described in fam11h otherwise AMD
always just speaks about L1 CAR. the fam11h needs some extra tweaks to various
MSR to disables speculative fills if I remember correctly. This is the reason
why I see this a bit dangerous, perhaps older CPUs needs this too.
I think we should mark the XIP region as WP instead of WB (check the fam11h
BKDG).
Anyway - I tried with UC copy looks like it is not so slow...
I have in works the patch for the register clobber cleanup plus I will do some
patch for saving the coreboot mem to resume area... but perhaps on Sunday.
Tomorrow bit of skiing, but if you are curious, here is the patch. It just fixes
the clobber stuff for the assembly routines, it has bitten me already while
dumping the MSRs... the ECX value contained some garbage, and rdmsr did some
exception.
The memcpy code is from Linux kernel.
Rudolf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAktQ/pkACgkQ3J9wPJqZRNV5OACghwX5yZFScyo24Pzkt66pgHta
2VIAoNryS9EX/JZpGcu4NJ3IpEVnbK/8
=IRfx
-END PGP SIGNATURE-
Index: disable_cache_as_ram.c
===
--- disable_cache_as_ram.c (revision 5009)
+++ disable_cache_as_ram.c (working copy)
@@ -2,62 +2,49 @@
/* be warned, this file will be used other cores and core 0 / node 0 */
static inline __attribute__((always_inline)) void disable_cache_as_ram(void)
{
-
-__asm__ volatile (
-
+__asm__ __volatile__ (
/* We don't need cache as ram for now on */
/* disable cache */
-movl%cr0, %eax\n\t
-orl$(0x130),%eax\n\t
-movl%eax, %cr0\n\t
+movl%%cr0, %%eax\n\t
+orl$(0x130),%%eax\n\t
+movl%%eax, %%cr0\n\t
/* clear sth */
-movl$0x269, %ecx\n\t /* fix4k_c8000*/
-xorl%edx, %edx\n\t
-xorl%eax, %eax\n\t
+movl$0x269, %%ecx\n\t /* fix4k_c8000*/
+xorl%%edx, %%edx\n\t
+xorl%%eax, %%eax\n\t
wrmsr\n\t
#if CONFIG_DCACHE_RAM_SIZE 0x8000
- movl$0x268, %ecx\n\t /* fix4k_c*/
+ movl$0x268, %%ecx\n\t /* fix4k_c*/
wrmsr\n\t
#endif
/* disable fixed mtrr from now on, it will be enabled by coreboot_ram again*/
-movl$0xC0010010, %ecx\n\t
+movl$0xC0010010, %%ecx\n\t
//movl$SYSCFG_MSR, %ecx\n\t
rdmsr\n\t
-andl$(~(318)), %eax\n\t
+andl$(~(318)), %%eax\n\t
//andl$(~(SYSCFG_MSR_MtrrFixDramModEn | SYSCFG_MSR_MtrrFixDramEn)), %eax\n\t
wrmsr\n\t
/* Set the default memory type and disable fixed and enable variable MTRRs */
-movl$0x2ff, %ecx\n\t
+movl$0x2ff, %%ecx\n\t
//movl$MTRRdefType_MSR, %ecx\n\t
-xorl%edx, %edx\n\t
+xorl%%edx, %%edx\n\t
/* Enable Variable and Disable Fixed MTRRs */
-movl$0x0800, %eax\n\t
+movl$0x0800, %%eax\n\t
wrmsr\n\t
/* enable cache */
-movl%cr0, %eax\n\t
-andl$0x9fff,%eax\n\t
-movl%eax, %cr0\n\t
-
+movl%%cr0, %%eax\n\t
+andl$0x9fff,%%eax\n\t
+movl%%eax, %%cr0\n\t
+::: memory, eax, ecx, edx
);
}
static void disable_cache_as_ram_bsp(void)
{
- __asm__ volatile (
-// pushl %eax\n\t
- pushl %edx\n\t
- pushl %ecx\n\t
- );
-
disable_cache_as_ram();
-__asm__ volatile (
-popl %ecx\n\t
-popl %edx\n\t
-//popl %eax\n\t
-);
}
Index: post_cache_as_ram.c
===
--- post_cache_as_ram.c (revision 5009)
+++ post_cache_as_ram.c (working copy)
@@ -12,12 +12,16 @@
static void inline __attribute__((always_inline)) memcopy(void *dest, const void *src, unsigned long bytes)
{
-__asm__ volatile(
-cld\n\t
-rep; movsl\n\t
-: /* No outputs */
-: S (src), D (dest), c ((bytes)2)
-);
+ int d0, d1, d2;
+ asm volatile(cld ; rep ; movsl\n\t
+ movl %4,%%ecx\n\t
+ andl $3,%%ecx\n\t
+ jz 1f\n\t
+ rep ; movsb\n\t
+ 1:
+ : =c (d0), =D (d1), =S (d2)
+ : 0 (bytes / 4), g (bytes), 1 ((long)dest), 2 ((long)src)
+ : memory, cc);
}
/* Disable Erratum 343 Workaround, see RevGuide for Fam10h, Pub#41322 Rev 3.33 */
@@ -66,28 +70,16 @@
/* from here don't store more data in CAR */
vErrata343();
-#if 0
-
Re: [coreboot] #101: flashrom: Remove pciutils check from Makefile
coreboot wrote: * resolution: = fixed Comment: This has been solved by making the libpci check conditional on actually needing libpci (i.e. not for the serial and USB and dummy flashers). I disagree with this. The point was to create a configure script and check for pciutils one time only. But whatever. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD CAR questions
My understanding was that CAR refers to L2. As long as nothing gets replaced from the L2, everything is as it should be. ROM contents can always be fetched again, so that's not critical for correctness. This is OK, but L2 CAR is in more detail described in fam11h otherwise AMD always just speaks about L1 CAR. the fam11h needs some extra tweaks to various MSR to disables speculative fills if I remember correctly. This is the reason why I see this a bit dangerous, perhaps older CPUs needs this too. I think we should mark the XIP region as WP instead of WB (check the fam11h BKDG). I wish I knew more about it. I haven't done much with fam10h or anything with fam11h. Anyway - I tried with UC copy looks like it is not so slow... I have in works the patch for the register clobber cleanup plus I will do some patch for saving the coreboot mem to resume area... but perhaps on Sunday. Tomorrow bit of skiing, but if you are curious, here is the patch. It just fixes the clobber stuff for the assembly routines, it has bitten me already while dumping the MSRs... the ECX value contained some garbage, and rdmsr did some exception. Good catch! Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD CAR questions
It clearly shows that L2 is used for this kind of things. Was this intended? The L2 I think contains also the cached ROM code... so situation is bit more complicated than one can expect. Thanks for the analysis. I can see it being useful for other things too. My understanding was that CAR refers to L2. As long as nothing gets replaced from the L2, everything is as it should be. ROM contents can always be fetched again, so that's not critical for correctness. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #120: flashrom: ICH SPI Hardware Sequencing
#120: flashrom: ICH SPI Hardware Sequencing -+-- Reporter: t...@… | Owner: stuge Type: enhancement| Status: assigned Priority: major | Milestone: flashrom v1.0 Component: flashrom |Version: Keywords: ich9 spi | Dependencies: Patchstatus: there is no patch | -+-- Comment(by stuge): Cleanup is great - just a note that the patch doesn't implement hardware sequencing. -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/120#comment:25 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #104: flashrom: Partial operations; change flash drivers to not erase in the write function
#104: flashrom: Partial operations; change flash drivers to not erase in the write function ---+ Reporter: stuge| Owner: hailfinger Type: enhancement | Status: new Priority: major| Milestone: flashrom v1.0 Component: flashrom |Version: Keywords: partial erase write | Dependencies: Patchstatus: there is no patch| ---+ Comment(by stuge): I could ack the patch since it just adds a function, but the function doesn't fix this ticket. This ticket is about changing write functions in drivers to never erase. (Ie. move erasing out of the driver write functions.) Once that's done (if already, then this could be closed as fixed) the next step is how to decide when to erase. It used to be always. Patch 582 suggest a heuristic, but I don't think this is wise, since code can not know what has happened to the flash chip before. I suggest that this decision must be made by the user. -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/104#comment:12 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #104: flashrom: Partial operations; change flash drivers to not erase in the write function
#104: flashrom: Partial operations; change flash drivers to not erase in the write function ---+ Reporter: stuge| Owner: hailfinger Type: enhancement | Status: new Priority: major| Milestone: flashrom v1.0 Component: flashrom |Version: Keywords: partial erase write | Dependencies: Patchstatus: there is no patch| ---+ Comment(by hailfinger): Yes, patch 582 is just a part of the solution, but I think it is a prerequisite to solve this completely. The idea behind patch 582 is to annotate struct flashchip with erase granularity (separate patch!) and use that info and patch 582 to determine whether we need an erase or not. The removal of unconditional erase is halfway done. A few chips remain, but Sean Nelson is tackling them right now. -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/104#comment:13 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #101: flashrom: Remove pciutils check from Makefile
On 16.01.2010 00:55, Peter Stuge wrote: coreboot wrote: * resolution: = fixed Comment: This has been solved by making the libpci check conditional on actually needing libpci (i.e. not for the serial and USB and dummy flashers). I disagree with this. The point was to create a configure script and check for pciutils one time only. I may have misunderstood the point of the bug in that case. Sorry about that. Quoting from the original bug description: the check also claims that packages can not be found for any build error, which is not good enough. The code changed months ago to fix this issue, and since that was 72% of the bug description text, I felt it was appropriate to close the bug. Side note: Last time I tried to split up Makefile into Makefile and configure, there was strong opposition against that idea. I do listen to others, and since it works for users right now (and is admittedly easier to use), it is unlikely that such a split will happen. Feel free to open a ticket for this, preferably in flashrom trac at http://www.flashrom.org/trac/flashrom/newticket Regards, Carl-Daniel -- Developer quote of the year: We are juggling too many chainsaws and flaming arrows and tigers. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #104: flashrom: Partial operations; change flash drivers to not erase in the write function
#104: flashrom: Partial operations; change flash drivers to not erase in the write function ---+ Reporter: stuge| Owner: hailfinger Type: enhancement | Status: new Priority: major| Milestone: flashrom v1.0 Component: flashrom |Version: Keywords: partial erase write | Dependencies: Patchstatus: there is no patch| ---+ Comment(by stuge): Yes, granularity was coded into write functions and should absolutely go into structured data instead. That patch I'll gladly ack if needed. But I still think erase-or-not must be a user decision rather than a heuristic. -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/104#comment:14 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #104: flashrom: Partial operations; change flash drivers to not erase in the write function
#104: flashrom: Partial operations; change flash drivers to not erase in the write function ---+ Reporter: stuge| Owner: hailfinger Type: enhancement | Status: new Priority: major| Milestone: flashrom v1.0 Component: flashrom |Version: Keywords: partial erase write | Dependencies: Patchstatus: there is no patch| ---+ Comment(by hailfinger): Could you please elaborate on what you mean with heuristic? It seems we are talking about different things and I want to understand your point. AFAICT flashrom should arrive at the desired image (i.e. what the user wants) with the minimal amount (may be zero) of erases. For that, we need write granularity info about the chip. Asking the user to look that up in the datasheet is doable, but not optimal. Flashrom should know that information (not by guessing or heuristic, but by hard info from the datasheet). For convenience, there could be a flashrom option do not erase even if the chip datasheet explicitly mentions that this write will not work without preceding erase. -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/104#comment:15 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #104: flashrom: Partial operations; change flash drivers to not erase in the write function
#104: flashrom: Partial operations; change flash drivers to not erase in the write function ---+ Reporter: stuge| Owner: hailfinger Type: enhancement | Status: assigned Priority: major| Milestone: flashrom v1.0 Component: flashrom |Version: Keywords: partial erase write | Dependencies: Patchstatus: there is no patch| ---+ Changes (by hailfinger): * status: new = assigned -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/104#comment:16 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] #104: flashrom: Partial operations; change flash drivers to not erase in the write function
#104: flashrom: Partial operations; change flash drivers to not erase in the write function ---+ Reporter: stuge| Owner: hailfinger Type: enhancement | Status: assigned Priority: major| Milestone: flashrom v1.0 Component: flashrom |Version: Keywords: partial erase write | Dependencies: Patchstatus: there is no patch| ---+ Comment(by stuge): If current flash bits look like we might be able to write without erase is a heuristic and since it's impossible to know how many times the flash chip has already been written to in order to get the current contents a heuristic isn't useful. -- Ticket URL: http://tracker.coreboot.org/trac/coreboot/ticket/104#comment:17 coreboot http://www.coreboot.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Seabios problems
On Fri, Jan 15, 2010 at 02:27:39PM +0100, conged...@voila.fr wrote: Hello, I wanted to upgrade my seabios version, but some troubles arrived. 0.5.0 : keyboard timeout problem (I think) error: ps2_recvbyte timeout keyboard self test failed (got e0 not 0xaa) 0.5.1 : same problem as 0.5.0 and Vista don't want to boot I don't have any problems with my previous version pre-0.4.3. I run coreboot rev5007 on my asus m2v-mx_se. Does anyone report those troubles before ? I haven't seen this reported before. Can you set the debug level to 8 on both the working and non-working versions of SeaBIOS and post the full logs? Thanks, -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
