8:53 p.m.
On Wed, Jul 31, 2013 at 1:48 PM, John Lewis <jlewis(a)johnlewis.ie> wrote:
On 31/07/2013 19:36, Aaron Durbin wrote:
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
On Wed, Jul 31, 2013 at 1:27 PM, John Lewis
<jlewis(a)johnlewis.ie> wrote:
Attached. Cold was much slower this time.
John. On 31/07/2013 17:51, Aaron Durbin wrote:
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. On Wed, Jul 31, 2013 at 11:42 AM, John Lewis
<jlewis(a)johnlewis.ie
[9]> wrote:
> On 31/07/2013 17:11, Aaron Durbin wrote:
>
>> On Wed, Jul 31, 2013 at 11:03 AM, John Lewis <jlewis(a)johnlewis.ie
>> [8][8]> wrote:
>>
>>> On 31/07/2013 16:56, Aaron Durbin wrote:
>>>
>>>> On Wed, Jul 31, 2013 at 10:50 AM, John Lewis
>>>> <jlewis(a)johnlewis.ie [7][7][7]> wrote:
>>>>
>>>>> On 31/07/2013 16:43, Aaron Durbin wrote:
>>>>>
>>>>>> On Wed, Jul 31, 2013 at 10:34 AM, John Lewis
>>>>>> <jlewis(a)johnlewis.ie [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
>>>>>>>> <adurbin(a)chromium.org [5][5][5][5][5]> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis
>>>>>>>>> <jlewis(a)johnlewis.ie [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
>>>>>>>>>>> <jlewis(a)johnlewis.ie
[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
2298
days inactive
2298
days old
0 comments
1 participants
participants (1)
-
Aaron Durbin