Quantcast
Channel: Processors forum - Recent Threads
Viewing all 17527 articles
Browse latest View live

TDA2PXEVM: Changing MMC for SD card reading in PSDK3.5

$
0
0

Part Number: TDA2PXEVM

Hey,

I am using PSDK3.5 with TDA2PXEVM. I want to change the MMC instance from 1(which is currently used) to 3, to test if file writing with 8bit data bus will accelerate writing frames to sd card.

So far I can`t find where to change the MMC and if it is possible at all.

Where can I adjust the settings to use MMC3?

Also I would like to increase the clk frequency from 10MHz to 19MHz in order to speed up the writing process. Does this work?

regards,

Nicolas Rausch


TDA2EVM5777: Linux/LVDS/Multi-Cam: Load bar calculation issue

$
0
0

Part Number: TDA2EVM5777

Hello,

We are currently exploring multi-camera use-cases in VisionSDK 3.06. We executed the "4CH VIP LVDS capture + SGX MOSAIC + DISPLAY" (lvds_vip_multi_cam_view_sgx_display) use-case using 4 LVDS cameras, and we are getting incorrect but streaming (30 fps) mosaic display. This use-case is built with links that execute on IPU1_0, A15, and SGX cores.

VisionSDK superimposes a bar graph at the bottom of every use-case visualization which shows the load on each core of the SoC. For the above use-case, we expected that the load bars would show higher percentages for IPU1_0, A15, and SGX cores, and low percentages for all the other cores.

Initially, we did not see any loading for the SGX core. We followed the steps mentioned in section 4.3 of the Vision SDK Linux User Guide, and we are now seeing up to 20% load on the SGX core. The load bars for the IPU1_0 and A15 cores do not appear to cross 1%. The real surprise, though, is that the load bar for the IPU2 core shows a load of approximately 13%!

How is this possible? Is this actually the correct output, or is there some issue in the Vision SDK?

Thank you.

PROCESSOR-SDK-AM437X: DDR3 initialization in SBL

$
0
0

Part Number: PROCESSOR-SDK-AM437X

Hello E2E Community,

I have a problem with DDR initialization from the bootloader on a custom board (AM4377 based). My RAM is DDR3 MT41K256M16TW-107 AAT from Micron. 

I have working GEL files for my board and all the test applications are working fine when when loaded from CCS with these GEL files.

Now I have to boot the application from the bootloader (SBL). I take the existing one as a referrence point, put my custom timings and configs and I have a problem!

In GEL files I have this line:

#define DDR3_SDRAM_CONFIG 0x61A213B2 //16-bit DDR3

  //this write initiates and EMIF initialization and also latches values to PHY

WR_MEM_32(EMIF_SDRAM_CONFIG,DDR3_SDRAM_CONFIG);

In my bootloader I reproduce this with this code:

    /* EMIF initialization and also latches values to PHY */
    regVal = pDdrEmifCfg->sdramCfg;
    HW_WR_REG32((SOC_EMIF_ADDRSP0_REG + EMIF_SDRAM_CONFIG), regVal);

But after that any write to SDRAM registers lead to the hang - the board is just stuck and not debuggable anymore.

If I comment this code out it goes further, my SDRAM is initialized, I can copy the application to RAM, I see that it is copied succesfully, but when I try to execute it - nothing happens.

My questions:

1. Is this step of EMIF initialization is realy important?

2. If after that the memory is readable/writibale - why the application in memory can't be executed?

3. How to debug after this point:

   /* Giving control to the application */
    pfnSBLAppEntry = (void (*)(void)) gSblEntryPoint;

    (*pfnSBLAppEntry)( );

I pass the control to application and... what? I'm writing this and I understand that I have to set the H/W breakpoint to address 0x80000000 and see what's going wrong there =)

I will give it a try tonight...

CCS/TMDSICE3359: Profibus DP support

$
0
0

Part Number: TMDSICE3359

Tool/software: Code Composer Studio

I would like to know how to configure TMDSICE3359 eval board for profibus DP application . 

PROCESSOR-SDK-AM335X: WDTimer configuration in MLO

$
0
0

Part Number: PROCESSOR-SDK-AM335X

Issue: If MLO unable to find u-boot watch dog restart is happening after 50 sec of time.

           How to reduce watchdog timer in MLO?

Why I am looking for change in watchdog: 

      As part of my requirement I am maintaining two boot loaders (u-boot) one is primary and other one is backup, I made appropriate changes in SPL code and it is working fine.

      If my primary boot loader corrupted, it is going for backup boot loader but delay is 50 sec(that is MLO restart). I want to  reduce that time.

More information:

Now my layout is like this

SPL start         (SPL copy on 1st block)

SPL end 

SPL.backup1 start (SPL copy on 2nd block)

SPL.backup1 end 

SPL.backup2 start (SPL copy on 3rd block)

SPL.backup2 end 

SPL.backup3 start (SPL copy on 4th block)

SPL.backup3 end

U-Boot1 start

U-Boot1 end

U-Boot2 start

U-Boot2 end

Followed by ENV , kernel, filesytem

Can you help on this?

TMS320DM8168: 4 quadrant video mosaic impossible with processor

$
0
0

Part Number: TMS320DM8168

TMS320DM816 doesn't permit to work with four independent video stream (PAL), in particular the problem is located in VIP1 port. If the streams aren't synchronized the port doesn't work, the problem isn't present with VIP0. How is possible to solve the problem?

CCS/TMS320C6748: Could you please help me boot C6748 from a nor flash ?

$
0
0

Part Number: TMS320C6748

Tool/software: Code Composer Studio

Hello, I  have a customized board based on the tms320C748 and a nor flash. I want to write the flash and let the C6748 boot from the flash. I know that TI provides an example to write the nor flash. I download the "norwriter" example code. However, this project is in ".pjt" format, which is an outdated project format. I imported this project into CCS, but CCS couldn't compile this project. The error is “#10178,attempt to link an object file that is not built for TI C6X".   Since my board is customized, I guess I have to modify the "norwriter" project and obtain a new ". out" file to write my application project to the nor flash. Am I right? 
Would you please help me with the following questions?

1) How can I compile the example project to obtain ". out" file?

2) What should I modify in the example project to fit with my customized board?

Thank you. I desire for your response. 

TDA2SX: tlv320aic34 : Bypass LINE2LP_A --->LEFT_LOP_A no sound on the speaker

$
0
0

Part Number: TDA2SX

Hi,

Iam using tlv320aic34, i want to route LINE2LP_A (single ended aux input) ---> LEFT_LOP_A  and LEFT_LOM_A (differential speaker).

>I am setting below values manually through I2C commands.

register:40, value:0x10

register:80, value:0x80

No voice is coming from speakers

>Can any body guide me through this?

Thanks,

Niraj


Linux/AM3352: About QT Display issue for LIDD Setting

$
0
0

Part Number: AM3352

Tool/software: Linux

Hi SIr 

We used Processor-SDK-04.01.00.06 for development and used LIDD  setting to send data/command to  RA8875 chip for display.

1. in u-boot, it can display normally.

2. in kernel ->QT stage , we have integrated RA8875 TFT driver in the kerenl and can show rootfs data in LCD via FB0.

if we execute "/etc/init.d/matrix-gui-2.0 start" and then execute matrix_browser  -qws http://localhost:80, the error message showed as below 

   Could not set DRM(4) CRTC(24) mode! (Permission denied) 

Do you have any suggestion for it ? 

BR

Yimin

Compiler/AM5716: Out-of-order support

$
0
0

Part Number: AM5716

Tool/software: TI C/C++ Compiler

Hi,

When loading / store specific data in our customers, there is a problem that the cortexA15 stalls.
If the cortexA15 is stalled, it is disconnected from the CCS and can not be connected, so the factors are unknown.

The following compiler is used due to the OS.
CCS: v7.4.0.000015
Compiler: TI v16.9.6.LTS

After various investigations, it turned out that no problem occurs when setting bit 1 of the following register of A15.
Auxiliary Control Register
[22] Force in-order load issue Force in-order load issue:
This is the reset value. 0 Does not force in-order load issue.
1 Forces in-order load issue.

Does TI v16.9.6.LTS not support out-of-order?
Is it possible to avoid it with compile options?

Best Regards,
Shigehiro Tsuda

AM5728: RTOS on Cortex-M4

$
0
0

Part Number: AM5728

Hello,

We use AM5728 for our products and looking at the SoC's datasheet we can use dual Cortex M4. I was planning to run Linux on the main SoC (A15) and use TI-RTOS/SYSBIOS on the Cortex M4. I am not much familiar with the TI-RTOS and hence I need some guidelines to proceed with my goal.

Thanks,

Divyeshkumar

TDA4M_EDP display issue with visual object detection demo

$
0
0

Running the objects detection demo and setting the configuration file to have an output on EDP display, I am not able to see anything. 

In addition, it looks like the display port used to connect the display, has an influence on the running SE. In fact depending where I connect the display cable, the demo runs or not. 

TMS320C6678: Board reset to run new thernet configuration

$
0
0

Part Number: TMS320C6678

I have a client program, running on core0, that has a defined static IP address that allows socket connection with a host PC.

It runs through some Stacktest-like code from the NIMU-emacClientSockets example and outputs a trace:

"Network Added: If-1:10.10.251.50". The socket works well.

I want to send a new program via socket to reboot onto core0 that can also provide a client - socket connection,

but I am unclear what has to be done to kill off (Shutdown?)the old connection and allow the new task to run the stacktest configuration code.

Can I do a SOFTRESET, of some kind, to reinitialise the ethernet so that the new task can start from scratch to connect to the PC?

I can reboot to the new task but I can't get it to produce the

"Network Added: If-1:10.10.251.50". trace.

TDA4M

$
0
0

Working on the TDA4V based design.

I have the following questions:

1) Request for an updated datasheet and hardware manual if available.

2) Preferred way of connecting 2 4GB Micron LPDDR4 devices (MT53B1024M32D4DT)  to the TDA4V for a total of 8 GB of ram.

OMAPL138B-EP: MMCSD_FatfsConsole_lcdkOMAPL138 1-BIT BUS

$
0
0

Part Number: OMAPL138B-EP

Hi

I am trying to modify the MMCSD_FatfsConsole_lcdkOMAPL138_DMA_c674xExampleProject

to a MMCSD_BUS_WIDTH_1BIT;

I have modified the pinmux code and rebuilt the libraries

I have also added

 hwAttrsConfig.supportedBusWidth=MMCSD_BUS_WIDTH_1BIT;
 hwAttrsConfig.inputClk=25000000;

my serial output was:

Card inserted.
All tests have PASSED
0:>ls

I also tried MMCSD_lcdkOMAPL138_DMA_c674xTestProject

And this was my output

-----------------------------------------------------------
Test Details for test ID      = 13
Test Profile[13]: Description = Default Unit Test (Max speed)
Test Profile[13]: PowerCyle   = Required
Test Profile[13] Device Config : Mode        = SOC Default
Test Profile[13] Device Config : BusVoltage  = SOC Default
Test Profile[13] Device Config : BusWidth    = SOC Default
Test Profile[13] Device Config : Interrupt   = SOC Default
------------------------------------------------------------
DMA is enabled
Interrupts are disabled

Performing RAW mode read/write tests ..
Getting SD Card parameters
SD Card: BlockSize = 512,  BlockCount = 0x01ce0000, CardSize = 0x39c000000 bytes
RAW READ/WRITE: Writing test pattern (256 KB) to the SD card starting at sector 0x300000 in 1 block(s) 256 KB each
RAW READ/WRITE: Reading test pattern (256 KB) from the SD card starting at sector 0x300000 in 1 block(s) 256 KB each
RAW READ/WRITE: PASS: Read/Write Success for this size (256 KB)
RAW READ/WRITE: Writing test pattern (512 KB) to the SD card starting at sector 0x300000 in 1 block(s) 512 KB each
RAW READ/WRITE: Reading test pattern (512 KB) from the SD card starting at sector 0x300000 in 1 block(s) 512 KB each
RAW READ/WRITE: PASS: Read/Write Success for this size (512 KB)
RAW READ/WRITE: Writing test pattern (1024 KB) to the SD card starting at sector 0x300000 in 1 block(s) 1024 KB each
RAW READ/WRITE: Reading test pattern (1024 KB) from the SD card starting at sector 0x300000 in 1 blo


AM5728: SPI Device Tree Question

$
0
0

Part Number: AM5728

Hey,

I'm just wondering where is spidev@# defined in for the device tree file? 

As an example I see the following to setup spi: 

P17_37 -> mmc3_dat4.spi4_clk

 P17_35-> mmc3_dat5.spi4_d1

 P17_38 ->mmc3_dat6.spi4_d0

 P17_6    ->mmc3_dat7.spi4_cs0

I added the following in am57xx-beagle-x15.dts:

mcspi4_pins: mcspi4_pins{

             pinctrl-single,pins = <

                       0x394 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*mmc3_dat4.spi4_clk*/

                       0x398 (PIN_INPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*mmc3_dat5.spi4_d1*/

                       0x39C (PIN_OUTPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*mmc3_dat6.spi4_d0*/

                       0x3A0 (PIN_OUTPUT_PULLUP | MANUAL_MODE | MUX_MODE1) /*mmc3_dat7.spi4_cs0*/

             >;

};

&mcspi4 { 
       status = "okay";
       pinctrl-names = "default";
       pinctrl-0 = <&mcspi4_pins>;
       spidev@4 { 
              spi-max-frequency = <24000000>;
              reg = <0>; 
              compatible = "rohm,dh2228fv";
       };
};

So then where is spidev@4 defined in? 

PROCESSOR-SDK-AM65X: Yocto build fails with metadata not deterministic errors

$
0
0

Part Number: PROCESSOR-SDK-AM65X

Hello,

There appears to be an issue with certain TI recipes caching the BB_NUMBER_THREADS variable in a way that causes the taskhash/basehash value check to fail if BB_NUMBER_THREADS is changed in the conf/local.conf file in between builds. I can reproduce this issue with the following recipes ti-ipc-examples-linux ti-ipc-rtos osal-rtos and common-csl-ip-rtos, but I believe it can affect all recipes that include the ti-pdk.bbclass or ti-ipc-rtos.inc files. This issue seems to persist even if you run cleanall on the affected package, which I thought would clean up the sstate cache for the packages and fix the issue but doesn't seem to be the case.

To reproduce the issue with one package, set up a fresh Yocto directory with the oe-layertool-setup.sh pointing to the 05.03.00.07 or 06.00.00.07 configuration file per the Building the SDK documentation. Proceed through the Building the SDK documentation steps but stop at "$ MACHINE=am57xx-evm bitbake arago-base-tisdk-image". Instead, run the following:

MACHINE=am65xx-evm bitbake osal-rtos
MACHINE=am65xx-evm bitbake -f -c cleanall osal-rtos

Edit your conf/local.conf and change BB_NUMBER_THREADS to 4 and run the following:

MACHINE=am65xx-evm bitbake osal-rtos

This should cause errors similar to the following log:

ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: osal-rtos-01.00.00.15A-r0.0 do_configure: Taskhash mismatch c25e0a356da49bba18b84084631ca6ed versus 80255794a8f05d198c56e9efc517019b for /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure
ERROR: Taskhash mismatch c25e0a356da49bba18b84084631ca6ed versus 80255794a8f05d198c56e9efc517019b for /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: osal-rtos-01.00.00.15A-r0.0 do_compile: Taskhash mismatch ef81f3d87a029932c97e03be6da58b4d versus 6010db069ee864382103af946c91a3ae for /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile
ERROR: Taskhash mismatch ef81f3d87a029932c97e03be6da58b4d versus 6010db069ee864382103af946c91a3ae for /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_configure, the basehash value changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce. The metadata is not deterministic and this needs to be fixed.
ERROR: When reparsing /home/mmckee/dev/am6/oe-layersetup/sources/meta-ti/recipes-bsp/osal/osal-rtos_git.bb.do_compile, the basehash value changed from 06b9f5aae08ea444f75eaf2edb9a4870 to a867128f5eba46962ce3393e39b62f02. The metadata is not deterministic and this needs to be fixed.

If you 'cleanall' on the osal-rtos recipe and try to rebuild it, the errors will happen again. The variable change that causes the errors can be confirmed with 'bitbake-diffsigs -t osal-rtos do_configure' or with other task and package names:

$ MACHINE=am65xx-evm bitbake-diffsigs -t osal-rtos do_configure
NOTE: Starting bitbake server...
WARNING: Layer meta-processor-sdk should set LAYERSERIES_COMPAT_meta-processor-sdk in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer browser-layer should set LAYERSERIES_COMPAT_browser-layer in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer meta-processor-sdk should set LAYERSERIES_COMPAT_meta-processor-sdk in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer browser-layer should set LAYERSERIES_COMPAT_browser-layer in its conf/layer.conf file to list the core layer names it is compatible with.
basehash changed from 1696c51b9be80e9e8d65fcda7212df44 to e886dbd2f2dc9f27211a3f4d4fcea3ce
Variable BB_NUMBER_THREADS value changed from '3' to '4'

Is there a way to clear the cache for affected packages so that changing BB_NUMBER_THREADS doesn't cause this issue? Also, can an internal issue be created to fix this in the recipes?

Thanks,

Matt McKee

PROCESSOR-SDK-AM437X: documentation for rtc, power restarts and tps65218 chips

$
0
0

Part Number: PROCESSOR-SDK-AM437X

Just wondering if someone could direct me to some theory of operation documents.  I have Powering the AM335x, AM437x, and AM438x With TPS65218.  Trying to figure out how to use this chip to kick me out of low power sleep.

Linux/AM6548: How to set watchdog timeout timer

$
0
0

Part Number: AM6548

Tool/software: Linux

Hi,

Currently the timeout of AM65XX's watchdog is ~120s, is there any way to change it to another value?

Thanks.

AM5718: Qt 5.12 support

$
0
0

Part Number: AM5718

Hi,

The latest Processor SDK 6.00.00 supports Qt 5.11.3.
Our customers want to use the features of Qt 5.12.0 or later.
Do you have plans to support Qt 5.12.0 or later in the future Processor SDK?

Best Regards,
Shigehiro Tsuda

Viewing all 17527 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>