Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
5,297 Views

DRAM initialization of Galileo Gen2: ROM code or firmware?

Dear community,

I was exploring the DRAM module that is implemented in the Galileo. I want to test the data retention characteristics of the DRAM but I exhibited that if one turns the board on, something writes values to the DRAM. I wanted to disable this procedure but wasn't successful yet. Thus, I was asking myself if there is some initalization code as part of potential ROM code that can not be disabled anyway? Or doesn't the Galileo platform implement any ROM code and everything is initialized within the firmware?

Best,

André

23 Replies
Highlighted
Honored Contributor I
64 Views

Hi André,

I've seen that if Galileo is turned on without SD, the firmware boots yocto (Linux) in RAM, so maybe the DRAM is initialized/written at boot time. I think something similar may happen when booted with SD, but I've not checked. I don't know about how yocto handles the different types of Galileo RAM.

HTH,

Fernando.

0 Kudos
Highlighted
Community Manager
64 Views

Hi an.schall,

 

 

That's an interesting question. Let me investigate about it to see if I'm able to get a better answer for you. I'll post an update as soon as possible.

 

 

Regards,

 

Diego
Highlighted
Valued Contributor II
64 Views

Hi,

a DDR3 memory initialization is performed by a code of SPI flash memory.

So, it is possible to compile own SPI flash memory image with disabled DDR3 initialization or DRAM memory access.

BR,

xbolshe

Highlighted
New Contributor I
64 Views

Dear all,

I guess the central initialization is done in /QuarkSocPkg/QuarkNorthCluster/MemoryInit/Pei/meminit.c. I am trying to locate whether there is code (i.e. the POST functions that writes values to the DRAM. However, given a brief scan I couldn't find any code that does so. Alternatively, given that the Galileo has DDR3 memory, there might be a DDR-related init sequence that initalizes the memory (i.e. precharges it) that might introduce values to the DRAM.

I will try to setup Olimex HW debugger to debug the source in order to get a clearer picture.

Best

Highlighted
Community Manager
64 Views

Hi an.schall,

 

 

I'm sorry for the delay. I see that you have posted an update. Regarding your first question, the firmware initializes the DRAM and it is open source. There is no ROM code on the Galileo platform.

 

 

Could you let us know if you are booting from the on-board flash?

 

 

Regards,

 

Diego
0 Kudos
Highlighted
Valued Contributor II
64 Views

21.10 Memory Training Engine Lockdown

As part of DDR3 memory initialization code, the Intel® Quark™ SoC UEFI firmware

makes use of a hardware engine to assist in the training of memory. Once DDR3

memory initialization is complete, Intel® Quark™ SoC UEFI firmware locks the

hardware training engine to prevent further training sequences being initiated.

File Path: QuarkSocPkg\QuarkNorthCluster\MemoryInit\Pei\meminit.c

Function: lock_registers

Source: http://www.intel.com/content/dam/www/public/us/en/documents/guides/quark-x1000-uefi-firmware-writers... http://www.intel.com/content/dam/www/public/us/en/documents/guides/quark-x1000-uefi-firmware-writers...

BR,

xbolshe

Highlighted
New Contributor I
64 Views

Dear Diego,

I am booting from SPI flash. I guess it is because of some training phase/ init phase xbolshe was pointing at.

Best,

André

0 Kudos
Highlighted
Valued Contributor II
64 Views

In my understanding, there is an init sequence:

static const MemInit_t init[] =

{

{ 0x0101, bmCold|bmFast|bmWarm|bmS3, clear_self_refresh }, //0

{ 0x0200, bmCold|bmFast|bmWarm|bmS3, prog_ddr_timing_control }, //1 initialise the MCU

{ 0x0103, bmCold|bmFast , prog_decode_before_jedec }, //2

{ 0x0104, bmCold|bmFast , perform_ddr_reset }, //3

{ 0x0300, bmCold|bmFast |bmS3, ddrphy_init }, //4 initialise the DDRPHY

{ 0x0400, bmCold|bmFast , perform_jedec_init }, //5 perform JEDEC initialisation of DRAMs

{ 0x0105, bmCold|bmFast , set_ddr_init_complete }, //6

{ 0x0106, bmFast|bmWarm|bmS3, restore_timings }, //7

{ 0x0106, bmCold , default_timings }, //8

{ 0x0500, bmCold , rcvn_cal }, //9 perform RCVN_CAL algorithm

{ 0x0600, bmCold , wr_level }, //10 perform WR_LEVEL algorithm

{ 0x0120, bmCold , prog_page_ctrl }, //11

{ 0x0700, bmCold , rd_train }, //12 perform RD_TRAIN algorithm

{ 0x0800, bmCold , wr_train }, //13 perform WR_TRAIN algorithm

{ 0x010B, bmCold , store_timings }, //14

{ 0x010C, bmCold|bmFast|bmWarm|bmS3, enable_scrambling }, //15

{ 0x010D, bmCold|bmFast|bmWarm|bmS3, prog_ddr_control }, //16

{ 0x010E, bmCold|bmFast|bmWarm|bmS3, prog_dra_drb }, //17

{ 0x010F, bmWarm|bmS3, perform_wake }, //18

{ 0x0110, bmCold|bmFast|bmWarm|bmS3, change_refresh_period }, //19

{ 0x0111, bmCold|bmFast|bmWarm|bmS3, set_auto_refresh }, //20

{ 0x0112, bmCold|bmFast|bmWarm|bmS3, ecc_enable }, //21

{ 0x0113, bmCold|bmFast , memory_test }, //22

{ 0x0114, bmCold|bmFast|bmWarm|bmS3, lock_registers } //23 set init done

};

And need to modify it to fix your problem.

BR,

xbolshe

0 Kudos
Highlighted
New Contributor I
64 Views

Indeed, this is the table I also stumpled over. I can see that I see remenance effect if I do a warm restart but not with cold reboot. Thus I will try to modify the code to enforce warm flow in any case.

Highlighted
Valued Contributor II
64 Views

Or may be need just halt a processor with an infinite loop during this procedure:

__asm {

label_halt:

hlt

jmp label_halt

}

BR,

xbolshe

0 Kudos
Highlighted
New Contributor I
64 Views

Thanks, this is another alternative. However, I will first have to see at which point I can insert this code such that DRAM is initialized minimalistically but not overwritten.

Highlighted
New Contributor I
64 Views

An update regarding my investigations:

In order to read from the DRAM the following registers must be programmed such that commands can be issued to DDR memory:

Dco.field.PMICTL = 0; Dco.field.IC = 1;

Copying these instruction (including the preceeding ones taken from set_ddr_init_complete()) to different locations of meminit.c in order to find the earliest code location that allows for reading the DRAM leads to the following observations:

1. DRAM can be read as early as at the end of ddrphy_init() but it again shows pre-initialized values. I am currently figuring out if it can be read a bit earlier.

2. Warm resets will always allow to read the previously stored values it the warm flow doesn't call certain functions. However, calling the function "dram_init_command(emrs1Command.raw)" that is part of jedec_init, which would NOT BE CALLED during a warm reset, pre-initializes the values.

Maybe as part of the physical level initalization some precharging is performed that would lead to preinitialized values.

Highlighted
Community Manager
64 Views

Hi an.schall,

 

 

I'd like to know how your investigations are going. Do you have additional updates or questions?

 

 

Regards,

 

Diego
0 Kudos
Highlighted
New Contributor I
64 Views

Dear Diego,

I am still no able to identify the part of the code that pre-initializes the DRAM memory values. I figured the earliest point in time to read out the memory (ddrphy_init before step 4a). However, reading the contents of the DRAM at this time reveals a very structured pattern that seems identical for almost all banks of the DRAM but it is different among multiple Galileo devices. I know that part of the JEDEC DDR3 standard, the cells will be precharged and there are also some read and write leveling sequences. However, as far as I can tell all the precharging and leveling is done in perform_jedec_init as well as wr_level, rd_train, wr_train. Thus, I guess the structure that I can observe must be due to some other code. Potentially, at a very early stage all the wordlines are actived and since the capacitors hold Vdd/2 the amplifiers (more or less) randomly decide whether there is a 0 or 1. So currently, I am still trying to find the code that is in charge of pre-initializing the DRAM cells.

Best

0 Kudos
Highlighted
Community Manager
64 Views

I see… I'll try to find any additional information that could be useful for you.

 

 

Additionally, I'm confused about the file you attached, can you explain it?

 

 

Regards,

 

Diego
0 Kudos
Highlighted
New Contributor I
64 Views

Regarding the attached file: It is a false-color map (heatmap) of a 32 KB section of the DRAM. I took 5 measurements (unplugging the board in between) and created for each cell the probability of having a "1" bit. Thus, yellow cells show cells that have a "1" bit in all of the five measurements while dark blue ones refer to those with 0 value. Basically, it is a bitmap of the startup pattern of a 32 KB DDR3 segment averaged over 5 measurements.

0 Kudos
Highlighted
Community Manager
64 Views

Hi an.schall,

 

 

Thanks for the explanation.

 

 

I'll try to find additional information that helps you on this.

 

 

I'll post an update as soon as possible.

 

 

Regards,

 

Diego
0 Kudos
Highlighted
New Contributor I
64 Views

Dear Diego,

do you have any updates regarding the remenance effect?

Best,

André

0 Kudos
Highlighted
Community Manager
64 Views

Hi an.schall,

 

 

I apologize for the delay in my response, but unfortunately I don't have updates about this yet. We're still investigating about it.

 

 

I'll post any update I get as soon as possible. Sorry for the inconveniences.

 

 

Regards,

 

Diego
0 Kudos