Can you send me some of the following:

On first boot, the device shows it's Part Number and Model Name along with it's serial number. Can you post a dump of that? The part numbers and speed, etc might be different than what I show, but it should look similar to:

ID data ROM : Gen 2
Model : dm3730 Torpedo
Version Code : -32
Temp Grade : Industrial
Max Speed : 800MHz
Part Number : 1026947
Model Name : SOMDM3730-32-1880AKIR-A
Serial Number: 1215M00009


Can you also tell me what cpuinfo thinks it's max frequency is?

DM-37x# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
800000


Can you also send me which governor is being used?
DM-37x# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand


I would like to compare this information to what would expect to see. Depending on the results, I can give some pointers to improve the speed.

Thank you,

adam

If you change the governor to performance you should see the cpu frequency jump. The processor example I have below is only 800MHz, but you can see the processor speed jump. Power consumption may go up a bit.


# View current processor speed
DM-37x# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
300000

#Set Governor to Performance
DM-37x# echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# View current processor speed
DM-37x# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
800000


adam

Hello Adam,

 

Regarding the frequency issue, there's no mistery, the SOM was actually 800Mhz industrial and the reported frequencies were correct.

What we have finally found is that the loss of performance occurs when using the 2.4.3 BSP u-boot. If we flash the 2.3.2 version that we previously used the performance is the same as we had previously. What can u-boot do that could affect the system that way ? I mean, what does u-boot sets up in the system that the kernel inherits ?

I'm now doing some tests to finally check if the corrupted wifi packets are still reported with the new firmware. Until now the results seem ok.

I look forward to your comments about u-boot.

Thanks.

One of the critical features of u-boot is setting up the L2 cache. We discovered a bug in the L2 cache initialization which affected large screen uses, and certain compiler tool chains. For the 2.4-3 release this was disabled. It will be re-enabled with 2.4-4 release in September, and the L2 cache initialization issues will be corrected.

If you'd prefer to continue to use the older u-boot, I don't think there are any conflicts with the kernel, but I need to check with my colleagues.

Once we release our new BSP, 2.4-4 in September , I would highly suggest you move to it, since it fixes some issues with the L2 cache initialization.

In our testing from 2.4-3 to 2.4-4 the NEON floating point calculations increased approximately 3x in performance do do the corrects in the L2 cache. The L2 cache also increases overall system performance as a whole. The updated u-boot will also increase the SD card speeds significantly so anyone booting from SD or updating NAND images from SD will see a significant reduction in the time it takes.


adam

I talked with my colleagues, and I would like to know if you'd like me to send you a pre-release version of the latest u-boot for your review.

If you like, I would e-mail you a compiled binary (not source code) to evaluate. Let me know if you're interested, and I can contact you privately

adam

Thanks Adam,

 

We use displays that are 800x600 and haven't had any problems with the L2 cache enabled; furthermore, we need to enable it to have a decent performance on the 2.4.3 u-boot. I've tried to enable it by changing (in include/configs/omap3logic.h) these lines:

#if 1
/* L2 was disabled since observed that large displays (720p) weren't working
 * Verify can boot kernel using either XGA or 720p HDMI displays settings */
#define CONFIG_L2_OFF         /* Keep L2 Cache Disabled */
#endif

for these

#if 0
/* L2 was disabled since observed that large displays (720p) weren't working
 * Verify can boot kernel using either XGA or 720p HDMI displays settings */
#define CONFIG_L2_OFF         /* Keep L2 Cache Disabled */
#endif
 

that is, just undefining the CONFIG_L2_OFF #define; unfortunately, when doing that  i'm not able to start the kernel (it just stops and does not even print the "Starting kernel" message). So, what should we do to enable the L2 cache in the 2.4.3 u-boot ?

 

I would suggest changing the toolchain to the 2011 toolchain using ./ltib -c

From the main menu can you select the toolchain to CodeSourcery-2011.09-70 gcc-4.6.1 ARMv5te/glibc-2.13

Unfortunately, the DVSDK tools from TI weren't designed to work with that toolchain, so if you need DVSDK, you'll have to continue to use the 2009 compiler.

With the 2.4-4 release in September, we've patched the DVSDK to work with both the 2009 and 2011 compiler, and the L2 issues are resolved and are not compiler specific.

adam

Hi Adam,

Regarding  the pre-released version, the problem is that we need the source code to patch it for our displays. It could be interesting to evaluate it but  it wouldn't solve the problem.

Changing the toolchain is definitely an option we'll check, but first we'd like to solve the L2 cache problem, hence the question about the source code. Would it be possible for you to give us the instructions to enable the cache on the new BSP ?

 

 

Pedro,

I will be sending you a compressed tarball. I have already looked up your e-mail address.



adam

Hello Adam,

 

We're back from vacation :). With the tarball you last sent me the L2 was activated and everything seemed fine. But this week we've found something strange. Our application uses the OTG to connect to an internal board which delivers a continuous stream of data at 480KB/s; the problem is that with the new BSP we see that, after a wireless disconnection, the USB gets reset, resulting in USB OTG packets loss.

That's not always the case, but happens very frequently, about 2/3 of the times the wifi gets disconnected.

Here is the log:

[ 3052.975860] wlan0: deauthenticated from 00:1a:2b:68:23:c5 (Reason: 4=DISASSOC_DUE_TO_INACTIVITY)
[ 3053.015869] cfg80211: All devices are disconnected, going to restore regulatory settings
[ 3053.024566] cfg80211: Restoring regulatory settings
[ 3053.029754] cfg80211: Kicking the queue
[ 3053.033874] cfg80211: Calling CRDA to update world regulatory domain
[ 3053.058929] wlan0: authenticate with 00:1a:2b:68:23:c5
[ 3053.108093] wlan0: send auth to 00:1a:2b:68:23:c5 (try 1/3)
[ 3053.121948] wlan0: authenticated
[ 3053.132873] wlan0: associate with 00:1a:2b:68:23:c5 (try 1/3)
[ 3053.148834] wlan0: RX AssocResp from 00:1a:2b:68:23:c5 (capab=0x431 status=0 aid=1)
[ 3053.210754] wlan0: associated
[ 3053.274414] wlcore: Association completed.
[ 3053.290832] cfg80211: Updating information on frequency 2412 MHz with regulatory rule:
[ 3053.299346] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.307312] cfg80211: Updating information on frequency 2417 MHz with regulatory rule:
[ 3053.315704] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.323669] cfg80211: Updating information on frequency 2422 MHz with regulatory rule:
[ 3053.332061] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.339996] cfg80211: Updating information on frequency 2427 MHz with regulatory rule:
[ 3053.348388] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.356353] cfg80211: Updating information on frequency 2432 MHz with regulatory rule:
[ 3053.364746] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.372680] cfg80211: Updating information on frequency 2437 MHz with regulatory rule:
[ 3053.381103] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.389068] cfg80211: Updating information on frequency 2442 MHz with regulatory rule:
[ 3053.397552] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.405487] cfg80211: Updating information on frequency 2447 MHz with regulatory rule:
[ 3053.413879] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.421783] cfg80211: Updating information on frequency 2452 MHz with regulatory rule:
[ 3053.430175] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.438079] cfg80211: Updating information on frequency 2457 MHz with regulatory rule:
[ 3053.446441] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.454528] cfg80211: Updating information on frequency 2462 MHz with regulatory rule:
[ 3053.462921] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.470855] cfg80211: Updating information on frequency 2467 MHz with regulatory rule:
[ 3053.479217] cfg80211: 2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.487152] cfg80211: Updating information on frequency 2472 MHz with regulatory rule:
[ 3053.495513] cfg80211: 2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A mBi, 2000 mBm)
[ 3053.503448] cfg80211: Updating information on frequency 2484 MHz with regulatory rule:
[ 3053.511810] cfg80211: 2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A mBi, 2000 mBm)
[ 3053.519744] cfg80211: Disabling freq 5040 MHz
[ 3053.524353] cfg80211: Disabling freq 5060 MHz
[ 3053.528961] cfg80211: Disabling freq 5080 MHz
[ 3053.533569] cfg80211: Disabling freq 5170 MHz
[ 3053.538146] cfg80211: Updating information on frequency 5180 MHz with regulatory rule:
[ 3053.546539] cfg80211: 5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.554565] cfg80211: Updating information on frequency 5190 MHz with regulatory rule:
[ 3053.562927] cfg80211: 5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.570953] cfg80211: Updating information on frequency 5200 MHz with regulatory rule:
[ 3053.579315] cfg80211: 5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.587341] cfg80211: Updating information on frequency 5210 MHz with regulatory rule:
[ 3053.595703] cfg80211: 5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.603729] cfg80211: Updating information on frequency 5220 MHz with regulatory rule:
[ 3053.612091] cfg80211: 5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.620086] cfg80211: Updating information on frequency 5230 MHz with regulatory rule:
[ 3053.628479] cfg80211: 5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.636474] cfg80211: Updating information on frequency 5240 MHz with regulatory rule:
[ 3053.644866] cfg80211: 5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.652862] cfg80211: Updating information on frequency 5260 MHz with regulatory rule:
[ 3053.661254] cfg80211: 5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.669250] cfg80211: Updating information on frequency 5280 MHz with regulatory rule:
[ 3053.677642] cfg80211: 5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.685638] cfg80211: Updating information on frequency 5300 MHz with regulatory rule:
[ 3053.694000] cfg80211: 5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.702026] cfg80211: Updating information on frequency 5320 MHz with regulatory rule:
[ 3053.710388] cfg80211: 5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.718414] cfg80211: Updating information on frequency 5500 MHz with regulatory rule:
[ 3053.726776] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.734802] cfg80211: Updating information on frequency 5520 MHz with regulatory rule:
[ 3053.743164] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.751190] cfg80211: Updating information on frequency 5540 MHz with regulatory rule:
[ 3053.759552] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.767578] cfg80211: Updating information on frequency 5560 MHz with regulatory rule:
[ 3053.775970] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.783966] cfg80211: Updating information on frequency 5580 MHz with regulatory rule:
[ 3053.792358] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.800354] cfg80211: Updating information on frequency 5600 MHz with regulatory rule:
[ 3053.808837] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.816833] cfg80211: Updating information on frequency 5620 MHz with regulatory rule:
[ 3053.825225] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.833221] cfg80211: Updating information on frequency 5640 MHz with regulatory rule:
[ 3053.841613] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.849609] cfg80211: Updating information on frequency 5660 MHz with regulatory rule:
[ 3053.858001] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.865997] cfg80211: Updating information on frequency 5680 MHz with regulatory rule:
[ 3053.874389] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.882415] cfg80211: Updating information on frequency 5700 MHz with regulatory rule:
[ 3053.890808] cfg80211: 5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A mBi, 2000 mBm)
[ 3053.898803] cfg80211: Updating information on frequency 5745 MHz with regulatory rule:
[ 3053.907196] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 2000 mBm)
[ 3053.915100] cfg80211: Updating information on frequency 5765 MHz with regulatory rule:
[ 3053.923492] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 2000 mBm)
[ 3053.931396] cfg80211: Updating information on frequency 5785 MHz with regulatory rule:
[ 3053.939788] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 2000 mBm)
[ 3053.947692] cfg80211: Updating information on frequency 5805 MHz with regulatory rule:
[ 3053.956085] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 2000 mBm)
[ 3053.963989] cfg80211: Updating information on frequency 5825 MHz with regulatory rule:
[ 3053.972381] cfg80211: 5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A mBi, 2000 mBm)
[ 3053.980346] cfg80211: World regulatory domain updated:
[ 3053.985778] cfg80211:  DFS Master region: unset
[ 3053.990386] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 3054.000671] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 3054.009185] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 3054.017669] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 3054.026123] cfg80211:   (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A)
[ 3054.034698] cfg80211:   (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 3054.043273] cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 3054.051818] cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 3054.060302] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 3054.076965] usb 2-1: USB disconnect, device number 12
[ 3054.398132] usb 2-1: new full speed USB device number 13 using musb-hdrc
[ 3054.547821] usb 2-1: New USB device found, idVendor=2504, idProduct=0300
[ 3054.554901] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3054.562438] usb 2-1: Product:   GHT ECG-PC
[ 3054.566894] usb 2-1: Manufacturer: GEM-MED SL / UPC BARCELONA TECH.

Why the usb gets disconnected ?

 

Thanks.

Dear Adam,

 

I have been doing some more tests and the problem is only indirectly related with the new BSP. Is our board, attached to the OTG, that resets when there are no requests after some time. This lack of requests seems related with the load induced by the reconnection process of the wifi. In the 2.3.2 BSP that process did not caused our board to reset, which makes me think that the new driver/firmware does something more that loads the CPU. The only thing that I could think of is to reduce the logs, which i'll test now. Apart from that, do you have any indications as to what could we do to make the reconnection process lighter ? I.e, could we include the modules into the kernel ( I don't know if the modules are reloaded on each disconnection, i suppose they are not )...

 

Thanks.

As an experiment, could you connect your device to a powered hub then connect the powred hub to the OTG port? The OTG port is only capable of handling 100mA. I would like to rule out any power issues first.

I'm going to talk with the developers and see if we can reproduce the issue here.

To answer your other question, I don't believe the Wireless modules are unloaded until you issue rmmod.

If you're using the backports, i am not sure it's going to be possible to integrate them into the kernel due the nature of how they are built, but I'll ask one of the developers.

If you want to lighten the load and the excessive chatter, remove 'ignore_loglevel' from otherbootargs parameter in u-boot. This will quiet down the chatter from the wireless driver, but I don't know how much of an impact it will make on the reconnection to the network.

Do you know what is causing the network disconnections?

adam

Nevermind my last question.


I just noticed your log: DISASSOC_DUE_TO_INACTIVITY

Hello Adam,

I checked the logging approach but it did not work. Just for your information, I am forcing the disconnections. What we need to maintain the 480 KB/s rate as a hard requirement, giving any other task lower priority.

Have you tried an externally powered USB bug between the OTG port and your device? I would like to rule out power issues.

adam

Hi Adam,

 

No, I've not tried using the powered hub. It's not easy because we'll need to build some adaptors. Anyway, the usb disconnection only happens when the supplicant reconnects. It seems more a kind a preemption problem to me. I've tried to use the low latency kernel but wihtout any luck.

Also, I've tried to do a "performance" build (ltib menuconfig -> Kernel default preconfig) but i get problems when compiling the SGX kernel module as lot of symbols are missing:

 

unresolved symbol __tracepoint_module_get in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/omaplfb.ko
unresolved symbol add_preempt_count in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/omaplfb.ko
unresolved symbol lockdep_init_map in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/omaplfb.ko
unresolved symbol mutex_destroy in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/omaplfb.ko
unresolved symbol mutex_lock_nested in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/omaplfb.ko
unresolved symbol preempt_schedule in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/omaplfb.ko
unresolved symbol sub_preempt_count in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/omaplfb.ko
unresolved symbol __rwlock_init in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol _raw_read_lock in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol _raw_read_unlock in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol _raw_spin_lock in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol _raw_spin_lock_irqsave in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol _raw_spin_unlock in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol _raw_spin_unlock_irqrestore in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol _raw_write_lock_irqsave in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol _raw_write_unlock_irqrestore in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol kmem_cache_alloc_trace in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol lockdep_init_map in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol mutex_lock_interruptible_nested in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol mutex_lock_nested in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol trace_hardirqs_off in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko
unresolved symbol trace_hardirqs_on in file /lib/modules/3.0.0-BSP-dm37x-2.4-3/extra/pvrsrvkm.ko

The performance defconfig turns off a bunch of logging and debug information to free up the processor from the burden. I am suprised to see it breaks SGX, but I will look into it.

We're in the final stages of releasing our newer BSP which has some improvements over 2.4-3, so I am going to run some tests on the sgx drivers and see what we find.

We did massage the performance config a bit, but we also found that some of the performance optimizations broke some of of the modulation rates in the T+W, so we were going to document some of that and how to re-enable the couple options for T+W since the defconfig is generic for all DM37 SOM's that we produce and not just the T+W.

If I can reproduce your USB disconnection with Wifi disconnection, I'll enter it into our bug tracking software and see if we can get a resolution. What kind of device are you using on the OTG port?

adam

If you're thinking it's kernel lag, you can try to enable the performance governor which increases the processor speed.

#read current speed
DM-37x# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
300000

# Set Governor to performance
DM-37x# echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

#read current speed
DM-37x# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
800000

The final reading might be 800MHz or 1GHz depending on which module you have.

That would give you higher performance with the debugging enabled.

adam

Can you send me the link to which Graphics library you are using for SGX and the build command you are using?

I'd like to reproduce the issue you are seeing.

thank you,

adam

Adam,

We've alreday fixed the issue. We're using GFX drivers from TI for graphics acceleration. The driver is composed of a set of kernel modules. When one of the modules is loaded, it double locks a semaphore which casues a kernel fault. The kernel fault changes the console log level to 15, so many traces are generated. To fix the issue, the console log level is restored to the initial value to avoid the traces.

Joaquim Duran