I am using Armbian 4.14 kernel on a custom board.

As soon as the boards boots up I get a lot of oops and memory address fault. Software works on another board that use same memory and mtest always succeeds on faulty board even with complementary patterns.

I have got the feedback that this new memory belongs to the newest revision level so SDRAM parameters needs to be updated.

However I am using the 4.14 kernel so .fex configuration is not taken into consideration by the kernel, although initialize the SDRAM controller is bootloader->SPL's duty.

 

Anyone knows how to update SDRAM parameters without using .fex config file or compile u-boot and SPL to open and initialize SDRAM controller according to its settings?

I realize that problem may be poor PCB layout, however I will be safe if I can compile according to the new instructions and show the result.

 

Thank you.

It would be delicious if you would mind to share what kind of soc your custom boards sports, otherwise you are making this even more difficult.

Hi,

 

my board is using AllwinnerH3 CPU with Samsung SDRAM. Reference design is the nanopi-m1-plus board.

We know believe the issue is hardware related because the board works well with one RAM chip however it has the issue observed above if two RAM chips are used.

Schematic is 100% the same of the nanopi-m1-plus, it should be EMC on power supply or wrong characteristic impedance when address lines split.

However it would be nice to understand how to program the SDRAM controller of this CPU. So far the documentation from Allwinner is disappointing on this point and RAM settings are for the 1333 speed grade while now we have 1800 speed grade however we cannot get any benefit until clear and complete specifications are released.

I'm not sure if I understood this correctly. You want clear and complete documentation from Allwinner?

 

17 hours ago, Gianluca85 said:

however we cannot get any benefit until clear and complete specifications are released.

Allwinner doesn't release any DRAM documentation. Actually, very few companies do. Presumably due to licensing terms with IP block vendor.

12 hours ago, jernej said:

Allwinner doesn't release any DRAM documentation. Actually, very few companies do. Presumably due to licensing terms with IP block vendor.

 

Understood.

In reply to Chrisf as well, yes, I was indirectly asking if anyone knows where I could find a complete and clear documentation. I am new with Allwinner so I may have missed something.

I understand the licensing terms issue, however I do not see how this may prevent them to release new hard coded parameters every time the RAM technology improves IF the RAM vendor is the same.

 

The ticket is closed for me.

3 minutes ago, Gianluca85 said:

I understand the licensing terms issue, however I do not see how this may prevent them to release new hard coded parameters every time the RAM technology improves IF the RAM vendor is the same.

 

Actually, Armbian (mostly) uses mainline U-Boot which has reverse engineered DRAM code from Allwinner blobs. Armbian for H3 is definetly such. Because reverse engineering is a pain, even more so when there is no documentation, most people are happy when it works nicely. Optimizations in this area are rare.

 

You can still use BSP U-Boot, which has configurable DRAM settings. But it's ancient version with fex files (something totally Allwinner specific), so using mainline U-Boot (with reverse engineered DRAM driver) is very much preferred and done as soon as feasible.

 

BTW, even mainline U-Boot has some settings for RAM. I suggest you take a look at them, but don't expect miracles, since DRAM controller is (at least afaik) not fully understood.

1 hour ago, jernej said:

 

Actually, Armbian (mostly) uses mainline U-Boot which has reverse engineered DRAM code from Allwinner blobs. Armbian for H3 is definetly such. Because reverse engineering is a pain, even more so when there is no documentation, most people are happy when it works nicely. Optimizations in this area are rare.

 

You can still use BSP U-Boot, which has configurable DRAM settings. But it's ancient version with fex files (something totally Allwinner specific), so using mainline U-Boot (with reverse engineered DRAM driver) is very much preferred and done as soon as feasible.

 

BTW, even mainline U-Boot has some settings for RAM. I suggest you take a look at them, but don't expect miracles, since DRAM controller is (at least afaik) not fully understood.

 

Is it possible to change the configuration parameters from the device tree or is embedded in the compile configuration? I took a fast look into u-boot sunxi device trees but did not found anything valuable

9 hours ago, jock said:

Is it possible to change the configuration parameters from the device tree or is embedded in the compile configuration?

It's the later. sunxi platform doesn't use DT in SPL.