[coreboot] Infinite loop with fsp_baytrail and COLLECT_TIMESTAMPS in coreboot 4.2

Ben Gardner gardner.ben at gmail.com
Thu Nov 19 01:14:08 CET 2015


(Martin - I missed the mailing list on my reply to you.)

If I force CBMEMC_RESET in init_console_ptr(), the CBMEM console is at
least valid from the RAM stage on.
That is called via cbmemc_reinit(), after CBMEM is initialized.

If I force CBMEMC_RESET in cbmemc_init(), nothing changes.

It is as if the CBMEM buffers already contain data when they are first
initialized.
How does that memory get cleared?

On Wed, Nov 18, 2015 at 3:24 PM, Ben Gardner <gardner.ben at gmail.com> wrote:
> More info:
> The console log is also messed up (timestamps are disabled).
> It is looking like something wasn't initialized properly.
>
> Partial memory dump of the console area, which is filled with 'garbage':
> 7adde000: f8 ff 01 00 9e 10 02 00 52 2a db ff 80 d0 86 96  ........R*......
> 7adde010: 3f 2e c1 69 04 81 ba 40 84 96 cc 34 01 ad 14 00  ?..i... at ...4....
> 7adde020: 2b d3 0c 82 52 76 63 39 3c 22 fa 6a 22 42 da 9c  +...Rvc9<".j"B..
> 7adde030: 98 99 60 c6 2e 84 30 aa cf 73 c8 9f e2 f2 6c cc  ..`...0..s....l.
> ...
> 7adfdfa0: c4 f2 a9 82 f3 72 29 0b 21 22 e2 ca 80 40 d2 58  .....r).!"... at .X
> 7adfdfb0: 0a 0a 2a 2a 2a 20 4c 6f 67 20 74 72 75 6e 63 61  ..*** Log trunca
> 7adfdfc0: 74 65 64 2c 20 db 33 30 31 38 34 20 63 68 61 72  ted, .30184 char
> 7adfdfd0: 61 63 74 65 72 73 20 64 72 6f 70 70 65 64 2e 20  acters dropped.
> 7adfdfe0: 2a 2a 2a 0a 0a 43 42 46 53 20 70 72 6f 76 69 64  ***..CBFS provid
> 7adfdff0: 65 72 20 61 63 74 69 76 65 2e 0a 43 42 46 53 20  er active..CBFS
>
>
> On Wed, Nov 18, 2015 at 2:12 PM, Ben Gardner <gardner.ben at gmail.com> wrote:
>> Hi all,
>>
>> Has anyone else tried coreboot 4.2 on fsp_baytrail with
>> COLLECT_TIMESTAMPS enabled?
>>
>> I'm seeing the console flooded with an infinite loop of "ERROR:
>> Timestamp table full".
>>
>> The last few post codes are: 4a 4b 4c 4d.
>> That puts it in fsp_baytrail / romstage.c in romstage_main_continue():
>>
>> ...
>> /* if S3 resume skip ram check */
>> if (prev_sleep_state != 3) {
>>   quick_ram_check();
>>   post_code(0x4d);
>> }
>>
>> cbmem_was_initted = !cbmem_recovery(prev_sleep_state == 3);
>>
>> /* Save the HOB pointer in CBMEM to be used in ramstage*/
>> cbmem_hob_ptr = cbmem_add (CBMEM_ID_HOB_POINTER, sizeof(*hob_list_ptr));
>> *(u32*)cbmem_hob_ptr = (u32)hob_list_ptr;
>> post_code(0x4e);
>> ...
>>
>> I had console logging set at NOTICE, so I missed some possibly important logs.
>> Based on a look through the code, I'm guessing the call tree is:
>> romstage_main_continue()
>> cbmem_recovery()
>> cbmem_initialize_empty()
>> cbmem_initialize_empty_id_size()
>> cbmem_run_init_hooks()
>> timestamp_sync_cache_to_cbmem()
>> timestamp_add_table_entry()
>>
>> Side note: it takes 15 minutes to load the BIOS using an external
>> programmer, so I didn't experiment too much.  (Vs. ~30-60 seconds if
>> programmed using flashrom on the target.)
>> I just turned off timestamps and reloaded and it boots fine.
>>
>> Any ideas?
>>
>> Prior to rebasing on 4.2, I didn't have any issues with timestamps.
>> I was using 4.1 + a few patches.
>>
>> Thanks,
>> Ben



More information about the coreboot mailing list