Re: [coreboot] coreboot and MSM800BEV
Hello again, I've wrote my own RAM initialization function which based on factory BIOS setting and AMD Geode LX Data Book. Unfortunately it didn't bring any result. As previous, the booting process hangs on executing wbinvd function. I noticed that when I try to write some data into desired stack address range (pointed by CONFIG_CARBASE=0x8 value in .config file) the booting process hangs on it. This situation occurs when I use the coreboot RAM initialization function and my own function as well. It is very strange to me. Could you give me any advice how solve this situation? Thanks in advance for your engagement. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
2010/1/15 Peter Stuge pe...@stuge.se: 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 ... No, I didn't. I just got that lines with information about unrecognized registers. It seems that msrtool doesn't have suitable definitions in its database. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
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
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] coreboot and MSM800BEV
2010/1/13 Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net: On 13.01.2010 15:45, Piotr Piwko wrote: I had removed the the 'wbinvd' cache invalidation function, and then a boot process moved on. Now it hangs on 'FATAL: NO VSA found!' error'. Hm. I know the that piece of v3 code rather well and if wbinvd fails (or your code does unexpected things like hanging after wbinvd) it is a pretty sure sign that RAM is not working correctly. I am almost certain that the RAM memory is not initialized correctly. I wrote a simple RAM test function which writes some pattern data into 0x0 - 0x400 address range and then reads it. The difference occurs already at the first cell. There is 0x00, but should be 0xFF. Conclusion is that RAM initialization for adl/msm800sev target is not valid. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
2010/1/14 Peter Stuge pe...@stuge.se: Piotr Piwko wrote: Anyway, could you provide my any better solution to include the VSA to coreboot image? I believe you're doing it the correct way already. I hope so too :) There is a similar function ram_check() in lib/ramtest.c. Yes, but I don't know how I can force a compilation of /lib/ramtest.c file during building process. Conclusion is that RAM initialization for adl/msm800sev target is not valid. Can you try with several different model DIMMs? It is good hint. I will make some test tomorrow with different model of DIMMs. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
On 1/14/10 8:45 PM, Piotr Piwko wrote: There is a similar function ram_check() in lib/ramtest.c. Yes, but I don't know how I can force a compilation of /lib/ramtest.c file during building process. It already is included in cache_as_ram_auto.c Just add a line ram_check(0x, 0x000a); at the end of cache_as_ram_main() (assuming you use cache as ram) Conclusion is that RAM initialization for adl/msm800sev target is not valid. Can you try with several different model DIMMs? It is good hint. I will make some test tomorrow with different model of DIMMs. You can also try to use SerialICE (http://www.serialice.com) on the target to see how the original BIOS is configuring the RAM controller. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Stefan Reinauer wrote:
I've planned to write the simple application on Linux which will
print values of given registers. Now it is not necessary :)
That might still be worthwhile.
But: Most config registers on Geode are set via MSRs, so you might
get quite far with Peter Stuge's msrtool (coreboot/util/msrtool)
Good point. Try running:
./msrtool 0x20{18,19,1a,1b,1c,1d} 0x4c{0f,14}
in Linux started by factory BIOS. Note that you need /dev/cpu/*/msr
available to run msrtool in Linux. 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!)
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Hello, I had removed the the 'wbinvd' cache invalidation function, and then a boot process moved on. Now it hangs on 'FATAL: NO VSA found!' error'. In order to fix it I've added VSA to my coreboot image by following command: build/util/lar/lar -C lzma -a build/bios.bin ./build/gpl_vsa_lx_102.bin:blob/vsa After that, the boot process hangs on 'Done printk() buffer move'. It seems like the VSA is not placed in a proper place in the whole bios image. Do you know any other possibilities to include the VSA in coreboot image? Thanks in advance for interest. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Piotr Piwko escribió: Hello, I had removed the the 'wbinvd' cache invalidation function, and then a boot process moved on. Now it hangs on 'FATAL: NO VSA found!' error'. In order to fix it I've added VSA to my coreboot image by following command: build/util/lar/lar -C lzma -a build/bios.bin ./build/gpl_vsa_lx_102.bin:blob/vsa After that, the boot process hangs on 'Done printk() buffer move'. It seems like the VSA is not placed in a proper place in the whole bios image. Do you know any other possibilities to include the VSA in coreboot image? Thanks in advance for interest. Hi, I use: ./cbfstool coreboot.rom add vga.bin pci1002,515e.rom 99 and where 1002 is the vendor id (ATI) and 515e the device id (ES1000) obtain from a lspci -tvnn (+-06.0-[01]01.0 ATI Technologies Inc ES1000 [1002:515e]) not sure what 99 is :P. ciao. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
On 13.01.2010 15:45, Piotr Piwko wrote: I had removed the the 'wbinvd' cache invalidation function, and then a boot process moved on. Now it hangs on 'FATAL: NO VSA found!' error'. Hm. I know the that piece of v3 code rather well and if wbinvd fails (or your code does unexpected things like hanging after wbinvd) it is a pretty sure sign that RAM is not working correctly. I can test my GeodeLX systems with current v3 once I get a chance (will take a few weeks, though, because I'm preparing for final exams). 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] coreboot and MSM800BEV
On 12.01.2010 09:35, Piotr Piwko wrote: 2010/1/12 Piotr Piwko piotr.pi...@gmail.com: Did you already try the v3 support for adl/msm800sev? No I didn't. I am just going to try it. Of course, I will report my progress here :) So, here we go :) I attached the first log of coreboot-v3 booting process for adl/msm800sev board. As we can see there are the same errors with SMB. I suppose they are related as previously with the references to DIMM1 which are not present in this board. In the other hand, these lines make me worried: ... LAR: seen member bootbl...@0xafc0, size 20480 LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot ... That error message is harmless. Basically, we usually try fallback first, and if no fallback image is present, we use the normal image. 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] coreboot and MSM800BEV
2010/1/12 Piotr Piwko piotr.pi...@gmail.com: Did you already try the v3 support for adl/msm800sev? No I didn't. I am just going to try it. Of course, I will report my progress here :) So, here we go :) I attached the first log of coreboot-v3 booting process for adl/msm800sev board. As we can see there are the same errors with SMB. I suppose they are related as previously with the references to DIMM1 which are not present in this board. In the other hand, these lines make me worried: ... LAR: seen member bootbl...@0xafc0, size 20480 LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot ... -- Piotr Piwko http://www.embedded-engineering.pl/ coreboot-3.0.1177 Tue Jan 12 09:01:13 CET 2010 starting... (console_loglevel=8) Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff0 len 0x10 LAR: seen member normal/option_ta...@0xfff0, size 1160 LAR: seen member normal/initram/segme...@0xfff004e0, size 6400 LAR: seen member normal/stage2/segme...@0xfff01e30, size 1 LAR: seen member normal/stage2/segme...@0xfff01e90, size 22110 LAR: seen member normal/stage2/segme...@0xfff07540, size 525 LAR: seen member normal/payload/auto.c...@0xfff077a0, size 288 LAR: seen member normal/payload/auto.conf@0xfff07910, size 72 LAR: seen member normal/payload/bootlog_module.o/segme...@0xfff079b0, size 1 LAR: seen member normal/payload/cbfs_module.o/segme...@0xfff07a20, size 1 LAR: seen member normal/payload/confi...@0xfff07a90, size 313 LAR: seen member normal/payload/coreboot_module.o/segme...@0xfff07c20, size 1 LAR: seen member normal/payload/coreinfo.elf/segme...@0xfff07c90, size 1 LAR: seen member normal/payload/coreinfo.elf/segme...@0xfff07d00, size 17883 LAR: seen member normal/payload/coreinfo.o/segme...@0xfff0c340, size 1 LAR: seen member normal/payload/cpuinfo_module.o/segme...@0xfff0c3b0, size 1 LAR: seen member normal/payload/lar_module.o/segme...@0xfff0c420, size 1 LAR: seen member normal/payload/multiboot_module.o/segme...@0xfff0c490, size 1 LAR: seen member normal/payload/pci_module.o/segme...@0xfff0c500, size 1 LAR: seen member normal/payload/ramdump_module.o/segme...@0xfff0c570, size 1 LAR: seen member normal/payload/util/kconfig/lex.zcon...@0xfff0c5e0, size 13315 LAR: seen member normal/payload/util/kconfig/lxdialog/checklist.o/segme...@0xff1 LAR: seen member normal/payload/util/kconfig/lxdialog/menubox.o/segme...@0xfff01 LAR: seen member normal/payload/util/kconfig/lxdialog/textbox.o/segme...@0xfff01 LAR: seen member normal/payload/util/kconfig/lxdialog/util.o/segme...@0xfff0fbd1 LAR: seen member normal/payload/util/kconfig/mconf/segme...@0xfff0fc50, size 1 LAR: seen member normal/payload/util/kconfig/mconf/segme...@0xfff0fcc0, size 360 LAR: seen member normal/payload/util/kconfig/mconf/segme...@0xfff18d00, size 557 LAR: seen member normal/payload/util/kconfig/mconf.o/segme...@0xfff18f90, size 1 LAR: seen member normal/payload/util/kconfig/zconf.has...@0xfff19000, size 1871 LAR: seen member normal/payload/util/kconfig/zconf.ta...@0xfff197b0, size 16212 LAR: seen member normal/payload/util/kconfig/zconf.tab.o/segme...@0xfff1d770, s1 LAR: seen member bootbl...@0xafc0, size 20480 LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. LAR: Start 0xfff0 len 0x10 LAR: seen member normal/option_ta...@0xfff0, size 1160 LAR: seen member normal/initram/segme...@0xfff004e0, size 6400 LAR: CHECK normal/initram/segment0 @ 0xfff004e0 start 0xfff00530 len 6400 reallen 6400 compression 0 entry 0x1206 loadaddre0 Entry point is 0xfff01736 pll_reset: read msr 0x4c14 _MSR GLCP_SYS_RSTPLL (4c14) value is: 0392:180c Configuring PLL Resetting the processor after PLL configuration for the changes to take effect coreboot-3.0.1177 Tue Jan 12 09:01:13 CET 2010 starting... (console_loglevel=8) Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff0 len 0x10 LAR: seen member normal/option_ta...@0xfff0, size 1160 LAR: seen member normal/initram/segme...@0xfff004e0, size 6400 LAR: seen member normal/stage2/segme...@0xfff01e30, size 1 LAR: seen member normal/stage2/segme...@0xfff01e90, size 22110 LAR: seen member normal/stage2/segme...@0xfff07540, size 525 LAR: seen member normal/payload/auto.c...@0xfff077a0, size 288 LAR: seen member normal/payload/auto.conf@0xfff07910, size 72 LAR: seen member normal/payload/bootlog_module.o/segme...@0xfff079b0, size 1 LAR: seen member normal/payload/cbfs_module.o/segme...@0xfff07a20, size 1 LAR: seen member normal/payload/confi...@0xfff07a90, size 313 LAR: seen member normal/payload/coreboot_module.o/segme...@0xfff07c20, size 1 LAR: seen member normal/payload/coreinfo.elf/segme...@0xfff07c90, size 1 LAR: seen member normal/payload/coreinfo.elf/segme...@0xfff07d00, size 17883 LAR:
Re: [coreboot] coreboot and MSM800BEV
2010/1/12 Piotr Piwko piotr.pi...@gmail.com: I attached the first log of coreboot-v3 booting process for adl/msm800sev board. As we can see there are the same errors with SMB. I suppose they are related as previously with the references to DIMM1 which are not present in this board. OK, I fixed it by assigning the DIMM0 device address to the DIMM1 definition in mainboard/adl/msm800sev/initram.c file: //#define DIMM1 ((u8) 0xA2) #define DIMM1 DIMM0 LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot It seems that my coreboot image was built in normal boot mode while it tries use fallback boot. How can I enable the fallback mode in building process or enforce the use of the normal mode in booting process? Thanks in advance, -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
I've found the way to force the normal boot mode in boot process. I just set the RTC_NORMAL_BOOT_FLAG_SET bit in check_normal_boot_flag() function (patch is attached). Now the boot process seems to be ok, but it still hangs on the execution __asm__(wbinvd\n); in main function of mainboard/adl/msm800sev/initram.c file ... (please, see attached log). PS. Let me know if I am too verbose in this thread. I just want to help future users. -- Piotr Piwko http://www.embedded-engineering.pl/ coreboot-3.0.1177 Tue Jan 12 12:24:18 CET 2010 starting... (console_loglevel=8) Choosing normal boot. LAR: Attempting to open 'normal/initram/segment0'. LAR: Start 0xfff0 len 0x10 LAR: seen member normal/option_ta...@0xfff0, size 1160 LAR: seen member normal/initram/segme...@0xfff004e0, size 6464 LAR: CHECK normal/initram/segment0 @ 0xfff004e0 start 0xfff00530 len 6464 reallen 6464 compression 0 entry 0x1206 loadaddre0 Entry point is 0xfff01736 pll_reset: read msr 0x4c14 _MSR GLCP_SYS_RSTPLL (4c14) value is: 0392:180c Configuring PLL Resetting the processor after PLL configuration for the changes to take effect coreboot-3.0.1177 Tue Jan 12 12:24:18 CET 2010 starting... (console_loglevel=8) Choosing normal boot. LAR: Attempting to open 'normal/initram/segment0'. LAR: Start 0xfff0 len 0x10 LAR: seen member normal/option_ta...@0xfff0, size 1160 LAR: seen member normal/initram/segme...@0xfff004e0, size 6464 LAR: CHECK normal/initram/segment0 @ 0xfff004e0 start 0xfff00530 len 6464 reallen 6464 compression 0 entry 0x1206 loadaddre0 Entry point is 0xfff01736 pll_reset: read msr 0x4c14 _MSR GLCP_SYS_RSTPLL (4c14) value is: 0392:07de000c Done pll_reset spd_read_byte dev 00a0 addr 0d returns 08 spd_read_byte dev 00a0 addr 05 returns 01 spd_read_byte dev 00a0 addr 0d returns 08 spd_read_byte dev 00a0 addr 05 returns 01 Done cpubug fixes spd_read_byte dev 00a0 addr 15 returns 20 spd_read_byte dev 00a0 addr 15 returns 20 spd_read_byte dev 00a0 addr 09 returns 60 spd_read_byte dev 00a0 addr 09 returns 60 ddr max speed is 333 == Check present === spd_read_byte dev 00a0 addr 02 returns 07 == MODBANKS spd_read_byte dev 00a0 addr 05 returns 01 == FIELDBANKS == spd_read_byte dev 00a0 addr 11 returns 04 == SPDNUMROWS == spd_read_byte dev 00a0 addr 03 returns 0d spd_read_byte dev 00a0 addr 04 returns 0b == SPDBANKDENSITY == spd_read_byte dev 00a0 addr 1f returns 80 DIMM size is 80 == BEFORT CTZ == == TEST DIMM SIZE8 == PAGESIZE spd_read_byte dev 00a0 addr 04 returns 0b == MAXCOLADDR == == RDMSR CF07 == == WRMSR CF07 == CF07(2018): 10071007.0040 == ALL DONE == Check present === spd_read_byte dev 00a0 addr 02 returns 07 == MODBANKS spd_read_byte dev 00a0 addr 05 returns 01 == FIELDBANKS == spd_read_byte dev 00a0 addr 11 returns 04 == SPDNUMROWS == spd_read_byte dev 00a0 addr 03 returns 0d spd_read_byte dev 00a0 addr 04 returns 0b == SPDBANKDENSITY == spd_read_byte dev 00a0 addr 1f returns 80 DIMM size is 80 == BEFORT CTZ == == TEST DIMM SIZE8 == PAGESIZE spd_read_byte dev 00a0 addr 04 returns 0b == MAXCOLADDR == == RDMSR CF07 == == WRMSR CF07 == CF07(2018): 10077014.0040 == ALL DONE spd_read_byte dev 00a0 addr 12 returns 0c spd_read_byte dev 00a0 addr 17 returns 75 spd_read_byte dev 00a0 addr 19 returns 00 spd_read_byte dev 00a0 addr 12 returns 0c spd_read_byte dev 00a0 addr 17 returns 75 spd_read_byte dev 00a0 addr 19 returns
Re: [coreboot] coreboot and MSM800BEV
2010/1/12 Stefan Reinauer ste...@coresystems.de: //#define DIMM1 ((u8) 0xA2) #define DIMM1 DIMM0 This is wrong. Unless you use two equal DIMMs every time you will end up with incorrectly set up RAM and RAM controller (which will likely result in behavior such as the one you are seeing) So what address should I use if I have only one DIMM? Every functions which operates on RAM memory use dimm0 and dimm1 parameters. Maybe it will be proper if I just remove all references to DIMM 1 memory? Anyway I still try to go forward after cache invalidation by __asm__(wbinvd\n) ... Thanks for your hint. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
2010/1/8 Patrick Georgi patr...@georgi-clan.de: In that case, your ROM is probably not entirely mapped yet. That's an issue that has to be fixed per chipset (southbridge mostly). I see explicit support for it in cs5530 (even though that _might_ require some more changes), and somewhere in the code of cs5535. I don't know if this is applicable to cs5536, too. If you want to try, this hack might help you (untested, as I don't have the hardware). Maybe the call must be moved around a bit. Unfortunately it didn't help. When I use cs5530_enable_rom() function, the booting process didn't event execute cbfs_load_stage(). Please note that the src/mainboard/digitallogic/msm800sev/auto.c file is not in compilation chain - against it the coreboot/src/mainboard/digitallogic/msm800sev/cache_as_ram_auto.c is used. Maybe it has to be fixed? I've found that the booting process hangs on this part of cbfs_master_header() function (src/lib/cbfs.c): ... outb(0xa1, 0x80); // --- It is printed void *ptr = (void *)*((unsigned long *) CBFS_HEADPTR_ADDR); printk_spew(Check CBFS header at %p\n, ptr); header = (struct cbfs_header *) ptr; outb(0xa2, 0x80); // - It is NOT printed ... I don't know exactly where I need to begin make changes ... Thanks for your interest. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Piotr Piwko wrote: I've found that the booting process hangs on this part of cbfs_master_header() function (src/lib/cbfs.c): ... outb(0xa1, 0x80); // --- It is printed void *ptr = (void *)*((unsigned long *) CBFS_HEADPTR_ADDR); printk_spew(Check CBFS header at %p\n, ptr); header = (struct cbfs_header *) ptr; outb(0xa2, 0x80); // - It is NOT printed ... I don't know exactly where I need to begin make changes ... Do you see the printk message? Could you also add outb() before and after the printk? If it hangs on the printk call I guess it's a stack issue. Did you already try the v3 support for adl/msm800sev? //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
On Mon, Jan 11, 2010 at 2:24 PM, Peter Stuge pe...@stuge.se wrote: Did you already try the v3 support for adl/msm800sev? yes, try this first. See if it goes. Then you'll need to match up what v3 does with what v2 does, and if you get it fixed, I will thank you A LOT. Would be nice to have the msm800 working in v2 :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
OK, I removed all references to DIMM1 memory (there is only DIMM0 on MSM800BEV board) and the SMBUS READ ERROR:03 device:a2 error doesn't occur - please see attached log. My booting process as previously hangs on Uncompressing coreboot to ram. I suppose this situation is related with copying data from cache into RAM memory in cpu/amd/car/cache_as_ram.inc file, the suitable part: - [ cpu/amd/car/cache_as_ram.inc ] - __main: CONSOLE_DEBUG_TX_STRING($str_copying_to_ram) /* * Copy data into RAM and clear the BSS. Since these segments * isn\'t really that big we just copy/clear using bytes, not * double words. */ intel_chip_post_macro(0x11) /* post 11 */ cld /* clear direction flag */ /* copy coreboot from it's initial load location to * the location it is compiled to run at. * Normally this is copying from FLASH ROM to RAM. */ movl%ebp, %esi /* FIXME: look for a proper place for the stack */ movl$0x400, %esp movl%esp, %ebp pushl %esi pushl $str_coreboot_ram_name call cbfs_and_run_core -- It prints $str_coreboot_ram_name (Uncompressing coreboot to ram) and hangs after calling cbfs_and_run_core function. I think that I should set a proper memory address for stack. As we can see the default address (0x400) is wrong but which one is correct? Can you give my any hints? Thanks in advance -- Piotr Piwko http://www.embedded-engineering.pl/ coreboot-2.0.0-r4949M.0Fallback pi�ą, 8 sty 2010, 13:26:09 CET starting... _MSR GLCP_SYS_RSTPLL (4c14) value is: 0392:180c Configuring PLL coreboot-2.0.0-r4949M.0Fallback pi�ą, 8 sty 2010, 13:26:09 CET starting... _MSR GLCP_SYS_RSTPLL (4c14) value is: 0392:07de000c Done pll_reset Castle 2.0 BTM periodic sync period. Enable Quack for fewer re-RAS on the MC GLIU port active enable Set the Delay Control in GLCP Try to write GLCP_DELAY_CONTROLS: hi 83f100aa and lo 56960004 SetDelayControl done Enable RSDC FPU imprecise exceptions bit Enable Suspend on HLT PAUSE instructions Enable SUSP and allow TSC to run in Suspend Setup throttling delays to proper mode Done cpuRegInit Ram1.00 Ram2.00 ===sdram_set_spd_register == ===Check DIMM 0== ===Check DDR MAX== ===AUTOSIZE DIMM 0== ===Check present== ===MODBANKS== ===FIELDBANKS== ===SPDNUMROWS== ===SPDBANKDENSITY== ===DIMMSIZE== ===BEFORT CTZ== ===TEST DIMM SIZE8= ===PAGESIZE== ===MAXCOLADDR== ===12address test== ===RDMSR CF07== ===WRMSR CF07== ===ALL DONE== ===set cas latency== ===set all latency== ===set emrs== ===set ref rate== Ram3 DRAM controller init done. RAM DLL lock Ram4 Testing DRAM : - 000a DRAM fill: 0x-0x000a 000a DRAM filled DRAM verify: 0x-0x000a 000a DRAM range verified. Done. POST 02 Past wbinvd Uncompressing coreboot to ram. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Am 08.01.2010 13:57, schrieb Piotr Piwko: It prints $str_coreboot_ram_name (Uncompressing coreboot to ram) and hangs after calling cbfs_and_run_core function. I think that I should set a proper memory address for stack. As we can see the default address (0x400) is wrong but which one is correct? Can you give my any hints? It's not wrong, it's just an issue once suspend-to-ram etc. come into play - that's why I added this remark to the arbitrary value I used there. This value will be an issue if you have 64MB RAM (and with 64MB it might be a problem, too) How long did you wait? it _might_ be that it merely takes a very long time. That must of course be fixed, but is not the same problem as a hanging system. Patrick -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
2010/1/8 Patrick Georgi patr...@georgi-clan.de:
How long did you wait? it _might_ be that it merely takes a very long
time. That must of course be fixed, but is not the same problem as a
hanging system.
I wait for about 15-20 min and nothing special. I put some 'postcode'
functions for debug capability and I've found out that it hangs on
'cbfs_load_stage' function when it calls cbfs_find_file:
-[ lib/cbfs.c ]
// ...
void * cbfs_load_stage(const char *name)
{
struct cbfs_stage *stage = (struct cbfs_stage *)
cbfs_find_file(name, CBFS_TYPE_STAGE);
/* this is a mess. There is no ntohll. */
/* for now, assume compatible byte order until we solve this. */
u32 entry;
outb(0xaa, 0x80);// --- It doesn't occur
if (stage == NULL)
return (void *) -1;
printk_info(Stage: loading %s @ 0x%x (%d bytes), entry @ 0x%llx\n,
name,
(u32) stage-load, stage-memlen,
stage-entry);
memset((void *) (u32) stage-load, 0, stage-memlen);
if (cbfs_decompress(stage-compression,
((unsigned char *) stage) +
sizeof(struct cbfs_stage),
(void *) (u32) stage-load,
stage-len))
return (void *) -1;
printk_debug(Stage: done loading.\n);
entry = stage-entry;
// entry = ntohl((u32) stage-entry);
return (void *) entry;
}
// ...
---
On Monday I will test the cbfs_find_file function. I hope I will found
something.
Have a good weekend!
--
Piotr Piwko
http://www.embedded-engineering.pl/
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Am 08.01.2010 18:32, schrieb Piotr Piwko:
2010/1/8 Patrick Georgi patr...@georgi-clan.de:
How long did you wait? it _might_ be that it merely takes a very long
time. That must of course be fixed, but is not the same problem as a
hanging system.
I wait for about 15-20 min and nothing special. I put some 'postcode'
functions for debug capability and I've found out that it hangs on
'cbfs_load_stage' function when it calls cbfs_find_file:
-[ lib/cbfs.c ]
// ...
void * cbfs_load_stage(const char *name)
{
struct cbfs_stage *stage = (struct cbfs_stage *)
cbfs_find_file(name, CBFS_TYPE_STAGE);
/* this is a mess. There is no ntohll. */
/* for now, assume compatible byte order until we solve this. */
u32 entry;
outb(0xaa, 0x80);// --- It doesn't occur
In that case, your ROM is probably not entirely mapped yet. That's an
issue that has to be fixed per chipset (southbridge mostly).
I see explicit support for it in cs5530 (even though that _might_
require some more changes), and somewhere in the code of cs5535. I don't
know if this is applicable to cs5536, too. If you want to try, this hack
might help you (untested, as I don't have the hardware). Maybe the call
must be moved around a bit.
Thanks for your effort,
Patrick
--- src/mainboard/digitallogic/msm800sev/auto.c (revision 5003)
+++ src/mainboard/digitallogic/msm800sev/auto.c (working copy)
@@ -14,6 +14,7 @@
#include cpu/x86/bist.h
#include cpu/x86/msr.h
#include cpu/amd/lxdef.h
+#include southbridge/amd/cs5530/cs5530_enable_rom.c
//#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1)
@@ -114,6 +115,7 @@
msr_init(); //GX3 OK
+ cs5530_enable_rom();
cs5536_early_setup(); //GX3 OK
/* NOTE: must do this AFTER the early_setup!
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] coreboot and MSM800BEV
Hello, I am preparing the coreboot version for MSM800BEV board from Digital Logic. This is the same branch as MSM800SEV board so, I've decided that is a good starting point. So, I built and loaded it to my flash memory and finally run. Unfortunately, it stops at Uncompressing coreboot to ram message. I've found that it hangs on calling the 'cbfs_and_run_core' function which is in 'cpu/amd/model_lx/cache_as_ram.inc' file. Is it a known issue? Maybe you can give my any hints to fix this situation? Thank you in advance for your engagement. PS. I have attached the log from my serial port -- Piotr Piwko http://www.embedded-engineering.pl/ coreboot-2.0.0-r4949M.0Fallback czw, 7 sty 2010, 12:55:27 CET starting... _MSR GLCP_SYS_RSTPLL (4c14) value is: 0392:180c Configuring PLL coreboot-2.0.0-r4949M.0Fallback czw, 7 sty 2010, 12:55:27 CET starting... _MSR GLCP_SYS_RSTPLL (4c14) value is: 0392:07de000c Done pll_reset Castle 2.0 BTM periodic sync period. Enable Quack for fewer re-RAS on the MC GLIU port active enable Set the Delay Control in GLCP SMBUS READ ERROR:03 device:a2 Try to write GLCP_DELAY_CONTROLS: hi 83f100aa and lo 56960004 SetDelayControl done Enable RSDC FPU imprecise exceptions bit Enable Suspend on HLT PAUSE instructions Enable SUSP and allow TSC to run in Suspend Setup throttling delays to proper mode Done cpuRegInit Ram1.00 Ram2.00 ===sdram_set_spd_register == ===Check DIMM 0== ===Check DIMM 1== SMBUS READ ERROR:03 device:a2 ===Check DDR MAX== SMBUS READ ERROR:03 device:a2 ===AUTOSIZE DIMM 0== ===Check present== ===MODBANKS== ===FIELDBANKS== ===SPDNUMROWS== ===SPDBANKDENSITY== ===DIMMSIZE== ===BEFORT CTZ== ===TEST DIMM SIZE8= ===PAGESIZE== ===MAXCOLADDR== ===12address test== ===RDMSR CF07== ===WRMSR CF07== ===ALL DONE== ===AUTOSIZE DIMM 1== ===Check present== SMBUS READ ERROR:03 device:a2 ===set cas latency== SMBUS READ ERROR:03 device:a2 ===set all latency== SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 SMBUS READ ERROR:03 device:a2 ===set emrs== SMBUS READ ERROR:03 device:a2 ===set ref rate== SMBUS READ ERROR:03 device:a2 Ram3 DRAM controller init done. RAM DLL lock Ram4 Testing DRAM : - 000a DRAM fill: 0x-0x000a 000a DRAM filled DRAM verify: 0x-0x000a 000a DRAM range verified. Done. POST 02 Past wbinvd Uncompressing coreboot to ram. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
Dear Piotr, Your SPD rom can not be read correctly, hence your RAM controller is not set up correctly... Stefan On 07.01.2010, at 14:22, Piotr Piwko piotr.pi...@gmail.com wrote: Hello, I am preparing the coreboot version for MSM800BEV board from Digital Logic. This is the same branch as MSM800SEV board so, I've decided that is a good starting point. So, I built and loaded it to my flash memory and finally run. Unfortunately, it stops at Uncompressing coreboot to ram message. I've found that it hangs on calling the 'cbfs_and_run_core' function which is in 'cpu/amd/model_lx/cache_as_ram.inc' file. Is it a known issue? Maybe you can give my any hints to fix this situation? Thank you in advance for your engagement. PS. I have attached the log from my serial port -- Piotr Piwko http://www.embedded-engineering.pl/ msm800bev_log.txt -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
This is very bad: SMBUS READ ERROR:03 device:a2 You can run smbus test code in user mode on linux under standard bios, but make sure your superio is the right one. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] coreboot and MSM800BEV
Hi Piotr, I am not a specialist as Stephan and Ron, so don`t shoot me if i`m wrong! But despite the fact that Stephan and Ron are probably right that (part of ?) your RAM is not setup correct, i would think looking at the RAM test output that there is some RAM available. I had the same error on my (non-CAR) board at revision r4992 and the problem disappeared at r4995. So it might be worth a try to test a newer revision. Good luck!,Nils. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
On Thu, Jan 7, 2010 at 10:46 AM, Nils njaco...@hetnet.nl wrote: But despite the fact that Stephan and Ron are probably right that (part of ?) your RAM is not setup correct, i would think looking at the RAM test output that there is some RAM available. But those SMB errors really should be fixed. That's just a very bad thing to happen. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot and MSM800BEV
2010/1/7 ron minnich rminn...@gmail.com: But those SMB errors really should be fixed. That's just a very bad thing to happen. Yes, I agree. I suppose that the mentioned error is related with wrong SMB initialization function. I am going to look at values of SMB registers when my board is booted from vendor BIOS and compare they with coreboot values. I hope it will point me. But first, I will check this coreboot BIOS on MSM800SEV board. It should work correctly, isn't it? Thank you all for your engagement. I will inform about progress in this case. Have a nice day! -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
