[coreboot] CBMEM Console corruption with fsp_baytrail in coreboot 4.2

Ben Gardner gardner.ben at gmail.com
Sun Nov 22 05:14:28 CET 2015

I think I found the issue, but won't be able to test for another week.

car_get_var_ptr() assumes that the migrated base is the same as _car_data_start.
On FSP 1.0, that isn't true.  _car_data_start is 0x0c00 bytes past
migrated base.

The last two lines of car_get_var_ptr() read as follows:
   offset = (char *)var - (char *)_car_data_start;
   return &migrated_base[offset];

However, migrated base matches 0xfef00000 (DCACHE_RAM_BASE), while
_car_data_start is 0xfef00c00.
So, when the data is migrated, the migrated offset is wrong and
cbmem_console_p is fairly random.

It worked when I moved _preram_cbmem_console because that put
_car_data_start at 0xfef00000 again.
A simple fix would be to use CONFIG_DCACHE_RAM_BASE instead of
_car_data_start when calculating the base.

I think we may also need Aaron's earlier patch proposed in this
thread, as _preram_cbmem_console is not between _car_data_start and

The fix might be something like the following: (gmail ate my tabs).

What do you think?

--- a/src/cpu/x86/car.c
+++ b/src/cpu/x86/car.c
@@ -63,15 +63,15 @@ void *car_get_var_ptr(void *var)
        migrated_base=(char *)find_saved_temp_mem(
                        *(void **)CBMEM_FSP_HOB_PTR);
+       offset = (char *)var - (char *)CONFIG_DCACHE_RAM_BASE;
        migrated_base = cbmem_find(CBMEM_ID_CAR_GLOBALS);
+       offset = (char *)var - (char *)_car_start;

        if (migrated_base == NULL)
                die( "CAR: Could not find migration base!\n");

-       offset = (char *)var - (char *)_car_start;
        return &migrated_base[offset];

On Fri, Nov 20, 2015 at 5:11 PM, Ben Gardner <gardner.ben at gmail.com> wrote:
> On Fri, Nov 20, 2015 at 4:56 PM, Ben Gardner <gardner.ben at gmail.com> wrote:
>> Ug. I was looking at the wrong log. Time for a break.
>> The output from the log was:
>> Stack: fef03fc4 or fef03fcc
>> That seems to match the settings:
> For what it is worth, I verified that ECX = 0xfef00000 and EDX =
> 0xfef04000 when the FSP's TempRamIinitEntry() function returns.
> The CAR global data makes more sense now, as that is mapped to the
> bottom of the temporary stack area.
> The CAR data location is correct and the stack data does indeed appear
> to have been copied correctly to 0x7ae230a0.
> I think I'm looking in the wrong area.
> Oh, well.  I'll look at it again after the Thanksgiving holiday.
> Ben

More information about the coreboot mailing list