Linux/DRA76P: Boot DRA76p with three spooky oops...

Hi Marco,

I have forwarded your question to kernel experts.

Can you just upload complete boot log?

Regards,
Yordan

It seems to be a problem bringing up the special, internal oscillated timer12 of the TDA2P:

------------[ cut here ]------------
[    0.635800] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2108 _enable+0x2b8/0x2d0()
[    0.635808] omap_hwmod: timer12: enabled state can only be entered from initialized, idle, or disabled state
[    0.635815] Modules linked in:
[    0.635830] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.4.84XXXXX#2
[    0.635838] Hardware name: Generic DRA74X (Flattened Device Tree)
[    0.635845] Backtrace: 
[    0.635866] [<c0012934>] (dump_backtrace) from [<c0012ad0>] (show_stack+0x18/0x1c)
[    0.635874]  r6:20000093 r5:ffffffff r4:00000000 r3:00000000
[    0.635905] [<c0012ab8>] (show_stack) from [<c028ff24>] (dump_stack+0x7c/0x9c)
[    0.635919] [<c028fea8>] (dump_stack) from [<c003f0c8>] (warn_slowpath_common+0x7c/0xb8)
[    0.635926]  r6:c06b5cf8 r5:0000083c r4:eec8dc70 r3:eec8c000
[    0.635952] [<c003f04c>] (warn_slowpath_common) from [<c003f1a8>] (warn_slowpath_fmt+0x38/0x40)
[    0.635959]  r8:00000004 r7:c00319f0 r6:a0000093 r5:ffffffea r4:c07afb40
[    0.635987] [<c003f174>] (warn_slowpath_fmt) from [<c00302c4>] (_enable+0x2b8/0x2d0)
[    0.635994]  r3:c06b823c r2:c06b617c
[    0.636013] [<c003000c>] (_enable) from [<c00307b8>] (omap_hwmod_enable+0x2c/0x4c)
[    0.636019]  r7:c00319f0 r6:a0000093 r5:c07afba0 r4:c07afb40
[    0.636045] [<c003078c>] (omap_hwmod_enable) from [<c003199c>] (omap_device_enable+0x48/0x9c)
[    0.636051]  r6:eee3b6c0 r5:00000000 r4:00000001 r3:eee3b700
[    0.636076] [<c0031954>] (omap_device_enable) from [<c0031a08>] (_od_runtime_resume+0x18/0x2c)
[    0.636083]  r6:c00319f0 r5:eee4fa74 r4:eee4fa10 r3:00000000
[    0.636111] [<c00319f0>] (_od_runtime_resume) from [<c032c6f4>] (__rpm_callback+0x34/0x68)
[    0.636117]  r4:eee4fa10 r3:00000000
[    0.636136] [<c032c6c0>] (__rpm_callback) from [<c032c750>] (rpm_callback+0x28/0x88)
[    0.636143]  r6:eee06c10 r5:c079c100 r4:eee4fa10 r3:00000002
[    0.636168] [<c032c728>] (rpm_callback) from [<c032d528>] (rpm_resume+0x384/0x4fc)
[    0.636175]  r5:c079c100 r4:eee4fa10
[    0.636191] [<c032d1a4>] (rpm_resume) from [<c032d90c>] (__pm_runtime_resume+0x54/0x6c)
[    0.636197]  r10:eee39880 r9:c078683c r8:eee398a8 r7:60000013 r6:00000004 r5:eee4fa74
[    0.636222]  r4:eee4fa10
[    0.636237] [<c032d8b8>] (__pm_runtime_resume) from [<c003b244>] (omap_dm_timer_probe+0x198/0x3e8)
[    0.636244]  r7:c0577ef0 r6:eee4fa10 r5:eee4fa00 r4:eef550d0
[    0.636271] [<c003b0ac>] (omap_dm_timer_probe) from [<c03269f0>] (platform_drv_probe+0x58/0xb8)
[    0.636278]  r10:00000000 r8:00000000 r7:c07b0a5c r6:fffffdfb r5:eee4fa10 r4:ffffffed
[    0.636309] [<c0326998>] (platform_drv_probe) from [<c03254d4>] (driver_probe_device+0x1e8/0x2b0)
[    0.636316]  r7:c07b0a5c r6:00000000 r5:c0823d9c r4:eee4fa10
[    0.636342] [<c03252ec>] (driver_probe_device) from [<c0325630>] (__driver_attach+0x94/0x98)
[    0.636348]  r8:c075427c r7:00000000 r6:eee4fa44 r5:c07b0a5c r4:eee4fa10 r3:00000000
[    0.636379] [<c032559c>] (__driver_attach) from [<c0323a40>] (bus_for_each_dev+0x5c/0x90)
[    0.636385]  r6:c032559c r5:c07b0a5c r4:00000000 r3:00000000
[    0.636410] [<c03239e4>] (bus_for_each_dev) from [<c0324dc4>] (driver_attach+0x24/0x28)
[    0.636417]  r6:c07d64e0 r5:eef52600 r4:c07b0a5c
[    0.636439] [<c0324da0>] (driver_attach) from [<c0324b40>] (bus_add_driver+0xf0/0x1fc)
[    0.636452] [<c0324a50>] (bus_add_driver) from [<c0325c74>] (driver_register+0x80/0xfc)
[    0.636458]  r7:00000077 r6:eef53040 r5:c07a29a8 r4:c07b0a5c
[    0.636483] [<c0325bf4>] (driver_register) from [<c032688c>] (__platform_driver_register+0x4c/0x50)
[    0.636489]  r5:c07a29a8 r4:c07a29a8
[    0.636506] [<c0326840>] (__platform_driver_register) from [<c0754294>] (omap_dm_timer_driver_init+0x18/0x20)
[    0.636517] [<c075427c>] (omap_dm_timer_driver_init) from [<c0009820>] (do_one_initcall+0x8c/0x1dc)
[    0.636531] [<c0009794>] (do_one_initcall) from [<c0744f08>] (kernel_init_freeable+0x1a4/0x270)
[    0.636538]  r10:00000000 r9:c078683c r8:c0786830 r7:00000077 r6:c07ec000 r5:00000006
[    0.636561]  r4:c0793c08
[    0.636577] [<c0744d64>] (kernel_init_freeable) from [<c056f450>] (kernel_init+0x10/0x100)
[    0.636583]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c056f440
[    0.636607]  r4:00000000
[    0.636620] [<c056f440>] (kernel_init) from [<c000fc08>] (ret_from_fork+0x14/0x2c)
[    0.636626]  r4:00000000 r3:eec8c000
[    0.636640] ---[ end trace 74ff43b142d21e53 ]---
[    0.636654] omap_timer 4ae20000.timer: omap_dm_timer_probe: pm_runtime_get_sync failed!
[    0.636680] omap_timer: probe of 4ae20000.timer failed with error -22

Other problem is related to MCAN bring up: 

------------[ cut here ]------------
[    0.265281] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2529 _init+0x324/0x430()
[    0.265288] omap_hwmod: mcan: couldn't init clocks
[    0.265296] Modules linked in:
[    0.265313] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.84XXXXXX#2
[    0.265321] Hardware name: Generic DRA74X (Flattened Device Tree)
[    0.265329] Backtrace: 
[    0.265352] [<c0012934>] (dump_backtrace) from [<c0012ad0>] (show_stack+0x18/0x1c)
[    0.265360]  r6:60000013 r5:ffffffff r4:00000000 r3:00000000
[    0.265395] [<c0012ab8>] (show_stack) from [<c028ff24>] (dump_stack+0x7c/0x9c)
[    0.265410] [<c028fea8>] (dump_stack) from [<c003f0c8>] (warn_slowpath_common+0x7c/0xb8)
[    0.265418]  r6:c06b5cf8 r5:000009e1 r4:eec8de58 r3:00000000
[    0.265447] [<c003f04c>] (warn_slowpath_common) from [<c003f1a8>] (warn_slowpath_fmt+0x38/0x40)
[    0.265455]  r8:ffffffea r7:00000000 r6:ffffffea r5:0000000c r4:c07afa30
[    0.265488] [<c003f174>] (warn_slowpath_fmt) from [<c0751144>] (_init+0x324/0x430)
[    0.265495]  r3:c06b8228 r2:c06b60e8
[    0.265518] [<c0750e20>] (_init) from [<c003064c>] (omap_hwmod_for_each+0x38/0x64)
[    0.265525]  r10:00000000 r8:c07519b0 r7:00000000 r6:c0750e20 r5:c07a7150 r4:c07afa30
[    0.265561] [<c0030614>] (omap_hwmod_for_each) from [<c07519dc>] (__omap_hwmod_setup_all+0x2c/0x48)
[    0.265568]  r7:00000077 r6:eede2a80 r5:c07a29a8 r4:c07a29a8
[    0.265597] [<c07519b0>] (__omap_hwmod_setup_all) from [<c0009820>] (do_one_initcall+0x8c/0x1dc)
[    0.265612] [<c0009794>] (do_one_initcall) from [<c0744f08>] (kernel_init_freeable+0x1a4/0x270)
[    0.265620]  r10:00000000 r9:c078683c r8:c078681c r7:00000077 r6:c07ec000 r5:00000001
[    0.265647]  r4:c0793908
[    0.265663] [<c0744d64>] (kernel_init_freeable) from [<c056f450>] (kernel_init+0x10/0x100)
[    0.265671]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c056f440
[    0.265698]  r4:00000000
[    0.265713] [<c056f440>] (kernel_init) from [<c000fc08>] (ret_from_fork+0x14/0x2c)
[    0.265720]  r4:00000000 r3:eec8c000
[    0.265746] ---[ end trace 74ff43b142d21e52 ]---

Third problem is related to rng: 

------------[ cut here ]------------
[    2.491786] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2108 _enable+0x2b8/0x2d0()
[    2.500697] omap_hwmod: rng: enabled state can only be entered from initialized, idle, or disabled state
[    2.510217] Modules linked in:
[    2.513296] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.4.84XXXXX#2
[    2.522905] Hardware name: Generic DRA74X (Flattened Device Tree)
[    2.529025] Backtrace: 
[    2.531503] [<c0012934>] (dump_backtrace) from [<c0012ad0>] (show_stack+0x18/0x1c)
[    2.539105]  r6:20000093 r5:ffffffff r4:00000000 r3:00000000
[    2.544838] [<c0012ab8>] (show_stack) from [<c028ff24>] (dump_stack+0x7c/0x9c)
[    2.552099] [<c028fea8>] (dump_stack) from [<c003f0c8>] (warn_slowpath_common+0x7c/0xb8)
[    2.560221]  r6:c06b5cf8 r5:0000083c r4:eec8dc60 r3:eec8c000
[    2.565946] [<c003f04c>] (warn_slowpath_common) from [<c003f1a8>] (warn_slowpath_fmt+0x38/0x40)
[    2.574680]  r8:00000004 r7:c00319f0 r6:a0000013 r5:ffffffea r4:c07afbc8
[    2.581462] [<c003f174>] (warn_slowpath_fmt) from [<c00302c4>] (_enable+0x2b8/0x2d0)
[    2.589238]  r3:c06b508c r2:c06b617c
[    2.592851] [<c003000c>] (_enable) from [<c00307b8>] (omap_hwmod_enable+0x2c/0x4c)
[    2.600452]  r7:c00319f0 r6:a0000013 r5:c07afc28 r4:c07afbc8
[    2.606179] [<c003078c>] (omap_hwmod_enable) from [<c003199c>] (omap_device_enable+0x48/0x9c)
[    2.614738]  r6:eee47bc0 r5:00000000 r4:00000001 r3:eee47c00
[    2.620462] [<c0031954>] (omap_device_enable) from [<c0031a08>] (_od_runtime_resume+0x18/0x2c)
[    2.629108]  r6:c00319f0 r5:eee53874 r4:eee53810 r3:00000000
[    2.634833] [<c00319f0>] (_od_runtime_resume) from [<c032c6f4>] (__rpm_callback+0x34/0x68)
[    2.643133]  r4:eee53810 r3:00000000
[    2.646749] [<c032c6c0>] (__rpm_callback) from [<c032c750>] (rpm_callback+0x28/0x88)
[    2.654522]  r6:eee06c10 r5:c079c100 r4:eee53810 r3:00000000
[    2.660244] [<c032c728>] (rpm_callback) from [<c032d528>] (rpm_resume+0x384/0x4fc)
[    2.667844]  r5:c079c100 r4:eee53810
[    2.671453] [<c032d1a4>] (rpm_resume) from [<c032d90c>] (__pm_runtime_resume+0x54/0x6c)
[    2.679492]  r10:00000000 r9:c078683c r8:c07d6188 r7:60000013 r6:00000004 r5:eee53874
[    2.687400]  r4:eee53810
[    2.689961] [<c032d8b8>] (__pm_runtime_resume) from [<c031bdf4>] (omap_rng_probe+0x84/0x290)
[    2.698432]  r7:c07d619c r6:eee53800 r5:ee598350 r4:eee53810
[    2.704156] [<c031bd70>] (omap_rng_probe) from [<c03269f0>] (platform_drv_probe+0x58/0xb8)
[    2.712454]  r8:00000000 r7:c07d619c r6:fffffdfb r5:eee53810 r4:ffffffed
[    2.719236] [<c0326998>] (platform_drv_probe) from [<c03254d4>] (driver_probe_device+0x1e8/0x2b0)
[    2.728144]  r7:c07d619c r6:00000000 r5:c0823d9c r4:eee53810
[    2.733868] [<c03252ec>] (driver_probe_device) from [<c0325630>] (__driver_attach+0x94/0x98)
[    2.742340]  r8:c0768a68 r7:00000000 r6:eee53844 r5:c07d619c r4:eee53810 r3:00000000
[    2.750167] [<c032559c>] (__driver_attach) from [<c0323a40>] (bus_for_each_dev+0x5c/0x90)
[    2.758378]  r6:c032559c r5:c07d619c r4:00000000 r3:00000000
[    2.764103] [<c03239e4>] (bus_for_each_dev) from [<c0324dc4>] (driver_attach+0x24/0x28)
[    2.772138]  r6:c07d64e0 r5:ee58fe80 r4:c07d619c
[    2.776807] [<c0324da0>] (driver_attach) from [<c0324b40>] (bus_add_driver+0xf0/0x1fc)
[    2.784765] [<c0324a50>] (bus_add_driver) from [<c0325c74>] (driver_register+0x80/0xfc)
[    2.792801]  r7:00000077 r6:ee598300 r5:c07a29a8 r4:c07d619c
[    2.798522] [<c0325bf4>] (driver_register) from [<c032688c>] (__platform_driver_register+0x4c/0x50)
[    2.807604]  r5:c07a29a8 r4:c07a29a8
[    2.811216] [<c0326840>] (__platform_driver_register) from [<c0768a80>] (omap_rng_driver_init+0x18/0x20)
[    2.820740] [<c0768a68>] (omap_rng_driver_init) from [<c0009820>] (do_one_initcall+0x8c/0x1dc)
[    2.829397] [<c0009794>] (do_one_initcall) from [<c0744f08>] (kernel_init_freeable+0x1a4/0x270)
[    2.838131]  r10:00000000 r9:c078683c r8:c0786830 r7:00000077 r6:c07ec000 r5:00000006
[    2.846038]  r4:c0793e0c
[    2.848595] [<c0744d64>] (kernel_init_freeable) from [<c056f450>] (kernel_init+0x10/0x100)
[    2.856893]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c056f440
[    2.864803]  r4:00000000
[    2.867359] [<c056f440>] (kernel_init) from [<c000fc08>] (ret_from_fork+0x14/0x2c)
[    2.874959]  r4:00000000 r3:eec8c000
[    2.878569] ---[ end trace 74ff43b142d21e54 ]---
[    2.883270] omap_rng 48090000.rng: Failed to runtime_get device: -22
[    2.889697] omap_rng 48090000.rng: initialization failed.
[    2.895157] omap_rng: probe of 48090000.rng failed with error -22

Regards,
Marco.

... last minute addition:

Devicetree and Hardware:

Our board is based on TDA2Plus and I use the same dtsi as used on evalboard (only thing I added: 2nd A15 core, works fine).

So: DRA7.dtsi -> DRA74x.dtsi -> DRA76x.dtsi -> mystuff.dts

Is this the correct "line" for tda2plus usage? Choosen the wrong "DRA7-something" not fetching every setting for TDA2Plus...?

There are a lot of different names and I do not understand clearly what they want to tell me:

So there is is a DRA7 Family, but it is also known as "Jacinto"? And on some CPU on evalnboards "5777" is lasered. In linux, there is a lot of OMAP2 stuff used and what the business people of TI told us was we have to use the TDA2Plus... quite confusing ;-) 

And sometimes... sometimes the IPs of SoC uses OMAP5 stuff... well: Can you explain (with a nice chart?) or where can I find such a "smart graphic", which explains the confusing naming?

Oh... and another question: Do you have some devicetree files, or a complete Linux "for the good guys"... with less magic numbers and more abstraction, some #defines, which makes pinmultiplexing less frustrating? (Offset 0x1400, reading registers, looking for mode... and bit-fizzling all time long is no fun at all. Well named defines would be a nice service in good BSPs! By the way: If there are defines, for example naming a register: It would be sooooo nice when it fits the naming in the relating data sheet.... grumbled enough... back to work.) 

TNX Stan!

Marco
Our Software developer's guide includes information about the right DTB(dtb is compiled binary output generated from the dts files) file to choose based on the Jacinto6 part. You can refer processors.wiki.ti.com/.../Processor_SDK_Linux_Automotive_Software_Developers_Guide

For J6plus(or TDA2+), the reference would be dra76-evm.dts - it will include the corresponding dtsi (include files)

Also, please note that Pin mux in case of DRA7x is managed from the bootloader (uboot in case of linux).

You will have to make incremental changes based on differences between your customer board and the TI EVM - would be good if you can summarize those changes for review

Hello Sriram,

Please remember: I do not use the SDK! So the link to the wiki is quite useless for me in this case.

I took kernel and bootloader as a "BSP" out of the SDK and I use the evalboard-config as a start-up point. Our use-case is not captured from any provided SDK. Bad commenting and a lot of magic numbers does not make the job easy. ( I can understand why TI pushes the idea of a "one sdk do everything for every Soc and costumer"... but what we have to do is something completely different. ) 

MUXING...Would you please explain, why pinmuxing in TDA2+ is only managed in u-boot? As I mentioned:

• First, there is the ROM-Code which loads the SPL. The muxing is done in boardfile (SPL-part), the file "mux-data.h" contain. There is an "early" part, and a regular part.
• If dt for uboot is enabled and SPL have loaded uboot, the embedded uboot-dtb blob will be used remuxing the "mux-data.h" and setup needed periphery.
• Uboot loads a dt-blob produced in kernel environment, the kernel, do a little console settings and boot the kernel.

This one uses its own dt-blob and this one is of course able to remux and re-setup nearly (!) everything.

So pinmux can be done (and is done)  in several chunks: Boardfile and "mux-data.h", u-boot dt-blob and last not least the kernel dt-blob.

DT in uboot is no substitution of the DT in Linux, except you activate that functionality which provide u-boot-dt to the kernel: I didn't.

I got some special problems booting the Kernel, because there's something wrong with timer12, rng and mcan. The error messages are able to give some points of reference.

I do not need instructions of how to do something in the environment of the SDK, because (again) I'm not able to use it in our project. 
I need some help from your embedded engineers, who work on the Linux Kernel in its deepest layers. 

Marco
SDK includes the kernel, uboot components and hence i pointed to the SDK documentation as we describe which dtb to refer to for each device in the J6 family - the table was a reference for the dts file that you need to reference and start with for changes at your end.

with respect to pin muxing, bulk of the pin mux configuration is done from early bootloader stage(for configuration of iodelay parameters for each pin). Only for devices which support multiple functional modes like mmc - the speed, mode of operation depends of the card that you detect and hence will program iodelay parameters dynamically from the kernel

And for "TI pushes the idea of a "one sdk do everything for every Soc and costumer" - lot of the peripherals on J6 are reused from earlier generation devices and with Linux , the policy is to reuse(or make generic) existing driver for peripherals reused on multiple platforms - this is just the way Linux community works. Also, the intent from SW perspective is make migration from one platform or use case to another seamless as possible: hence we try to maintain uniform SW IF(SDK) reusing SW wherever possible.

The kernel configuration in SDK is mapped to the features that we can support on the TI EVM - it would be helpful if you can describe your HW platform(differences) and your intended changes for us to review and provide any feedback

I've got a booting system over here and a console on linux works also fine.

The three problems during boot are specified in the posts above.
So please let us focusing on theses three problems and what principally goes wrong.

The main information is: "enabled state can only be entered from initialized, idle, or disabled state"
The timer12 and rng can not be initialized, because there's something wrong with its state.
Double try or race condition? Why, where?

"mcan: couldn't init clocks" is the first problem on my list.
I do not change anything in the dtsi files of linux, especially: I didn't touch the clock domains.
So what mistakes can be made to prevent mcan from init its clocking?

(other information on following posts...)

This is a good explanation of the subject -> Thank you!

This is our first contact with iodelay_recalibration.
Never needed before, never focussed before... without any problems.
... maybe: Not needed at all?
What is Use case to switch to manual mode? I have to find out first... I grep the repo and dokumnents... Thank for this stuff ;-)

Regards... Marco.