Date   

Re: [meta-fsl-arm][PATCH v3 0/8] iMX6 Yocto Support based on 12.09.01 BSP

Gary Thomas <samoht.yrag@...>
 

On 2012-11-27 10:52, Fabio Estevam wrote:
On Tue, Nov 27, 2012 at 1:13 AM, Fabio Estevam <festevam@...> wrote:
On Mon, Nov 26, 2012 at 4:57 PM, Otavio Salvador
<otavio@...> wrote:

In any case this seems to be kernel related and not a BSP issue.
Fabio, could you take a look?
The "failed to read firmware version" seems to be an I2C issue. The
I2C controllers send some commands to the panel, and it is failing.
I think the I2C read failure is normal, as the sabrelite panel is not egalax.

You should use the Hannstar panel.
Hmm, that driver does not build (meta-fsl-arm is up to date):

| drivers/input/touchscreen/p1003_ts.c: In function 'p1003_probe':
| drivers/input/touchscreen/p1003_ts.c:304:2: error: implicit declaration of function 'set_irq_type' [-Werror=implicit-function-declaration]
| cc1: some warnings being treated as errors
| make[3]: *** [drivers/input/touchscreen/p1003_ts.o] Error 1
| make[2]: *** [drivers/input/touchscreen] Error 2
| make[1]: *** [drivers/input] Error 2
| make: *** [drivers] Error 2
| make: *** Waiting for unfinished jobs....
| AR lib/lib.a
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (see /home/local/imx6_poky/tmp/work/sabrelite-amltd-linux-gnueabi/linux-imx-3.0.35-r32.3/temp/log.do_compile.12860 for further information)
ERROR: Task 6 (/home/local/poky-multi/meta-fsl-arm/recipes-kernel/linux/linux-imx_3.0.35.bb, do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 603 tasks of which 599 didn't need to be rerun and 1 failed.
No currently running tasks (599 of 613)

Summary: 1 task failed:
/home/local/poky-multi/meta-fsl-arm/recipes-kernel/linux/linux-imx_3.0.35.bb, do_compile


Re: [meta-fsl-arm][PATCH v3 0/8] iMX6 Yocto Support based on 12.09.01 BSP

Fabio Estevam
 

On Tue, Nov 27, 2012 at 4:13 PM, Gary Thomas <samoht.yrag@...> wrote:

Hmm, that driver does not build (meta-fsl-arm is up to date):

| drivers/input/touchscreen/p1003_ts.c: In function 'p1003_probe':
| drivers/input/touchscreen/p1003_ts.c:304:2: error: implicit declaration of
function 'set_irq_type' [-Werror=implicit-function-declaration]
Try changing it to 'irq_set_irq_type' instead.

Do you know exactly the panel you are using with sabrelite?

Just looked at Boundary Device's git tree and it seems they support 3 panels:
https://github.com/boundarydevices/linux-imx6/blob/boundary-L3.0.35_MX6DQ_ER_1208-Beta/arch/arm/mach-mx6/board-mx6q_sabrelite.c

The original 12.09 BSP from FSL has not been tested/validated on
mx6qsabrelite board. Please compare it with the Boundary Device tree.

Regards,

Fabio Estevam


Re: [meta-fsl-arm][PATCH 1/5] mxsldr: Add recipe

Daiane
 

It looks fine to me.

Daiane


Re: [meta-fsl-arm][PATCH 2/5] amd-gpu-x11-bin-mx51: Use a python function to populate INSANE_SKIP

Daiane
 

It looks fine to me
Daiane


Re: [meta-fsl-arm][PATCH 3/5] meta-toolchain: Include elftosb and mxsldr in toolchain

Daiane
 

it looks fine to me


Re: [meta-fsl-arm][PATCH 4/5] imx-lib: Set PACKAGE_ARCH to MACHINE_ARCH

Daiane
 

Please BUMP both recipes


Daiane


Re: [meta-fsl-arm][PATCH 1/5] mxsldr: Add recipe

Fabio Estevam
 

On Tue, Nov 27, 2012 at 3:21 PM, Otavio Salvador
<otavio@...> wrote:
This provides an USB loader compatible with mxs SoCs and is specially
useful for toolchains.
Toolchains? What do you mean?

+SRCREV = "3463b576b67f03012a59cedd8e55e9d37c5cea76"
+SRC_URI = "git://git.bfuser.eu/git/marex/mxsldr.git;protocol=http"
Isn't this tool supposed to run on the host PC?


Re: [meta-fsl-arm][PATCH 5/5] imx-lib: Fix build system to allow override of CC and AR commands

Daiane
 

it looks fine to me, but it will get a conflict when you BUMP this
file on previous patch.

So, please, send a v2 for this patch

Daiane


Re: [meta-fsl-arm][PATCH v3 0/8] iMX6 Yocto Support based on 12.09.01 BSP

Gary Thomas <samoht.yrag@...>
 

On 2012-11-27 11:17, Fabio Estevam wrote:
On Tue, Nov 27, 2012 at 4:13 PM, Gary Thomas <samoht.yrag@...> wrote:

Hmm, that driver does not build (meta-fsl-arm is up to date):

| drivers/input/touchscreen/p1003_ts.c: In function 'p1003_probe':
| drivers/input/touchscreen/p1003_ts.c:304:2: error: implicit declaration of
function 'set_irq_type' [-Werror=implicit-function-declaration]
Try changing it to 'irq_set_irq_type' instead.

Do you know exactly the panel you are using with sabrelite?

Just looked at Boundary Device's git tree and it seems they support 3 panels:
https://github.com/boundarydevices/linux-imx6/blob/boundary-L3.0.35_MX6DQ_ER_1208-Beta/arch/arm/mach-mx6/board-mx6q_sabrelite.c

The original 12.09 BSP from FSL has not been tested/validated on
mx6qsabrelite board. Please compare it with the Boundary Device tree.
I thought I had your kernel working with this board, but I've tried so many things
in the past few weeks (not to mention all the other boards I try to keep track of!)
My panel is the Nit6X_800x480 which uses the TSC2004 touch controller.

For now, I'll build the kernel using their tree.

Would you entertain patches to make the FSL BSP work with this board
(if I have time)?


Re: [meta-fsl-arm][PATCH v3 0/8] iMX6 Yocto Support based on 12.09.01 BSP

Fabio Estevam
 

On Tue, Nov 27, 2012 at 4:33 PM, Gary Thomas <samoht.yrag@...> wrote:

I thought I had your kernel working with this board, but I've tried so many
things
in the past few weeks (not to mention all the other boards I try to keep
track of!)
My panel is the Nit6X_800x480 which uses the TSC2004 touch controller.

For now, I'll build the kernel using their tree.

Would you entertain patches to make the FSL BSP work with this board
(if I have time)?
If you can generate a patch that fixes touchscreen on 12.09 for
sabrelite, please submit it to the list.


Re: [meta-fsl-arm][PATCH 1/5] mxsldr: Add recipe

Otavio Salvador
 

On Tue, Nov 27, 2012 at 4:30 PM, Fabio Estevam <festevam@...> wrote:
On Tue, Nov 27, 2012 at 3:21 PM, Otavio Salvador
<otavio@...> wrote:
This provides an USB loader compatible with mxs SoCs and is specially
useful for toolchains.
Toolchains? What do you mean?
It will be included in meta-toolchain so host can use it.

+SRCREV = "3463b576b67f03012a59cedd8e55e9d37c5cea76"
+SRC_URI = "git://git.bfuser.eu/git/marex/mxsldr.git;protocol=http"
Isn't this tool supposed to run on the host PC?
Yes but it has nothing that makes it impossible to run in an arm
machine as well. So we inherit native and nativesdk due this.



--
Otavio Salvador O.S. Systems
E-mail: otavio@... http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br


problem building linux-qoriq-sdk-headers in meta-fsl-ppc master branch

Bob Cochran
 

Hello,

While using the poky master branch and the meta-fsl-ppc master branch, I experienced build errors while baking linux-qoriq-sdk-headers. The build reported an error that the two patch files, which are specified in linux-qoriq-sdk.inc, couldn't be fetched.

The two patch files are currently found in poky/meta-fsl-ppc/recipes-kernel/linux.

As a workaround, I created a subdirectory called files and moved the patches there. It then built without further errors.

Do I have a path problem, or was it just wrong to have the patches at the same directory level as the recipes?

Thanks,

Bob


Re: problem building linux-qoriq-sdk-headers in meta-fsl-ppc master branch

McClintock Matthew-B29882 <B29882@...>
 

On Tue, Nov 27, 2012 at 6:52 PM, Bob Cochran <yocto@...> wrote:
Hello,

While using the poky master branch and the meta-fsl-ppc master branch, I
experienced build errors while baking linux-qoriq-sdk-headers. The build
reported an error that the two patch files, which are specified in
linux-qoriq-sdk.inc, couldn't be fetched.

The two patch files are currently found in
poky/meta-fsl-ppc/recipes-kernel/linux.

As a workaround, I created a subdirectory called files and moved the patches
there. It then built without further errors.

Do I have a path problem, or was it just wrong to have the patches at the
same directory level as the recipes?
No, I saw this error too and I'm carrying a fix for it... will post
once it's tested but it will probably be a few days. I just made a
subdir there called files and moved the patches there.

-M


Re: problem building linux-qoriq-sdk-headers in meta-fsl-ppc master branch

Liu Ting-B28495 <B28495@...>
 

Hello Bob,

Seems that no this issue on my side. Poky searched "lots" of directories and found that two patches. Attached the log.do_patch file.
Could you take a look at your log file?

-Ting

-----Original Message-----
From: meta-freescale-bounces@... [mailto:meta-freescale-
bounces@...] On Behalf Of Bob Cochran
Sent: Wednesday, November 28, 2012 8:52 AM
To: meta-freescale@...
Subject: [meta-freescale] problem building linux-qoriq-sdk-headers in
meta-fsl-ppc master branch

Hello,

While using the poky master branch and the meta-fsl-ppc master branch, I
experienced build errors while baking linux-qoriq-sdk-headers. The
build reported an error that the two patch files, which are specified in
linux-qoriq-sdk.inc, couldn't be fetched.

The two patch files are currently found in poky/meta-fsl-ppc/recipes-
kernel/linux.

As a workaround, I created a subdirectory called files and moved the
patches there. It then built without further errors.

Do I have a path problem, or was it just wrong to have the patches at the
same directory level as the recipes?

Thanks,

Bob


_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale


Re: [meta-fsl-ppc denzil] cryptodev kernel module recipe

McClintock Matthew-B29882 <B29882@...>
 

On Tue, Nov 27, 2012 at 11:15 PM, Zhenhua Luo <b19537@...> wrote:
From: Yashpal Dutta <yashpal.dutta@...>

This is a /dev/crypto device driver, equivalent to those in OpenBSD or FreeBSD.
The main idea is to access of existing ciphers in kernel space from userspace,
thus enabling re-use of a hardware implementation of a cipher.

Signed-off-by: Yashpal Dutta <yashpal.dutta@...>
Signed-off-by: Zhenhua Luo <b19537@...>
Should this work on master and danny as well?

-M


Re: problem building linux-qoriq-sdk-headers in meta-fsl-ppc master branch

McClintock Matthew-B29882 <B29882@...>
 

On Tue, Nov 27, 2012 at 9:10 PM, Liu Ting-B28495 <B28495@...> wrote:
Hello Bob,

Seems that no this issue on my side. Poky searched "lots" of directories and found that two patches. Attached the log.do_patch file.
Could you take a look at your log file?
Are you using a recent version of poky master branch? This only occurs
on a fairly recent master.

-M


-Ting


-----Original Message-----
From: meta-freescale-bounces@... [mailto:meta-freescale-
bounces@...] On Behalf Of Bob Cochran
Sent: Wednesday, November 28, 2012 8:52 AM
To: meta-freescale@...
Subject: [meta-freescale] problem building linux-qoriq-sdk-headers in
meta-fsl-ppc master branch

Hello,

While using the poky master branch and the meta-fsl-ppc master branch, I
experienced build errors while baking linux-qoriq-sdk-headers. The
build reported an error that the two patch files, which are specified in
linux-qoriq-sdk.inc, couldn't be fetched.

The two patch files are currently found in poky/meta-fsl-ppc/recipes-
kernel/linux.

As a workaround, I created a subdirectory called files and moved the
patches there. It then built without further errors.

Do I have a path problem, or was it just wrong to have the patches at the
same directory level as the recipes?

Thanks,

Bob


_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale

_______________________________________________
meta-freescale mailing list
meta-freescale@...
https://lists.yoctoproject.org/listinfo/meta-freescale


Re: [meta-fsl-ppc denzil] cryptodev kernel module recipe

Luo Zhenhua-B19537 <B19537@...>
 

I don't think it is urgent to apply it in danny and master now.

I'd like to see what will happen on acceptance of this patch by upstream oe-core/meta-oe.


Best Regards,

Zhenhua

-----Original Message-----
From: McClintock Matthew-B29882
Sent: Wednesday, November 28, 2012 12:54 PM
To: Luo Zhenhua-B19537
Cc: meta-freescale@...; McClintock Matthew-B29882; Dutta
Yashpal-B05456
Subject: Re: [meta-freescale] [meta-fsl-ppc denzil] cryptodev kernel
module recipe

On Tue, Nov 27, 2012 at 11:15 PM, Zhenhua Luo <b19537@...>
wrote:
From: Yashpal Dutta <yashpal.dutta@...>

This is a /dev/crypto device driver, equivalent to those in OpenBSD or
FreeBSD.
The main idea is to access of existing ciphers in kernel space from
userspace, thus enabling re-use of a hardware implementation of a
cipher.

Signed-off-by: Yashpal Dutta <yashpal.dutta@...>
Signed-off-by: Zhenhua Luo <b19537@...>
Should this work on master and danny as well?

-M


Re: [meta-fsl-ppc denzil] cryptodev kernel module recipe

Dutta Yashpal-B05456 <B05456@...>
 

Hi Zhenhua,

I don't understand your statement on urgency. Cryptodev must be part of SDK-1.3.1 release. So,
Keeping it in meta-fsl-ppc is required till upstream completes.

Regards
Yashpal

-----Original Message-----
From: Luo Zhenhua-B19537
Sent: Wednesday, November 28, 2012 10:30 AM
To: McClintock Matthew-B29882
Cc: meta-freescale@...; Dutta Yashpal-B05456
Subject: RE: [meta-freescale] [meta-fsl-ppc denzil] cryptodev kernel
module recipe

I don't think it is urgent to apply it in danny and master now.

I'd like to see what will happen on acceptance of this patch by upstream
oe-core/meta-oe.


Best Regards,

Zhenhua

-----Original Message-----
From: McClintock Matthew-B29882
Sent: Wednesday, November 28, 2012 12:54 PM
To: Luo Zhenhua-B19537
Cc: meta-freescale@...; McClintock Matthew-B29882; Dutta
Yashpal-B05456
Subject: Re: [meta-freescale] [meta-fsl-ppc denzil] cryptodev kernel
module recipe

On Tue, Nov 27, 2012 at 11:15 PM, Zhenhua Luo <b19537@...>
wrote:
From: Yashpal Dutta <yashpal.dutta@...>

This is a /dev/crypto device driver, equivalent to those in OpenBSD
or
FreeBSD.
The main idea is to access of existing ciphers in kernel space from
userspace, thus enabling re-use of a hardware implementation of a
cipher.

Signed-off-by: Yashpal Dutta <yashpal.dutta@...>
Signed-off-by: Zhenhua Luo <b19537@...>
Should this work on master and danny as well?

-M


Re: [meta-fsl-ppc denzil] cryptodev kernel module recipe

McClintock Matthew-B29882 <B29882@...>
 

On Tue, Nov 27, 2012 at 11:02 PM, Dutta Yashpal-B05456
<B05456@...> wrote:
Hi Zhenhua,

I don't understand your statement on urgency. Cryptodev must be part of SDK-1.3.1 release. So,
Keeping it in meta-fsl-ppc is required till upstream completes.
Yashpal,

You are posting to an upstream list. This patch is already in the SDK.

-M


Re: [meta-fsl-ppc denzil] cryptodev kernel module recipe

Luo Zhenhua-B19537 <B19537@...>
 

I mean we need to put this package into upstream oe-core or meta-oe, this shouldn't be FSL PPC specific package.


Best Regards,

Zhenhua

-----Original Message-----
From: Dutta Yashpal-B05456
Sent: Wednesday, November 28, 2012 1:03 PM
To: Luo Zhenhua-B19537; McClintock Matthew-B29882
Cc: meta-freescale@...
Subject: RE: [meta-freescale] [meta-fsl-ppc denzil] cryptodev kernel
module recipe

Hi Zhenhua,

I don't understand your statement on urgency. Cryptodev must be part of
SDK-1.3.1 release. So, Keeping it in meta-fsl-ppc is required till
upstream completes.

Regards
Yashpal

-----Original Message-----
From: Luo Zhenhua-B19537
Sent: Wednesday, November 28, 2012 10:30 AM
To: McClintock Matthew-B29882
Cc: meta-freescale@...; Dutta Yashpal-B05456
Subject: RE: [meta-freescale] [meta-fsl-ppc denzil] cryptodev kernel
module recipe

I don't think it is urgent to apply it in danny and master now.

I'd like to see what will happen on acceptance of this patch by
upstream oe-core/meta-oe.


Best Regards,

Zhenhua

-----Original Message-----
From: McClintock Matthew-B29882
Sent: Wednesday, November 28, 2012 12:54 PM
To: Luo Zhenhua-B19537
Cc: meta-freescale@...; McClintock Matthew-B29882;
Dutta
Yashpal-B05456
Subject: Re: [meta-freescale] [meta-fsl-ppc denzil] cryptodev kernel
module recipe

On Tue, Nov 27, 2012 at 11:15 PM, Zhenhua Luo <b19537@...>
wrote:
From: Yashpal Dutta <yashpal.dutta@...>

This is a /dev/crypto device driver, equivalent to those in
OpenBSD or
FreeBSD.
The main idea is to access of existing ciphers in kernel space
from userspace, thus enabling re-use of a hardware implementation
of a
cipher.

Signed-off-by: Yashpal Dutta <yashpal.dutta@...>
Signed-off-by: Zhenhua Luo <b19537@...>
Should this work on master and danny as well?

-M

181 - 200 of 24854