[coreboot] Samsung 550 Chromebook own Coreboot

Wed Jul 31 20:36:57 CEST 2013

On Wed, Jul 31, 2013 at 1:27 PM, John Lewis <jlewis at johnlewis.ie> wrote:
>
> On 31/07/2013 17:51, Aaron Durbin wrote:
>
>> On Wed, Jul 31, 2013 at 11:42 AM, John Lewis <jlewis at johnlewis.ie> wrote:
>>
>>> On 31/07/2013 17:11, Aaron Durbin wrote:
>>>
>>>> On Wed, Jul 31, 2013 at 11:03 AM, John Lewis <jlewis at johnlewis.ie
>>>> [8]> wrote:
>>>>
>>>>> On 31/07/2013 16:56, Aaron Durbin wrote:
>>>>>
>>>>>> On Wed, Jul 31, 2013 at 10:50 AM, John Lewis <jlewis at johnlewis.ie
>>>>>> [7][7]> wrote:
>>>>>>
>>>>>>> On 31/07/2013 16:43, Aaron Durbin wrote:
>>>>>>>
>>>>>>>> On Wed, Jul 31, 2013 at 10:34 AM, John Lewis
>>>>>>>> <jlewis at johnlewis.ie [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 at chromium.org [5][5][5][5]> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, Jul 31, 2013 at 10:00 AM, John Lewis
>>>>>>>>>>> <jlewis at johnlewis.ie [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 at johnlewis.ie [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] as detailed by Kyösti in the
>>>>>>>>>>>>>> comments. The patches in
>>>>>>>>>>>>>> http://review.coreboot.org/#/c/3830/ [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 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>>> 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 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
>
>
> 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.