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.

Linux/DRA750: Jacinto 6 memory map layout

Part Number: DRA750


Tool/software: Linux

Hi all,

I am working on getting hypervisor up on DRA75X board based on Processor-SDK, xen 4.10. Xen is up but I kernel is crashing(dom0). I suspect the problem of crash is due to the memory map not being handled properly as xen is introduced.

I would like to know how can I modify the memory layout of J6 in processor sdk. 

Attaching logs of boot for your reference.

Please provide your inputs.

Thanks,

Prabhuraj

reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2014.07-00035-gdcde330-dirty (Nov 17 2017 - 23:38:38)

CPU  : DRA752 ES1.0
Board: DRA7xx
I2C:   ready
DRAM:  1.5 GiB
WARNING: Caches not enabled
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst 
scanning bus for devices...
Found 0 device(s).
SCSI:  Net:   <ethaddr> not set. Validating first E-fuse MAC
cpsw
Hit any key to stop autoboot:  0 
U-Boot# 
U-Boot# fatload mmc 0:1 0x80000000 4.10_xen-uImage
reading 4.10_xen-uImage
852040 bytes read in 49 ms (16.6 MiB/s)
U-Boot# fatload mmc 0:1 0xc0000000 zImage
reading zImage
3646776 bytes read in 173 ms (20.1 MiB/s)
U-Boot# fatload mmc 0:1 0xc2f00000 dra7-evm.dtb
reading dra7-evm.dtb
109004 bytes read in 9 ms (11.5 MiB/s)
U-Boot# bootm 0x80000000 - 0xc2f00000
## Booting kernel from Legacy Image at 80000000 ...
   Image Name:   XEN
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    851976 Bytes = 832 KiB
   Load Address: 80000000
   Entry Point:  80000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at c2f00000
   Booting using the fdt blob at 0xc2f00000
   Loading Kernel Image ... OK
   Using Device Tree in place at c2f00000, end c2f1d9cb

Starting kernel ...

- UART enabled -
- CPU 00000000 booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 0000000080000000 - 00000000dfffffff
(XEN) 
(XEN) MODULE[0]: 00000000c2f00000 - 00000000c2f1b000 Device Tree  
(XEN) MODULE[1]: 00000000c0000000 - 00000000c1000000 Kernel       
(XEN) MODULE[2]: 00000000c3000000 - 00000000c3010000 XSM          
(XEN)  RESVD[0]: 00000000c2f00000 - 00000000c2f1b000
(XEN) 
(XEN) Command line: dom0_mem=0x100000 console=dtuart dtuart=serial0 dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1
(XEN) parameter "flask_enforcing" unknown!
(XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000
(XEN) Update BOOTMOD_XEN from 0000000080000000-0000000080115781 => 00000000dfe00000-00000000dff15781
(XEN) Xen heap: 00000000da000000-00000000de000000 (16384 pages)
(XEN) Dom heap: 376832 pages
(XEN) Domain heap initialised
(XEN) Booting using Device Tree
(XEN) Platform: TI DRA7
(XEN) Looking for dtuart at "serial0", options ""
(XEN) omap-uart: Unable to retrieve the IRQ
(XEN) Unable to initialize dtuart: -22
(XEN) Bad console= option 'dtuart'
 Xen 4.10.0-rc
(XEN) Xen version 4.10.0-rc (prabhuraj@) (arm-linux-gnueabihf-gcc (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) 4.8.4) debug=y  Mon Nov 13 18:23:18 IS
T 2017
(XEN) Latest ChangeSet: Mon Nov 6 11:35:23 2017 +0100 git:92f0d43
(XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
(XEN) 32-bit Execution:
(XEN)   Processor Features: 00001131:00011011
(XEN)     Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN)     Extensions: GenericTimer Security
(XEN)   Debug Features: 02010555
(XEN)   Auxiliary Features: 00000000
(XEN)   Memory Model Features: 10201105 20000000 01240000 02102211
(XEN)  ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
(XEN) /psci method must be smc, but is: "hvc"
(XEN) Set AuxCoreBoot1 to 00000000dfe0004c (0020004c)
(XEN) Set AuxCoreBoot0 to 0x20
(XEN) SMP: Allowing 2 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 6144 KHz
(XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected 0x2000
(XEN) GICv2 initialization:
(XEN)         gic_dist_addr=0000000048211000
(XEN)         gic_cpu_addr=0000000048212000
(XEN)         gic_hyp_addr=0000000048214000
(XEN)         gic_vcpu_addr=0000000048216000
(XEN)         gic_maintenance_irq=25
(XEN) GICv2: 192 lines, 2 cpus, secure (IID 0000043b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Allocated console ring of 16 KiB.
(XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
(XEN) Bringing up CPU1
- CPU 00000001 booting -
- Xen starting in Hyp mode -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) CPU 1 booted.
(XEN) Brought up 2 CPUs
(XEN) P2M: 40-bit IPA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558
(XEN) I/O virtualisation disabled
(XEN) build-id: e115fd5c4c7e13be00969c6569ff9325d9b5fd81
(XEN) alternatives: Patching with alt table 100b7540 -> 100b7570
(XEN) grant_table.c:1688:IDLEv0 Expanding d0 grant table from 0 to 1 frames
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 00000000c0000000
(XEN) Allocating 1:1 mappings totalling 1024MB for dom0:
(XEN) BANK[0] 0x00000080000000-0x000000c0000000 (1024MB)
(XEN) Grant table range: 0x000000dfe00000-0x000000dfe40000
(XEN) Loading zImage from 00000000c0000000 to 0000000087c00000-0000000087f7a538
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x0000000088000000-0x000000008801a6b2
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 288kB init memory.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.4.84-g7e6588b179 (prabhuraj@prabhuraj-E40) (gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02) ) #17 SMP PREEMP
T Mon Dec 4 16:56:47 IST 2017
[    0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Machine model: TI DRA742
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Reserved memory: created CMA memory pool at 0x0000000095800000, size 56 MiB
[    0.000000] Reserved memory: initialized node ipu2_cma@95800000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x0000000099000000, size 64 MiB
[    0.000000] Reserved memory: initialized node dsp1_cma@99000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x000000009d000000, size 32 MiB
[    0.000000] Reserved memory: initialized node ipu1_cma@9d000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x000000009f000000, size 8 MiB
[    0.000000] Reserved memory: initialized node dsp2_cma@9f000000, compatible id shared-dma-pool
[    0.000000] cma: Reserved 24 MiB at 0x00000000be000000
[    0.000000] Forcing write-allocate cache policy for SMP
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] OMAP4: Map 0x00000000bfd00000 to fe600000 for dram barrier
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv0.2 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] Xen 4.10 support found
[    0.000000] DRA752 ES1.0
(XEN) traps.c:2081:d0v0 HSR=0x93800007 pc=0xc002bb38 gva=0xfa243404 gpa=0x00000048243404
[    0.000000] Unhandled fault: debug event (0x222) at 0xfa243404
[    0.000000] pgd = c0003000
[    0.000000] [fa243404] *pgd=80000080007003, *pmd=affab003, *pte=c0000048243713
[    0.000000] Internal error: : 222 [#1] PREEMPT SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.84-g7e6588b179 #17
[    0.000000] Hardware name: Generic DRA74X (Flattened Device Tree)
[    0.000000] task: c0969c38 ti: c0964000 task.ti: c0964000
[    0.000000] PC is at omap4_prminst_read_inst_reg+0x2c/0x40
[    0.000000] LR is at omap4_pwrdm_wait_transition+0x54/0x80
[    0.000000] pc : [<c002bb30>]    lr : [<c002b8d0>]    psr: a00000d3
[    0.000000] sp : c0965e88  ip : c09b8398  fp : c0965e94
[    0.000000] r10: c0949938  r9 : 00000000  r8 : 000186a1
[    0.000000] r7 : c0983e78  r6 : 0001a36e  r5 : c096d588  r4 : 00000001
[    0.000000] r3 : fa243404  r2 : 00000004  r1 : 00000404  r0 : 00000005
[    0.000000] Flags: NzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
[    0.000000] Control: 30c5387d  Table: 80003000  DAC: fffffffd
[    0.000000] Process swapper (pid: 0, stack limit = 0xc0964210)
[    0.000000] Stack: (0xc0965e88 to 0xc0966000)
[    0.000000] 5e80:                   c0965ebc c0965e98 c002b8d0 c002bb10 c096d588 c096c860
[    0.000000] 5ea0: c095620c c09b83d8 c0847ffc 00000000 c0965ee4 c0965ec0 c002cbc4 c002b888
[    0.000000] 5ec0: c096994c 00000000 00000001 00000001 c09665c8 00000000 c0965ef4 c0965ee8
[    0.000000] 5ee0: c091d6a8 c002cab0 c0965f0c c0965ef8 c0917cc8 c091d690 00000000 c096994c
[    0.000000] 5f00: c0965f9c c0965f10 c0911f14 c0917c94 00000000 00000000 00000000 00000000
[    0.000000] 5f20: ffffffff 00000000 c0922c44 c096adc0 bfcfffff 00000000 bfd00000 00000000
[    0.000000] 5f40: 000bfd00 00000000 000bfc00 00000000 bfc00000 00000000 00000000 00000000
[    0.000000] 5f60: 00000000 00000001 00000000 00000000 c0965f9c 00000000 00007000 00000000
[    0.000000] 5f80: 00000000 ffffffff c0966400 00000000 c0965ff4 c0965fa0 c090ea34 c09113ec
[    0.000000] 5fa0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    0.000000] 5fc0: 00000000 c0951e2c 00000000 c09b7ad4 c0966488 c0951e28 c096af10 80007000
[    0.000000] 5fe0: 412fc0f2 00000000 00000000 c0965ff8 80008090 c090e994 00000000 00000000
[    0.000000] Backtrace: 
[    0.000000] [<c002bb04>] (omap4_prminst_read_inst_reg) from [<c002b8d0>] (omap4_pwrdm_wait_transition+0x54/0x80)
[    0.000000] [<c002b87c>] (omap4_pwrdm_wait_transition) from [<c002cbc4>] (pwrdm_register_pwrdms+0x120/0x180)
[    0.000000]  r9:00000000 r8:c0847ffc r7:c09b83d8 r6:c095620c r5:c096c860 r4:c096d588
[    0.000000] [<c002caa4>] (pwrdm_register_pwrdms) from [<c091d6a8>] (dra7xx_powerdomains_init+0x24/0x2c)
[    0.000000]  r9:00000000 r8:c09665c8 r7:00000001 r6:00000001 r5:00000000 r4:c096994c
[    0.000000] [<c091d684>] (dra7xx_powerdomains_init) from [<c0917cc8>] (dra7xx_init_early+0x40/0xa4)
[    0.000000] [<c0917c88>] (dra7xx_init_early) from [<c0911f14>] (setup_arch+0xb34/0xb60)
[    0.000000] [<c09113e0>] (setup_arch) from [<c090ea34>] (start_kernel+0xac/0x40c)
[    0.000000]  r10:00000000 r9:c0966400 r8:ffffffff r7:00000000 r6:00000000 r5:00007000
[    0.000000]  r4:00000000
[    0.000000] [<c090e988>] (start_kernel) from [<80008090>] (0x80008090)
[    0.000000]  r10:00000000 r9:412fc0f2 r8:80007000 r7:c096af10 r6:c0951e28 r5:c0966488
[    0.000000]  r4:c09b7ad4
[    0.000000] Code: e34cc09b e79c3100 e3530000 0a000003 (e0811002) 
[    0.000000] ---[ end trace cb88537fdc8fa200 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!


  • Hi Prabhuraj,

    I have forwarded your question to a Linux expert.

    Regards,
    Yordan
  • Hi
    Not sure if we understand the question here. when hypervisor(xen or others) is enabled, the hypervisor manages the second stage ARM MMU translations and the first stage is still left to the OS(linux) - this process should be seamless to the OS and it might even be unaware that it is running on top of a hypervisor.

    In the simplest of cases, you might just want to retain 1-1 mapping for the second stage translation

    Can you explain , what changes you envisage so that it would be easier to guide through the process
  • Hi Srirama,

    Thanks for your reply. In Vision SDK we can find .xs file (eg mem_segment_definition_linux.xs). I am actually looking for memory layout file in Processor SDK - dra7xx board.

    Thanks,

    Prabhuraj

  • Hello Prabhuraj,

    Linux kernel memory map is managed by kernel.
    You should find this printed in the log when the regular kernel is booting.
    If you have some reserved memory sections, they will be described in the device tree


    Nikhil D
  • Thanks for your valuable reply Nikhil.

    I understand that Linux memory mapping is managed in kernel and DT. Where's is IPU, DSP, EVE etc memory mapping done in PSDK for DRA7X.
    My use case is, let's say the EVK 's DDR is 1.5GB, our custom board has 2GB. Now, I would like to distribute 2GB DDR memory to Linux, Sys/Bios, DSP, IPU, EVE cores etc..
    The above is done in .xs file in Vision SDK. Where's it done in Processor SDK for DRA7XX?
    Also, when I Download vision SDK, I can see index.html which gives links to all the documents. Is there a similar index.html for PSDK?
    Please let me know.

    Regards,
    Prabhuraj
  • Hi Prabhuraj, All of this info is described in the DTS file. For each of IPU DSP, you'll find reserved_memory nodes. And for the shared regions (SR0, SR1) you'll find some more reserved_memory nodes. By default everything is owned by Linux, entire 2GB Reserved_memory is a way to taking out some chunks from Linux This is used to allocate memory to VSDK The regions needed by VSDK (described in xs file) should match with the ones reserved in Linux (described in DT) I hope this clarification helps Regards, Nikhil D
  • Sure Nikhil. This clarifies my question.

    Regards,
    Prabhuraj