Re: [coreboot] Executing bootstrap from MBR in coreboot
2010/2/25 Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net: The someone on the list would be me. I still care about v3 and Geode, but my feature/bugfix request backlog is huge, and I can't start before end of April at the earliest, so my best bet would be September before I can tackle this. And even then, I probably won't have time to focus on hardware I don't own. I'm thankful for your engagement and I fully understand you. Now, it will be better if you focus on your final exams :) Good luck! -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Executing bootstrap from MBR in coreboot
2010/2/26 Marc Jones marcj...@gmail.com: They have some objections about the following registers: - MC_CF1017_DATA (0x201a) should be equal something more like 0x_140DD101 instead of 0x_0101 - GLCP_DELAY_CONTROLS (0x4c0f) should be closer to something like 0xF2F100FF_56960004 I think you are correct. This looks like the memory init is not able to get correct information from the SPD. If that is the problem, you should check that the SMBus controller setup is correct. Ok, I'm going to check it. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Executing bootstrap from MBR in coreboot
2010/2/24 Peter Stuge pe...@stuge.se: Piotr Piwko wrote: I'm afraid that I will have to write my own part of code which will be responsible to execute a boostrap. At this moment I use the old version of coreboot project (practically LinuxBIOS 2.0.0), because only in this release my target board (MSM800BEV) is fully supported out of the box. It would really be nice if you could help make this target work with the updated coreboot sources. I would really like to do this job, but unfortunately I currently work on the quite urgent project and I don't enough time and energy to join to another project. Anyway, I am impressed with your work and I hope that I will be able to help in the future. Then there are basically two choices; 1. Backport support for high tables from current code 2. Fix current code for your target I would strongly prefer option 2. I've decided to write my own code to execute bootstrap from MBR. At this moment I test the functions which are responsible for ATA protocol support. If I have any positive results, I will post my observations. Can you show us boot logs from your working version and from the very latest version? I'm going to do this as soon as possible. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Executing bootstrap from MBR in coreboot
Hello, Does coreboot support executing of boostrap which is contained in MBR? Maybe you have any hints about writing payload which can do that? 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] Executing bootstrap from MBR in coreboot
2010/2/23 Peter Stuge pe...@stuge.se: As Joseph pointed out you could look at SeaBIOS, which has quickly become a very complete BIOS implementation. SeaBIOS runs well as a coreboot payload, and if you combine coreboot and SeaBIOS you will indeed have a legacy compatible open source firmware. I'm afraid that I will have to write my own part of code which will be responsible to execute a boostrap. At this moment I use the old version of coreboot project (practically LinuxBIOS 2.0.0), because only in this release my target board (MSM800BEV) is fully supported out of the box. Unfortunately, it doesn't contain the uint64_t high_tables_base = 0; uint64_t high_tables_size; variables which are necessary to proper SeaBIOS work (according with http://www.coreboot.org/SeaBIOS document). Maybe do you have any documents or advices about using SeaBIOS with this coreboot version? 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
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
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
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
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
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
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
[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
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
[coreboot] Boot time of coreboot on MSM800SEV
Hello, I set about to build and implement the coreboot bios on my MSM800SEV (LX800) platform from Digital Logic. In order to do that I would like to know how much time it takes to boot a bootloader (ex. GRUB)? Have you ever measured this factor on MSM800SEV platform? It will be nice if you can provide my an estimated time. Thank you in advance for engagement. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AMD VSA in Digital Logic MSM800SEV coreboot image
Hello, I've just build the coreboot image with coreinfo playload for Digital Logic MSM800SEV target. In Config.lb file for this board is written that I have to leave 32KB space in image for AMD VSA. As it is required, I build the image which has 988KB size but what about VSA? Where and how can include it in order to have 1MB coreboot image? Thanks in advance for your help and engagement. -- Piotr Piwko http://www.embedded-engineering.pl/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
