For amd/picasso and RESET_VECTOR_IN_RAM=y implying ENV_CACHE_AS_RAM=n, I don't see anything absolutely requiring use of x86/car.ld. There's couple _car_xx symbols referenced under drivers/intel/fsp2_0, those seemed to be related to (older) FSP choosing pre-ram stack location dynamically and checking it is not trashing other CAR objects. Those references may hit garbage-collection with a strategically placed 'if (ENV_CACHE_AS_RAM)'.

For sure, I am lacking some details and most discussions you have had about this, but I hope this doesn't further stirr things or add confusion. I just feel the keyword CAR in context with amd/picasso is the biggest source of confusion so far.

View Change

4 comments:

• File src/arch/x86/early_dram.ld:

  • Patch Set #1, Line 27: _car_stack_start = .;

    There is probably some easy way to put this in between _program and _eprogram. Section .bss is already picked up from program.ld since amd/picasso has ENV_CACHE_AS_RAM=n.

  • Patch Set #1, Line 35: PRERAM_CBMEM_CONSOLE(., CONFIG_PRERAM_CBMEM_CONSOLE_SIZE)

    If we have some CBMEM console before romstage, it would be from PSP execution. (Current information is x86 will skip bootblock and verstage). So any such DRAM region would be defined in a memlayout shared between x86 and PSP. So the entry here can be removed?

  • Patch Set #1, Line 37: TIMESTAMP(., 0x200)

    Same thing with timestamps. Inherit/share memlayout with PSP, should we have any timestamps prior to x86 deassertion. Although I have no clue if there is any common timebase or monotonic timer in PSP such that we could scale and sync those with x86 TSC.

  • Patch Set #1, Line 42: _car_ehci_dbg_info_end = .;

    Can be removed. This was to support usbdebug more smoothly thru bootblock and verstage. Maybe you don't even have EHCI controller anymore.

To view, visit change 35035. To unsubscribe, or for help writing mail filters, visit settings.