Infinite loop with fsp_baytrail and COLLECT_TIMESTAMPS in coreboot 4.2

[Ben Gardner]

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

Infinite loop with fsp_baytrail and COLLECT_TIMESTAMPS in coreboot 4.2

[Ben Gardner]

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...@...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).!"...@.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  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

Infinite loop with fsp_baytrail and COLLECT_TIMESTAMPS in coreboot 4.2

[Ben Gardner]

(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  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...@...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).!"...@.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  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