On 31/07/2013 17:11, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 11:03 AM, John Lewis jlewis@johnlewis.ie wrote:
On 31/07/2013 16:56, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 10:50 AM, John Lewis <jlewis@johnlewis.ie [7]> wrote:
On 31/07/2013 16:43, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 10:34 AM, John Lewis <jlewis@johnlewis.ie [6][6]> wrote:
On 31/07/2013 16:20, Aaron Durbin wrote:
> On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin > <adurbin@chromium.org [5][5][5]> wrote: > >> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis >> <jlewis@johnlewis.ie [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 >>>> <jlewis@johnlewis.ie [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?
On Wed, Jul 31, 2013 at 11:42 AM, John Lewis jlewis@johnlewis.ie wrote:
On 31/07/2013 17:11, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 11:03 AM, John Lewis jlewis@johnlewis.ie wrote:
On 31/07/2013 16:56, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 10:50 AM, John Lewis <jlewis@johnlewis.ie [7]> wrote:
On 31/07/2013 16:43, Aaron Durbin wrote:
On Wed, Jul 31, 2013 at 10:34 AM, John Lewis <jlewis@johnlewis.ie [6][6]> wrote:
> On 31/07/2013 16:20, Aaron Durbin wrote: > >> On Wed, Jul 31, 2013 at 10:18 AM, Aaron Durbin >> <adurbin@chromium.org [5][5][5]> wrote: >> >>> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis >>> <jlewis@johnlewis.ie [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 >>>>> <jlewis@johnlewis.ie [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
-
Aaron Durbin -
John Lewis