• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1588 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: About DMSC ROM Code and R5 ROM Code

felix_123
Expert 1251 points
Part Number: TDA4VM

Hi TI,

according to u-boot/board/ti/j721e/README and to TRM chapter 4.2, TDA4VM's boot sequence is initialized by the factory sealed DMSC ROM Code, which starts also factory sealed R5 ROM Code. The TRM says, that those are responsible for 

  • PLL Configuration
  • PM Configuration
  • RM Configuration

Can you please give some details about which PLLs are configured and which regions of the SoC are powered up through those two pieces of code?

The reason behind this question is, that I am curious about the big time difference when setting the board to "No-Boot"-Mode and connect it to a CCS debug session via launch.js script (takes up to 3 min using Blackhawk XDS560 v2 Debugger) and, for instance, the "normal" booting sequence from SD card (to U-Boot prompt, it takes only about 5s).

In my understanding, the launch.js file (including the GEL functions, which are called when connecting to DMSC core) does, at least for the first steps, exactly the same as DMSC/R5 ROM Code. It calls

  • Set_All_PLL()
  • Set_PSC_All_On()

which set up all PLLs and PSCs. 

I can imagine, that DMSC/R5 ROM Code are not setting up ALL PLLs/PSCs like the launch.js script does, and I can imagine that the JTAG connection introduces also some time issue. But I can not imagine, that these two reasons are responsible for this big time difference. 

Thank you very much for your help.

Best regards,

Felix

  • 0
    Expert 1251 points

    Hi TI,

    any additional information on this is appreciated.

    Thanks again.

  • 0 in reply to felix_123
    Expert 1251 points

    Hi TI,

    can you please deny or confirm:

    DMSC ROM Code configures all MCU PLLs for OFC (Original Frequency Combination) according to MCU_BOOTMODE [0:2] Switches?

    MCU ROM Code configures all MAIN PLLs for OFC (Original Frequency Combination) according to MCU_BOOTMODE [0:2] Switches?

    Thanks again and best regards,

    Felix

  • +1 in reply to felix_123
    TI__Guru* 77704 points

    Hi Felix,

    Apologies for late response here, this thread got missed.

    felix_123 said:

    DMSC ROM Code configures all MCU PLLs for OFC (Original Frequency Combination) according to MCU_BOOTMODE [0:2] Switches?

    MCU ROM Code configures all MAIN PLLs for OFC (Original Frequency Combination) according to MCU_BOOTMODE [0:2] Switches?

    The device has two ROM codes operating in tandem – the MCU ROM code, and the DMSC ROM code.

    Excerpt from the TRM:

    During initialization, the ROM Code configures the device resources (PLLs, peripherals, pins) as needed to support the boot process. The resources used depend on the boot mode requirements. During the boot process the boot image can be loaded into device memory and executed, or executed in place, depending on the boot peripheral. DMSC will perform code verification and allow, or forbid, the image execution.

    Main configuration source for boot after power-up are the BOOTMODE pins sampled automatically after reset
    release and stored in device status registers. At ROM Code startup, these pin values are read from the registers
    to create the boot peripheral list and the boot configuration tables used later to initialize and startup the PLLs
    and boot peripherals.

    The MCU_BOOTMODE[0:2] only tell the ROM code the frequency of the external oscillator. The ROM Code will configure any PLLs required during the boot process and that configuration is based on what frequency is recorded by the ROM code from these 3 pins. On customer boards if there is a change in the external oscillator then these pins need to be pulled up/down appropriately.

    So yes, the reference clock for setting all PLLs is recorded by MCU_BOOTMODE[0:2]. This will include MCU and MAIN PLLs.

    DMSC ROM will configure the MCU PLLs required for boot process with some conservative setting and then releases MCU R5Fs reset. Upon that the MCU ROM code runs and configures more MCU PLLs needed for boot process and then based on boot switch setting (both MCU_BOOTMODE and BOOTMODE) it configures more MAIN PLLs to fetch the bootloader image. Finally the DMSC issues a reset for MCU R5 and then MCU R5 starts executing the bootloader. The bootloader can not now re-configure and configure more PLLs (overriding the ROM defaults if needed).

    I will post another response for your original question.

    Regards,

    Karan

  • +1
    TI__Guru* 77704 points

    Hi Felix,

    felix_123 said:
    Can you please give some details about which PLLs are configured and which regions of the SoC are powered up through those two pieces of code?

    The ROM code will read the BOOTMODE and MCU_BOOTMODE pins to determine the Primary and Secondary boot mode. It will only configure the limited set of PLLs needed to fetch the first SW configurable bootloader (tiboot3.bin) which runs on the MCU R5F. It is then the job of the bootloader to configure more PLLs based on application requirement.

    felix_123 said:
    The reason behind this question is, that I am curious about the big time difference when setting the board to "No-Boot"-Mode and connect it to a CCS debug session via launch.js script (takes up to 3 min using Blackhawk XDS560 v2 Debugger) and, for instance, the "normal" booting sequence from SD card (to U-Boot prompt, it takes only about 5s).

    The "no boot" mode is a no ROM boot mode, here no ROM code runs on the device and it is upto the GEL files to do all the initializations. Also the GEL files are very generic and do initialization of the whole SoC so that any application can run we run the GEL files. For example a simple application just accessing some MCU domain memory running on the MCU R5F will also have the overhead of initialization of the MAIN domain peripherals, DDR etc.

    And as these are loaded via JTAG, the HOST PC configuration and choice of JTAG determines the time of execution of the script. The script also loads the DMSC firmware which also goes over via the JTAG interface. All (or Only a subset) of these things happen in lets say an MMCSD boot and also the firmware is fetched from a much faster memory. So essentially a better machine and JTAG will reduce the time of launch.js. If you have a VM you can try changing its configuration to see this.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Expert 1251 points

    Hi Karan,

    thank you for your answers.

    Karan Saxena said:
    The bootloader can not re-configure and configure more PLLs (overriding the ROM defaults if needed).

    Just for further clarification: Is "not" correct here?

    Karan Saxena said:
    It is then the job of the bootloader to configure more PLLs based on application requirement.

    I found arch/arm/mach-k3/j721e/clk-data.c in the U-Boot source files. The devices which are powered up here make total sense and also match with the description given here (https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721e/clocks.html). Is this the correct place where R5 SPL (tiboot3.bin) gets information about which modules are powered up / which PLLs are to be configured? Or is this done via the device tree files?

    Thanks again and best regards,

    Felix

  • 0 in reply to felix_123
    TI__Guru* 77704 points

    Hi Felix,

    felix_123 said:
    Just for further clarification: Is "not" correct here?

    Sorry, I meant "now" not "not", updated my previous reply fixing the typo.

    felix_123 said:
    I found arch/arm/mach-k3/j721e/clk-data.c in the U-Boot source files. The devices which are powered up here make total sense and also match with the description given here (https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721e/clocks.html). Is this the correct place where R5 SPL (tiboot3.bin) gets information about which modules are powered up / which PLLs are to be configured? Or is this done via the device tree files?

    Let me check the code for this.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    TI__Guru* 77704 points

    Hi Felix,

    Karan Saxena said:
    felix_123 said:
    I found arch/arm/mach-k3/j721e/clk-data.c in the U-Boot source files. The devices which are powered up here make total sense and also match with the description given here (https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721e/clocks.html). Is this the correct place where R5 SPL (tiboot3.bin) gets information about which modules are powered up / which PLLs are to be configured? Or is this done via the device tree files?

    This is the list being used by R5 SPL. This gets consumed by the clk driver, see drivers/clk/clk-k3.c.

    Regards,

    Karan

  • 0 in reply to Karan Saxena
    Expert 1251 points

    Hi Karan,

    thank you for conforming, this was really helpful.

    I have got one last (a little bit off topic) question:

    Where is the place to activate Clocks/Devices in Linux Kernel? I think this is most probably done in the Device Tree files. PCIE1 Module for instance has the following entry in arch/arm64/boot/dts/ti/k3-j721e-main.dtsi:

    pcie1_rc: pcie@2910000 {
		compatible = "ti,j721e-pcie-host";
		reg = <0x00 0x02910000 0x00 0x1000>,
		      <0x00 0x02917000 0x00 0x400>,
		      <0x00 0x0d800000 0x00 0x00800000>,
		      <0x00 0x18000000 0x00 0x00001000>;
		reg-names = "intd_cfg", "user_cfg", "reg", "cfg";
		ti,syscon-pcie-ctrl = <&pcie1_ctrl>;
		max-link-speed = <3>;
		num-lanes = <2>;
		power-domains = <&k3_pds 240 TI_SCI_PD_EXCLUSIVE>;
		clocks = <&k3_clks 240 1>;
		clock-names = "fck";
		#address-cells = <3>;
		#size-cells = <2>;
		bus-range = <0x0 0xf>;
		cdns,max-outbound-regions = <16>;
		cdns,no-bar-match-nbits = <64>;
		vendor-id = /bits/ 16 <0x104c>;
		device-id = /bits/ 16 <0xb00d>;
		msi-map = <0x0 &gic_its 0x10000 0x10000>;
		dma-coherent;
		ranges = <0x01000000 0x0 0x18001000  0x00 0x18001000  0x0 0x0010000>,
			 <0x02000000 0x0 0x18011000  0x00 0x18011000  0x0 0x7fef000>;
		#interrupt-cells = <1>;
		interrupt-map-mask = <0 0 0 7>;
		interrupt-map = <0 0 0 1 &pcie1_intc 0>, /* INT A */
				<0 0 0 2 &pcie1_intc 0>, /* INT B */
				<0 0 0 3 &pcie1_intc 0>, /* INT C */
				<0 0 0 4 &pcie1_intc 0>; /* INT D */

		pcie1_intc: legacy-interrupt-controller {
			interrupt-controller;
			#interrupt-cells = <2>;
			interrupt-parent = <&gic500>;
			interrupts = <GIC_SPI 324 IRQ_TYPE_EDGE_RISING>;
		};
	};

    the field "clocks" would match with the already mentioned device list (https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721e/devices.html), because of the Device ID 240. If this is the correct place to activate Modules in Linux, then there is still a missing link to how Linux knows the correct frequency to power up this module? Can you point me to the right direction where this is done?

    For context: J721E_DEV_PCIE1 for instance is neither activated in R5 SPL, nor in U-Boot. I verified this by using an Baremetal application for MCU2_0, which consumes J721E_DEV_PCIE1. This application throws errors, when executed after U-Boot boot (The corresponding option to activate the Clocks is not passed to theBoard_init() function). After Linux has booted, J721E_DEV_PCIE1 is enabled and this previous mentioned application works as expected.

    Thanks again and best regards

    Felix