data2/text/range/20001-25000/665712.txt

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

Query Text:
Part Number: DRA76P Other Parts Discussed in Thread: TDA2 Tool/software: Linux On a custom board based on DRA76p (esp. TDA2Plus) SoC I've got some problems during linux (4.4.84) boot; (1) omap_hwmod: mcan: couldn't init clocks (2) omap_hwmod: timer12: enabled state can only be entered from initialized, idle, or disabled state (3) omap_hwmod: rng: enabled state can only be entered from initialized, idle, or disabled state ... if this sounds familiar to you, please let me know. TNX - Marco

Responses:
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.)

Hi Marco, I will only be able to answer to a part of your questions. Hope other will be answered soon. - Jacinto6 is an internal nickname of DRA75x/DRA74x family and some other derivatives - 5777 is a pre-production, test SoC of DRA75x/DRA74x and some other derivatives. It may not meet some characteristics like MHz and temp range - DRA75x/DRA74x is the successor of OMAP5, very similar but has some additional peripherals (e.g. DCAN) and some removed - OMAP2 is an early predecessor of OMAP5 (with OMAP3 and OMAP4 in between). Many peripherals such as UART, I2C, SPI did not change much over the time, thats why it is not uncommon to see omap2_ prefix for their drivers. Regarding the TDA2+ , note that it is offered in two packages: one legacy and compatible to DRA75x/DRA74x; and one enhanced but incompatible. The silicon is still very similar to DRA75x/DRA74x in the both packages, and the changes can be found by comparing the respective Data Manuals. Regards, Stan

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...)

IODELAY and how this is implemented,well... lets take a look: #ifdef CONFIG_IODELAY_RECALIBRATION
const struct iodelay_cfg_entry dra72_iodelay_cfg_array_revb[] = {
        {0x6F0, 359, 0}, /* RGMMI0_RXC_IN */
        {0x6FC, 129, 1896}, /* RGMMI0_RXCTL_IN */
        {0x708, 80, 1391}, /* RGMMI0_RXD0_IN */
        {0x714, 196, 1522}, /* RGMMI0_RXD1_IN */
        {0x720, 40, 1860}, /* RGMMI0_RXD2_IN */
        {0x72C, 0, 1956}, /* RGMMI0_RXD3_IN */
.... Okay... there are a few questions about it: What happen if I do not want to do these "iodelay recalibration" and undef "CONFIG_IODELAY_RECALIBRATION" ? It is not possible to introduce more magic numbers in a code like this... ;-) But, one moment... I just remember something: As I remember my latest contact with TI-Processors (long time ago, AM3xxx)... I used the Pinmux-tool to generate this magic-number-coffin automatically...! A long time ago, it was before devicetree started... that it was quite comfortable: Use the pinmux-tool and even the stuff of the complete header-file would be exported... doing pinmux with this output in u-boot... and have fun...! Okay: My problem... we got a processor with ACD package. Is this package integrated in the latest pinmux-tool? (A few days ago... no way... Our processor: TDA2PHArVQACDQ1) AND: Is the pinmux-tool still able to output what I need during "iodelay" pinmuxing and this recalibration of the iodelay per used pin?

Hi Marco, According to the data manual, iodelay are to be programmed to guarantee the timing requirements for each of the signal. There are different options like LEGACY/VIRTUAL/MANUAL mode. Only for MANUAL mode, you'll need to program additional registers. If you remove IODELAY #ifdef, you may face some issues wrt timing syncs. This is not recommended. Also, the iodelay config is to be done while the Chip is in isolation. That's the reason it is done in the bootloader. You can find details on how you can get the iodelay data for the pads you are using git.ti.com/.../iodelay-config Regards, Nikhil D

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.

Hi Marco, You will face timing issues if the iodelay configuration is not done. iodelay configuration makes sure that the switching of different signals all happen at the same time without any relative delay between them. Data sheet explains which modules need the iodelay configuration and different scenarios where VIRTUAL/MANUAL modes are applicable. Regards, Nikhil D