View Change

2 comments:

• File src/include/rules.h:

  • Patch Set #1, Line 259: #define ENV_EARLY_RAM (ENV_ROMSTAGE_OR_BEFORE && CONFIG(RESET_VECTOR_IN_RAM))

    I read ENV_CAR (and I wrote ENV_EARLY_RAM) to indicate any time when that mode is active, not that they're the opposite of each other. So ENV_CACHE_AS_RAM=1 when CAR is active (bootblock, verstage, romstage) and =0 ramstage, etc. I see them as more analogous than opposite.

    there should be an accompanying #define for !ARCH_X86.

    Missed that.

    ...are there some if (ENV_EARLY_RAM) cases on your patchtrain?

    See CB:37487. I'd be happy to squash it if it makes it more clear. program.ld is the only place it'll be used AFAIK.

    I don't mind if you rename RESET_VECTOR_IN_RAM, looking at the direction things are going

    My biggest complaint with the name is it's too generic of a name for a specific implementation. If a competitor made a product that also started executing in DRAM, I don't know that the x86's behavior would be compatible with this implementation.

  • Patch Set #1, Line 261: #define ENV_STAGE_HAS_DATA_SECTION (!ENV_CACHE_AS_RAM && !ENV_EARLY_RAM)

    I don't see why you would need to restrict this. Aaron has also suggested to add .data to car. […]

    The elf-to-image creation/compression feature of cbfstool only takes the elf file's PROGBITS. So without more work in that area, all data is effectively initialized to 0 due to zeroing the buffer before compressing. I'm curious how non-ro .data in CAR w/bootblock would work. How would the initialized data get loaded into the data location? BTW, my first question was actually "what's the downside of having no .data in the earliest stages?"

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