On Wed, Jul 31, 2013 at 11:42 AM, John Lewis <[email protected]> wrote: > > > On 31/07/2013 17:11, Aaron Durbin wrote: > >> On Wed, Jul 31, 2013 at 11:03 AM, John Lewis <[email protected]> wrote: >> >>> On 31/07/2013 16:56, Aaron Durbin wrote: >>> >>>> On Wed, Jul 31, 2013 at 10:50 AM, John Lewis <[email protected] >>>> [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]> 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]> wrote: >>>>>>>> >>>>>>>>> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis >>>>>>>>> <[email protected] [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]> 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] as detailed by Kyösti in the >>>>>>>>>>>> comments. The patches in >>>>>>>>>>>> http://review.coreboot.org/#/c/3830/ [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 fmap calls. Therefore, 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. In short, 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 in .config I get: >>>>> build/generated/crt0.romstage.o: In function `main': >>>>> /home/john/coreboot/src/mainboard/samsung/lumpy/romstage.c:215: >>>>> undefined reference to `save_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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
