DCD Contents

[seeking.that]

Hello,

​Thanks for the excellent videos on board bringup using Ubuntu and Linux. The bootloader initially programs the memory controller (Multi-Mode DRAM controller - MMDC) using a set of values - Device Config Data (DCD) which mostly contains the controller programming for memory card R/W, single/burst operations. Apart from that there may be some default clock configurations and other misc. pin configurations.


What precisely constitutes the DCD contents ? What other information could be added ? What should be the basic set of information for a particular custom board ?

​Since it is predominantly the memory card (DDR2/DDR3/...) programming and DDR programming is outlined by the jedec specs, can we substitute those values recommended by the memory card manufacturers in there ?

​What other configurations can be added for putting the board in debug mode ? Fore ex: JTAG, disabling watchdog, etc. It would be really good if you can cover this information in some detail.

Thanks,
Seeking That!

[robertferanec]

Please, could you be more specific?
- Are your referring to ARM / MIPS / etc. boards or x86 boards (bootloader vs BIOS)?
- Are you referring to boards with memory module plugged into a slot or boards with soldered down memory chips?

[seeking.that]

Hi Robert,

Thanks

This was specific to ARM-based processors.

I am not sure what changes would be required for modules plugged into a slot vs soldered down memory chips. Nice to cover that as well.

Regards,
Seeking That!

[robertferanec]

I am not exactly sure to what videos you are referring to and also I am not sure about your questions.

Basically, if you need to customize software for specific hardware, than you create something what is called BSP - board support package. Format of BSP is different between software, but it usually containts information like:
- memory configuration,
- pin configuration,
- interface configuration and initialization (e.g. what is width of your MMC interface),
- peripheral chip initialization (e.g Ethernet registers and reset), etc.

Some basic initialization is done in bootloader (often, in bootloader you may only initialize the interfaces and pins which you need to boot up OS) and full initialization is done in Linux (at this stage, memory initialization is already done by bootloader, but OS will initialize all the pins and interfaces which are on the board)

If you like, have a look at commits, you will see what kind of information can be changed:
- uBoot commits: https://github.com/FEDEVEL/openrex-u...commits/jethro
- Linux commits: https://github.com/FEDEVEL/openrex-l...commits/jethro

If you are using memory modules, they have EEPROM with information about the memory module. It is called SPD https://en.wikipedia.org/wiki/Serial_presence_detect - information from this EEPROM is used to setup memory controller.

[seeking.that]

Hi Robert,
I am assuming linux porting would constitute the following:
- pin-configurations as per mappings from schematics to pin-header files depending on the PCB routings and alt-configurations defined per processor datasheets
- for ex: if there is a conflict in one alt-configuration, use it as per another alt-configuration
- dts bindings for a peripheral would have been defined/tested. Use those standard bindings for our custom board and validate/refine the values of those bindings
- I am assuming the values of those bindings as such won't change if they are standard peripherals on the processor
- if the peripherals are new on the custom-board, then the dts bindings are to be created anew. The new values are to be calibrated and provided by the board designer. And the dts bindings are created as suggested by the board designer.
- Have you used pin-configuration tool provided for i.MX6 (iomux_tool, Pins_Tool_for_i.MX_Processors_v4_x64) by NXP ? It asks for processor/packaging details and generates dts/dtsi files. It is a bit confusing to use it. I would be interested to hear about it from you. What if there is a new peripheral on the board, not in the processor assembly ?
- I have seen different values for UART2_TX_DATA pins. But I won't care as long as it is generated by the tool because it does the calibration. I don't know if there is any other way of deciphering the values.

[robertferanec]

We used iomux, but we have not generated dts/dtsi. We always update dts manually by modifying files from the reference board.