On Wed, Jul 31, 2013 at 1:48 PM, John Lewis <[email protected]> wrote: > On 31/07/2013 19:36, Aaron Durbin wrote: > >> On Wed, Jul 31, 2013 at 1:27 PM, John Lewis <[email protected]> wrote: >> >>> On 31/07/2013 17:51, Aaron Durbin wrote: >>> >>>> On Wed, Jul 31, 2013 at 11:42 AM, John Lewis <[email protected] >>>> [9]> wrote: >>>> >>>>> On 31/07/2013 17:11, Aaron Durbin wrote: >>>>> >>>>>> On Wed, Jul 31, 2013 at 11:03 AM, John Lewis <[email protected] >>>>>> [8][8]> wrote: >>>>>> >>>>>>> On 31/07/2013 16:56, Aaron Durbin wrote: >>>>>>> >>>>>>>> On Wed, Jul 31, 2013 at 10:50 AM, John Lewis >>>>>>>> <[email protected] [7][7][7]> wrote: >>>>>>>> >>>>>>>>> On 31/07/2013 16:43, Aaron Durbin wrote: >>>>>>>>> >>>>>>>>>> On Wed, Jul 31, 2013 at 10:34 AM, John Lewis >>>>>>>>>> <[email protected] [6][6][6][6]> wrote: >>>>>>>>>> >>>>>>>>>>> On 31/07/2013 16:20, Aaron Durbin wrote: >>>>>>>>>>> >>>>>>>>>>>> On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin >>>>>>>>>>>> <[email protected] [5][5][5][5][5]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis >>>>>>>>>>>>> <[email protected] [4][4][4][4][4][4]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On 31/07/2013 15:33, Aaron Durbin wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Jul 31, 2013 at 9:24 AM, John Lewis >>>>>>>>>>>>>>> <[email protected] [3][3][3][3][3][3]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi all, Just want to confirm where we are in >>>>>>>>>>>>>>>> terms of things working or not. The new >>>>>>>>>>>>>>>> system-agent binary works and recognises all >>>>>>>>>>>>>>>> 4 GB of RAM as long as an additional pei data >>>>>>>>>>>>>>>> field is added to Stefan's patches in >>>>>>>>>>>>>>>> http://review.coreboot.org/#/c/3831/ [1] [1] >>>>>>>>>>>>>>>> [1] [1] [1] [1] [1] as detailed by Kyösti in >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the comments. The patches in >>>>>>>>>>>>>>>> http://review.coreboot.org/#/c/3830/ [2] [2] >>>>>>>>>>>>>>>> [2] [2] [2] [2] [2] don't appear to do >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> anything for mrc.cache (it's still zero size) >>>>>>>>>>>>>>>> and this (or perhaps something else) results >>>>>>>>>>>>>>>> in a time to SeaBIOS prompt of between 5 to 9 >>>>>>>>>>>>>>>> seconds. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can you show us 'ls -l $(obj)/mrc.cache' ? I >>>>>>>>>>>>>>> didn't see >>>>>>>>>>>>>> >>>>>>>>>>>>>> -rw-rw-r--. 1 john john 0 Jul 31 11:04 mrc.cache >>>>>>>>>>>>> >>>>>>>>>>>>> This is your problem. I was hoping for a build.log >>>>>>>>>>>>> that was completely clean. The build log attached >>>>>>>>>>>>> does not show mrc.cache being created. Can you try >>>>>>>>>>>>> the following and rebuilt? dd if=/dev/zero >>>>>>>>>>>>> of=mrc.cache bs=16K count=1 | tr '00' '377' > >>>>>>>>>>>>> mrc.cache >>>>>>>>>>>> >>>>>>>>>>>> Apologies. I am doing too many things at once. >>>>>>>>>>>> Remove the 'of=mrc.cache' parameter to dd. >>>>>>>>>>> >>>>>>>>>>> The good news is that cbfstool now reports a non-zero >>>>>>>>>>> mrc.cache, the bad news is it doesn't make any >>>>>>>>>>> difference. cbmem -c reports Updating MRC cache data. >>>>>>>>>>> No FMAP found at ffe70000. FMAP: area RW_MRC_CACHE not >>>>>>>>>>> found find_current_mrc_cache_local: No valid MRC cache >>>>>>>>>>> found. SF: Detected W25Q64 with page size 1000, total >>>>>>>>>>> 800000 Need to erase the MRC cache region of -1 bytes >>>>>>>>>>> at 0011037f SF: Erase offset/length not multiple of >>>>>>>>>>> erase size Finally: write MRC cache update to flash at >>>>>>>>>>> 0011037f ICH SPI: Data transaction error SF: Failed to >>>>>>>>>>> send write command (1 bytes): -1 SF: Winbond Page >>>>>>>>>>> Program failed >>>>>>>>>> >>>>>>>>>> CONFIG_CHROMEOS=y You have that option enabled. That's >>>>>>>>>> why you are seeing fm> erefore, it is not using >>>> the >>>>>> >>>>>> mrc.cache cbfs file. There's >>>>>>> >>>>>>> also the fact that >>>> certain variables are not initialized >>>>>>> properly and >>>> thinking the callee will initialize them. >>>>>>> cache_base >>>> should be set to NULL in update_mrc_cache() >>>>>>> before >>>> calling get_mrc_cahce_region(). You'll see more >>>>>>>>>>> >>>>>>>>>>> enlightening messages. That, or ensure >>>> >>>>>>> >>>>>>> get_mrc_cache_region NULL's out the parameter>>> don't >>>> >>>>>>> enable >> CONFIG_CHROMEOS. > Menuconfig enables it by >> >>> >>>>>>> default, and there is no option to > uncheck. If I set it >>> >>>>>>> to 'n' or comment >> get: > build/generated/crt0.romstage.o: In >>>>>>> function `main': >>> >> > >>>>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:215: >>>>>>>>>> >>>>>>>>>> undefined refe >>>>>> >>>>>> e_chromeos_gpios' > >> > >>>>>> >>>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:362: >>>>>>>>> >>>>>>>>> undefined reference to `init_chromeos' > >> >>>>>> >>>>>> build/northbridge/intel/sandybridge/mrccache.romstage.o: In > >> >>>>>> function `get_mrc_cache_region': >>>>>> >>>>> >>>> >>>> /home/john/coreboot/src/northbridge/intel/sandybridge/mrccache.c:71: >>>>>> >>>>>> >>>>>> >>>>>>>>> undefined reference to `find_fmap_entry' >>>>>>>>> build/northbridge/intel/sandybridge/raminit.romstage.o: In >>>>>>>>> function `sdram_initialize': >>>>>> >>>>>> >>>>> >>>> >>>> /home/john/coreboot/src/northbridge/intel/sandybridge/raminit.c:240: >>>>>> >>>>>> undefined reference to `recovery_mode_enabled' collect2: error: >>>>>> ld returned 1 exit status make: *** >>>>>> [build/cbfs/fallback/romstage_null.debug] Error 1 Fantastic. In >>>>>> src/mainboard/samsung/lumpy/Kconfig remove 'select CHROMEOS'. >>>>>> You'll need to do a 'make oldconfig' then rebuild. Fwiw, you >>>>>> can't set it to 'n'. It needs to be '# CONFIG_CHROMEOS is not >>>>>> set'. But since you did set it to 'n' the dependency object files >>>>>> weren't included in the link. Anyway, do a clean build after >>>>>> removing 'select CHROMEOS'. hth. -Aaron Okay. We are getting a >>>>>> bit further along now but: CC cbfs/fallback/coreboot_ram.debug >>>>>> build/generated/coreboot_ram.o: In function `acpi_create_gnvs': >>>>>> >>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/acpi_tables.c:102: >>>>>> >>>>>> undefined reference to `chromeos_init_vboot' collect2: error: ld >>>>>> returned 1 exit status make: *** >>>>>> [build/cbfs/fallback/coreboot_ram.debug] Error 1 Try the >>>>>> following patch: diff --git >>>>>> a/src/vendorcode/google/chromeos/gnvs.h >>>>>> b/src/vendorcode/google/chrom index 00fe443..5384423 100644 --- >>>>>> a/src/vendorcode/google/chromeos/gnvs.h +++ >>>>>> b/src/vendorcode/google/chromeos/gnvs.h @@ -61,9 +61,13 @@ >>>>>> typedef struct { // dbe } __attribute__((packed)) >>>>>> chromeos_acpi_t; +#if CONFIG_CHROMEOS extern chromeos_acpi_t >>>>>> *vboot_data; void chromeos_init_vboot(chromeos_acpi_t *chromeos); >>>>>> void chromeos_set_me_hash(u32*, int); void >>>>>> acpi_get_vdat_info(uint64_t *vdat_addr, uint32_t *vdat_size); >>>>>> +#else +static inline void chromeos_init_vboot(chromeos_acpi_t >>>>>> *chromeos) {} +#endif #endif Or wrap the call in >>>>>> lumpy/acpi_tables.c with '#if CONFIG_CHROMEOS/#endif'. >>>>> >>>>> Okay, that worked, but cold reboot takes 5 secs to SeaBIOS, warm >>>>> reboot is instantaneous. cbmem -c output looks pretty healthy to >>>>> me. I'll attach it anyway. What do you think? >>>> >>>> Was the log from a warm or cold reboot? Also, what do you mean by >>>> cold reboot? Could you set CONFIG_LAPIC_MONOTONIC_TIMER=y? Also, if >>>> you select CONFIG_COLLECT_TIMESTAMPS=y as well that will provide >>>> times that can be read by the cbmem utility (-t option, I think). >>>> With that data we can do an A/B comparison of boot times for your >>>> warm vs cold. -Aaron >>> >>> Cold, I think. Cold boot - power off and switch on again after a few >>> seconds. If I try to use both those options I get: >>> src/lib/timestamp.c:35:31: error: unknown type name 'tsc_t' static >>> uint64_t tsc_to_uint64(tsc_t tstamp) ^ src/lib/timestamp.c:41:1: error: >>> expected identifier or '(' before '{' token { ^ >>> src/lib/timestamp.c:59:1: error: expected identifier or '(' before '{' >>> token { ^ src/lib/timestamp.c:76:1: error: expected identifier or '(' >>> before '{' token { ^ make: *** [build/lib/timestamp.romstage.o] Error 1 >> >> >> Hrmm. I don't understand why that is failing. cpu/x86/tsc.h should be >> included from timestamp.h. No idea why tsc_t isn't being defined. >> Well, removing CONFIG_COLLECT_TIMESTAMPS should make your build work. >> And we can at least see ramstage boot times. > > > Attached. Cold was much slower this time. > > John.
Your cold logs has the following: find_current_mrc_cache_local: No valid MRC cache found. I take it that was after a fresh reprogram? If you do another cold boot it should use the MRC cache. I was going to compare the boot state times, but it seems these logs don't have CONFIG_LAPIC_MONOTONIC_TIMER enabled? -Aaron -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
