I'm Karthik working on Opencellular (https://code.fb.com/connectivity/introducing-opencellular-an-open-source-wi…). I'm trying to build coreboot image for Opencellular Board. Finally, succeeded in building the image but with a WARNING message
** WARNING **
coreboot will be built without an Intel Firmware Descriptor.
Never write a complete coreboot.rom without an IFD to your
board's flash chip! You can use flashrom's IFD or layout
parameters to flash only to the BIOS region.
So my question is
1. Is it okay to flash the image with above WARNING message onto the board?
Help me to find a way.
Thank you, in advance.
03.05.19 11:35, Shreesh Chhabbi wrote:
> MRC inside FSP is designed this way for reason that Soldered Memory
> will not be replaced on a particular design,
I have little experience with memory-down configurations. But still,
all the boards I know from the coreboot tree, they have options for
memory chips from different vendors.
> hence developer could hardcode parameters for that
> memory device. However for SODIMM, we could use DIMM from any
> vendor/configuration. Hence it needs to be dynamically determined.
Either interface can be fed with dynamic data. My interpretation was
always that it is simply uncommon to solder an SPD EEPROM to a main-
board, because you can integrate the data into the firmware. But that
doesn't mean, you can't switch chips.
On 02.05.19 10:20, Alexey Borovikov wrote:
> How to configure the board with soldered memory where spd?
> Is there any difference when using a memory controller with soldered memory with spd and DIMM?
this really depends on your board design. If the board with SPD follows
the same layout as the board without, the SPD should probably only be
used to configure the memory timings. In this case, you could write some
code that reads the SPD and translates the settings for the memory-down
configuration of FSP. Something like that has been done here , for
However, if your board design follows the design of a real DIMM, I would
simply try _not_ to treat it like a memory-down configuration and confi-
gure FSP as if there were a DIMM.
Hope that helps,
I'd like to discuss the issue of what's expected from developers after
code is added to the coreboot tree. It seems like there's a feeling
that if a company pushes code to coreboot, or hires someone to push
code to coreboot that there's an obligation to help maintain that code
going forward. This seems to be different than if an individual adds
code, but maybe I'm wrong.
- Is there any expectation that work will continue to be done on
contributed code after the initial merge?
- Is there a different expectation of maintenance for when a company
pushes code vs when an individual contributor pushes code?
- If there's an expectation that the contributor will help maintain
that codebase, how long does that expectation last?
- If there's an expectation of maintaining the code and that
expectation isn't met, what are the consequences?
Before I dig in without knowing the code: x86emu currently (
In file included from src/device/oprom/x86emu/x86emui.h:65,
src/device/oprom/x86emu/debug.c: In function 'x86emu_dump_regs':
src/device/oprom/x86emu/debug.h:46:22: error: implicit declaration of
function 'printk'; did you mean 'printf'?
#define printf(x...) printk(BIOS_DEBUG, x)
src/device/oprom/x86emu/debug.c:366:5: note: in expansion of macro
printf("\tAX=%04x ", M.x86.R_AX );
I append the config. Also, there's noone in MAINTAINER for it, and
appearently it's not build-tested :(
For memory down configuration ensure below are enabled/filled in FSP
When a DIMM is having its SPD, the smbus reads the SPD and configures the DIMM channels
For Memory down below changes are expected
1. UpdData->MemoryDownEnable is enabled
MEMORY_DOWN_DATA PcdMemoryParameters; /* Offset 0x00F0 */
UINT16 PcdRegionTerminator; /* Offset 0x0100 */
You can check this function below
UPD_DATA_REGION *UpdData = FspRtBuffer->Common.UpdDataRgnPtr;
/* Memory Down overriding */
UpdData->PcdMemoryParameters.EnableMemoryDown = 1;
UpdData->PcdMemoryParameters.DRAMSpeed = 1; /* DRAM Speed */
UpdData->PcdMemoryParameters.DRAMType = 1; /* DRAM Type */
UpdData->PcdMemoryParameters.DIMM0Enable = 1; /* DIMM 0 Enable */
UpdData->PcdMemoryParameters.DIMM1Enable = 0; /* DIMM 1 Enable */
UpdData->PcdMemoryParameters.DIMMDWidth = 1; /* DRAM device data width */
UpdData->PcdMemoryParameters.DIMMDensity = 2; /* DRAM device data density 2GB */
UpdData->PcdMemoryParameters.DIMMDensity = 1; /* DRAM device data density 1GB */
UpdData->PcdMemoryParameters.DIMMDensity = 2; /* DRAM device data density */
UpdData->PcdMemoryParameters.DIMMBusWidth = 3; /* DIMM Bus Width */
UpdData->PcdMemoryParameters.DIMMSides = 0; /* Ranks Per DIMM */
UpdData->PcdMemoryParameters.DIMMtCL = 7; /* tCL */
UpdData->PcdMemoryParameters.DIMMtRPtRCD = 7; /* tRP and tRCD in DRAM clk - 5:12.5ns, 6:15ns, etc. */
UpdData->PcdMemoryParameters.DIMMtWR = 8; /* tWR in DRAM clk */
UpdData->PcdMemoryParameters.DIMMtWTR = 4; /* tWTR in DRAM clk */
UpdData->PcdMemoryParameters.DIMMtRRD = 6; /* tRRD in DRAM clk */
UpdData->PcdMemoryParameters.DIMMtRTP = 4; /* tRTP in DRAM clk */
UpdData->PcdMemoryParameters.DIMMtFAW = 14; /* tFAW in DRAM clk */
From: Alexey Borovikov <realman.bau(a)gmail.com>
Sent: 02 May 2019 09:20
Subject: [coreboot] FSP 1.0: How to configure soldered memory with spd
There are two boards Intel Atom E3825 with soldered memory. One board with spd, the other without spd. For a board where there is no spd, after configure the correct memory settings in the fsp, I get a working memory controller. For a board with spd, the fsp configurator does not allow to select soldered memory with spd.
How to configure the board with soldered memory where spd?
Is there any difference when using a memory controller with soldered memory with spd and DIMM?
FSP 1.0 is working with a chip spd on a smbus?