[yocto] Fwd: FW: Creating BSP without using git
Hi, I need to create a local BSP layer using Yocto-bsp create command without the use of Git. yocto-bsp create mylayers qemu -s Which qemu architecture would you like to use? [default: i386] 1) i386(32-bit) 2) x86_64 (64-bit) 3) ARM (32-bit) 4) PowerPC (32-bit) 5) MIPS(32-bit) 3 Would you like to use the default (3.8) kernel? (y/n) [default: y] y Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y] n Getting branches from remote repo git:// git.yoctoproject.org/linux-yocto-3.8.git... Thanks with Regards - Dilip Kumar b The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and using or disseminating the information, and must notify the sender and delete it from their system. LT Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Provide sftp-client support in yocto
I am new to OpenEmbedded Yocto project and have a requirement to provide sftp-client support on my target board. Sftp-server bins are already packed into final image and is installed at tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/lib/openssh/sftp-server Now ,same way Do I have to install stfp client bins also or is there any other way to go about it?? Thanks Amit ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Provide sftp-client support in yocto
El 01/10/2013 9:52, Amit Tomer escribió: I am new to OpenEmbedded Yocto project and have a requirement to provide sftp-client support on my target board. Sftp-server bins are already packed into final image and is installed at tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/lib/openssh/sftp-server Now ,same way Do I have to install stfp client bins also or is there any other way to go about it?? Thanks Amit ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto I had the same problem and I posted this solution: https://lists.yoctoproject.org/pipermail/yocto/2013-September/018477.html Regards -- Diego González González Dpto. de Control Industrial HORUS HARDWARE S.A. diego.gonza...@horus.es ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Provide sftp-client support in yocto
* Amit Tomer amittome...@gmail.com [131001 09:53]: I am new to OpenEmbedded Yocto project and have a requirement to provide sftp-client support on my target board. Sftp-server bins are already packed into final image and is installed at tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/lib/openssh/ sftp-server Yes, that's correct. The server should be installable by adding openssh-sftp-server to your image. (Though, I guess you already figured this one out). Now ,same way Do I have to install stfp client bins also or is there any other way to go about it?? It's already being installed to a package named openssh-sftp. Thus, it should be enough to add openssh-sftp to your image. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to add /sys and /proc filesystems to image?
Hello, I have custom board with core-image-minimal and boot goes fine. Problem is that image has /sys and /proc directories but they are empty. I tried also core-image-sato but boot hangs on Starting udev... Is there a way to add these directories to image? Or should I bitbake other Yocto image more suitable for my board, which do not have display and console interface is OK? jv ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [psplash][PATCH] Add option to read message from file
Add an option to read the displayed message from a file.
Additionally the maximum length for the read string can be defined.
The string will then be cut after the given number of chars.
It is also possible to define a prefix which is displayed in front
of the read file content.
If no file is defined a hardcoded message (using MSG like before)
can be displayed.
For these changes the following defines were introduced:
MSG_FILE_PATH .. path to the file
MSG_FILE_MAX_LEN ... number of chars read from file
MSG_FILE_PREFIX text displayed in front of the file content
Signed-off-by: Richard Leitner richard.leit...@skidata.com
---
psplash.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/psplash.c b/psplash.c
index 09cf0d0..093a99a 100644
--- a/psplash.c
+++ b/psplash.c
@@ -23,6 +23,20 @@
#include psplash-bar-img.h
#include radeon-font.h
+/* Here you can define a message which will be displayed above the
+ * progress bar.
+ * The message can be either read from a file:
+ *Set MSG_FILE_PATH (and if needed MSG_FILE_{MAX_LEN,PREFIX})
+ *to display the first MSG_FILE_MAX_LEN characters
+ *of the first line from MSG_FILE_PATH as message.
+ *Additionally the content of MSG_FILE_PREFIX will be displayed
+ *before the read message. */
+#define MSG_FILE_PATH
+#define MSG_FILE_MAX_LEN 32
+#define MSG_FILE_PREFIX
+/* Or a fixed string can be used:
+ *If MSG_FILE is not set or not readable
+ *the content of MSG will be used as message. */
#define MSG
void
@@ -204,6 +218,8 @@ main (int argc, char** argv)
intpipe_fd, i = 0, angle = 0, ret = 0;
PSplashFB *fb;
bool disable_console_switch = FALSE;
+ FILE *fd_msg;
+ char *str_msg;
signal(SIGHUP, psplash_exit);
signal(SIGINT, psplash_exit);
@@ -287,7 +303,30 @@ main (int argc, char** argv)
psplash_draw_progress (fb, 0);
- psplash_draw_msg (fb, MSG);
+ /* Draw message from file or defined MSG */
+ fd_msg = fopen (MSG_FILE_PATH, r);
+ if (fd_msg==NULL) {
+psplash_draw_msg (fb, MSG);
+ } else {
+str_msg = (char*) malloc (
+ (MSG_FILE_MAX_LEN + strlen(MSG_FILE_PREFIX) + 1)*sizeof(char));
+if (str_msg != NULL fgets (str_msg, MSG_FILE_MAX_LEN, fd_msg)!=NULL) {
+ if (strlen (MSG_FILE_PREFIX) 0) {
+/* if MSG_FILE_PREFIX is set, prepend it to str_msg */
+memmove (str_msg + strlen(MSG_FILE_PREFIX) + 1, str_msg,
strlen(str_msg));
+strcpy (str_msg, MSG_FILE_PREFIX);
+ /* replace \0 after MSG_FILE_PREFIX with a space */
+str_msg[strlen(MSG_FILE_PREFIX)] = ' ';
+ }
+ psplash_draw_msg (fb, str_msg);
+ free (str_msg);
+} else {
+ /* MSG_FILE_PATH is empty (or malloc failed)
+ *so display MSG_FILE_PREFIX only */
+ psplash_draw_msg (fb, MSG_FILE_PREFIX);
+}
+fclose (fd_msg);
+ }
psplash_main (fb, pipe_fd, 0);
--
1.7.10.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [psplash][PATCH] Add option to read message from file
Hi everybody,
I recently sent a patch for psplash to add the ability to read the displayed
message from a file.
I'd appreciate any comments on it!
Thanks and best regards,
Richard Leitner
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On
Behalf Of Richard Leitner - SKIDATA
Sent: Tuesday, October 01, 2013 2:51 PM
To: Yocto Project Discussion ML (yocto@yoctoproject.org)
Subject: [yocto] [psplash][PATCH] Add option to read message from file
Add an option to read the displayed message from a file.
Additionally the maximum length for the read string can be defined.
The string will then be cut after the given number of chars.
It is also possible to define a prefix which is displayed in front of the
read file content.
If no file is defined a hardcoded message (using MSG like before) can be
displayed.
For these changes the following defines were introduced:
MSG_FILE_PATH .. path to the file
MSG_FILE_MAX_LEN ... number of chars read from file MSG_FILE_PREFIX text
displayed in front of the file content
Signed-off-by: Richard Leitner richard.leit...@skidata.com
---
psplash.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/psplash.c b/psplash.c
index 09cf0d0..093a99a 100644
--- a/psplash.c
+++ b/psplash.c
@@ -23,6 +23,20 @@
#include psplash-bar-img.h
#include radeon-font.h
+/* Here you can define a message which will be displayed above the
+ * progress bar.
+ * The message can be either read from a file:
+ *Set MSG_FILE_PATH (and if needed MSG_FILE_{MAX_LEN,PREFIX})
+ *to display the first MSG_FILE_MAX_LEN characters
+ *of the first line from MSG_FILE_PATH as message.
+ *Additionally the content of MSG_FILE_PREFIX will be displayed
+ *before the read message. */
+#define MSG_FILE_PATH
+#define MSG_FILE_MAX_LEN 32
+#define MSG_FILE_PREFIX
+/* Or a fixed string can be used:
+ *If MSG_FILE is not set or not readable
+ *the content of MSG will be used as message. */
#define MSG
void
@@ -204,6 +218,8 @@ main (int argc, char** argv)
intpipe_fd, i = 0, angle = 0, ret = 0;
PSplashFB *fb;
bool disable_console_switch = FALSE;
+ FILE *fd_msg;
+ char *str_msg;
signal(SIGHUP, psplash_exit);
signal(SIGINT, psplash_exit);
@@ -287,7 +303,30 @@ main (int argc, char** argv)
psplash_draw_progress (fb, 0);
- psplash_draw_msg (fb, MSG);
+ /* Draw message from file or defined MSG */
+ fd_msg = fopen (MSG_FILE_PATH, r);
+ if (fd_msg==NULL) {
+psplash_draw_msg (fb, MSG);
+ } else {
+str_msg = (char*) malloc (
+ (MSG_FILE_MAX_LEN + strlen(MSG_FILE_PREFIX) + 1)*sizeof(char));
+if (str_msg != NULL fgets (str_msg, MSG_FILE_MAX_LEN, fd_msg)!=NULL) {
+ if (strlen (MSG_FILE_PREFIX) 0) {
+/* if MSG_FILE_PREFIX is set, prepend it to str_msg */
+memmove (str_msg + strlen(MSG_FILE_PREFIX) + 1, str_msg,
strlen(str_msg));
+strcpy (str_msg, MSG_FILE_PREFIX);
+ /* replace \0 after MSG_FILE_PREFIX with a space */
+str_msg[strlen(MSG_FILE_PREFIX)] = ' ';
+ }
+ psplash_draw_msg (fb, str_msg);
+ free (str_msg);
+} else {
+ /* MSG_FILE_PATH is empty (or malloc failed)
+*so display MSG_FILE_PREFIX only */
+ psplash_draw_msg (fb, MSG_FILE_PREFIX);
+}
+fclose (fd_msg);
+ }
psplash_main (fb, pipe_fd, 0);
--
1.7.10.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fwd: FW: Creating BSP without using git
On Tue, 2013-10-01 at 11:48 +0530, Dilip Kumar wrote: Hi, I need to create a local BSP layer using Yocto-bsp create command without the use of Git. yocto-bsp create mylayers qemu -s Which qemu architecture would you like to use? [default: i386] 1) i386(32-bit) 2) x86_64 (64-bit) 3) ARM (32-bit) 4) PowerPC (32-bit) 5) MIPS(32-bit) 3 Would you like to use the default (3.8) kernel? (y/n) [default: y] y Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y] n Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.8.git... You can use the -i param with JSON to feed it the answers you want to give it, and then it won't try to generate and display a branch list, etc. From the help: yocto-bsp create bsp-name karch [-o DIRNAME | --outdir DIRNAME] [-i JSON PROPERTY FILE | --infile JSON PROPERTY_FILE] The BSP-specific properties that define the values that will be used to generate a particular BSP can be specified on the command-line using the -i option and supplying a JSON object consisting of the set of name:value pairs needed by the BSP. If the -i option is not used, the user will be interactively prompted for each of the required property values, which will then be used as values for BSP generation. The set of properties available for a given architecture can be listed using the 'yocto-bsp list' command. Thanks with Regards - Dilip Kumar b The contents of this e-mail and any attachment(s) may contain confidential or privileged information for the intended recipient(s). Unintended recipients are prohibited from taking action on the basis of information in this e-mail and using or disseminating the information, and must notify the sender and delete it from their system. LT Infotech will not accept responsibility or liability for the accuracy or completeness of, or the presence of any virus or disabling code in this e-mail ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problem finding -lgcc when using SDK toolchain
Hello. We have stumbled into a problem when using ld directly instead
of going through the gcc frontend.
A simple operation like this fails:
${CC} -c hello_world.c
${LD} hello_world.o -lgcc
arm-poky-linux-gnueabi-ld: cannot find -lgcc
And yes, I know -lgcc is not required in this case to compile this
one, but this is only a simple reproducer.
The real issue was discovered when trying to build U-Boot from the SDK.
To resolve this problem we are forced to provide
-Lsysroot/usr/lib/arm-poky-linux-gnueabi/4.7.2 to LDFLAGS.
But that should not be needed, should it? Anyone else bumped into this
problem? Are there any real solutions.
I am starting to think it has to do with the hardcoded installation
path in the binaries maybe? If you choose not to install
the SDK where Yocto assumes it to be installed things break, even if
--sysroot is used.
Thanks.
Hans
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Provide sftp-client support in yocto
Amit Tomer amittome...@gmail.com wrote: Thansk Anders for your kind response Yes we are created our image and can see there are some IMAGE_INSTALL already used Good. But when I add IMAGE_INSTALL += openssh-sftp Getting below error Error: openssh-sftp not found in the base feeds (fzm_lsp_k2 cortexa15hf-vfp-neon cortexa15hf-vfp armv7ahf-vfp-neon armv7ahf-vfp armv6hf-vfp armv5ehf-vfp armv5hf-vfp noarch any all). Do we need to do something more here That should have been enough. If you look in tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/packages-split, do you see openssh-sftp there, or which packages do you have there? Which version of Yocto / Poky are you using? What layers do you have enabled? Cheers, Anders Thanks Amit On Tue, Oct 1, 2013 at 6:56 PM, Anders Darander and...@chargestorm.se wrote: * Amit Tomer amittome...@gmail.com [131001 14:57]: Just now I have seen your responses ,didn't get any notification of your responses on my mail-id. Let me present my problem again to you guys. We have stfp-server running fine on put target machine and is running as part of sshd daemon. Ok, that sounds good. Then the server is apparantly no problem for you. But when we try to connect to other machine from target board, sftp is not working becaue our borad is set to run as sftp -client. An SFTP client program called sftp is already insatlled to tmp/work/ fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/bin. The build process built sftp (the client) as a part of building openssh. The client was packaged into a separate package, called openssh-sftp. But on Target I could not find this sftp .bins. Now you need to install that package, openssh-sftp, to your image. If you have created your own image, just add openssh-sftp to IMAGE_INSTALL. If you're not creating your own images, I'd strongly suggest that you do that. (It'll make all your customizations a lot easier in the end). See http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage-custombb for more information. I hope this answers your question. Cheers, Anders Now we want this stfp run as some daemon or part of sshd daemon itself. Anders: It's already being installed to a package named openssh-sftp We don't have package named openssh-sftp ,we have package named with openssh only Thanks Amit On Tue, Oct 1, 2013 at 1:22 PM, Amit Tomer amittome...@gmail.com wrote: I am new to OpenEmbedded Yocto project and have a requirement to provide sftp-client support on my target board. Sftp-server bins are already packed into final image and is installed at tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/lib/openssh/ sftp-server Now ,same way Do I have to install stfp client bins also or is there any other way to go about it?? Thanks Amit -- Anders Darander ChargeStorm AB / eStorm AB -- Anders Darander ChargeStorm AB Tel: +46 702 44 84 36 Laxholmstorget 3 Email: and...@chargestorm.se 602 21 Norrköping Web: www.chargestorm.se Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel access of bad area in kernel module
Hi,
I want to set/reset GPIO registers in freescale p1022 processor. I saw a
hello-mod kernel module in yocto and I added it to my image and it worked.
According to hello-mod kernel module, I created GPIO module like hello-mod.
But it GPIO module failed when I run it in kernel level. I checked several
times addresses of registers and it seems accurate.
My code is here :
#include linux/module.h
int init_module(void)
{
volatile uint32_t * Guts_Pmuxcr;
volatile uint32_t * Gpio3_Gpdir;
volatile uint32_t * Gpio3_Gpdat;
// e500 Core View To Power Architecture CCSR: 0x0_FF70_
// GUTS_PMUXCR:Alternate Function Signal Multiplex Control Register
Guts_Pmuxcr = (volatile uint32_t *)(0xFF7E0060);
// GPIO3_GPDIR: GPIO3 direction register
Gpio3_Gpdir = (volatile uint32_t *)(0xFF70F200);
// GPIO3_GPDAT: GPIO3 data register
Gpio3_Gpdat = (volatile uint32_t *)(0xFF70F208);
// Enable GPIO3[10]: IRQ_DEBUG1_GPIO FIELD [BIT 26] set to 1
*(Guts_Pmuxcr) = 0x0010;
// Set Direction for GPIO3[10] to Output: FIELD DR10 [BIT 10] set to '1'
*(Gpio3_Gpdir) = 0x0020;
// Set GPIO3[10] to '0': FIELD D10 [BIT 10] set to '0'
*(Gpio3_Gpdat) = 0x;
printk(Hello World!\n);
return 0;
}
void cleanup_module(void)
{
printk(Goodbye Cruel World!\n);
}
MODULE_LICENSE(GPL);
When I write insmod GPIO.ko in the terminal I get error these errors:
Unable to handle kernel paging request for data at address 0xff7e0060
faulting instruction address: 0xf107e05c
Oops: Kernel access of bad area, sig: 11 [#1]
..
.
How can I solve this problem?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Provide sftp-client support in yocto
Amit Tomer amittome...@gmail.com wrote: Yes Anders, I can see openssh-sftp folder inside tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/packages-split.But its empty one. Ok, then the sftp binary should have been packaged into openssh-sftp. The question is then why your package is being empty. You said that the sftp binary was available in tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/bin, cab you so find out there? Do you get any clue from the packaging log as to why openssh-sftp is empty? If you run 'bitbake openssh -e' and search for FILES_openssh-sftp, what does it tell you? In which directory under packages-split can you find sftp? DISTRO= poky DISTRO_VERSION= 1.4.2 It should work. Unless there something that overrides the packaging (and splitting) step in any other layer you might have configured. I won't be able to run any tests on my own until early next week. If necessary, I hope that someone else might be able to help you until then. Cheers, Anders This is taken from build confriguation. Thanks Amit. On Tue, Oct 1, 2013 at 7:37 PM, Anders Darander and...@chargestorm.se wrote: Amit Tomer amittome...@gmail.com wrote: Thansk Anders for your kind response Yes we are created our image and can see there are some IMAGE_INSTALL already used Good. But when I add IMAGE_INSTALL += openssh-sftp Getting below error Error: openssh-sftp not found in the base feeds (fzm_lsp_k2 cortexa15hf-vfp-neon cortexa15hf-vfp armv7ahf-vfp-neon armv7ahf-vfp armv6hf-vfp armv5ehf-vfp armv5hf-vfp noarch any all). Do we need to do something more here That should have been enough. If you look in tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/packages-split, do you see openssh-sftp there, or which packages do you have there? Which version of Yocto / Poky are you using? What layers do you have enabled? Cheers, Anders Thanks Amit On Tue, Oct 1, 2013 at 6:56 PM, Anders Darander and...@chargestorm.se wrote: * Amit Tomer amittome...@gmail.com [131001 14:57]: Just now I have seen your responses ,didn't get any notification of your responses on my mail-id. Let me present my problem again to you guys. We have stfp-server running fine on put target machine and is running as part of sshd daemon. Ok, that sounds good. Then the server is apparantly no problem for you. But when we try to connect to other machine from target board, sftp is not working becaue our borad is set to run as sftp -client. An SFTP client program called sftp is already insatlled to tmp/work/ fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/bin. The build process built sftp (the client) as a part of building openssh. The client was packaged into a separate package, called openssh-sftp. But on Target I could not find this sftp .bins. Now you need to install that package, openssh-sftp, to your image. If you have created your own image, just add openssh-sftp to IMAGE_INSTALL. If you're not creating your own images, I'd strongly suggest that you do that. (It'll make all your customizations a lot easier in the end). See http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-customimage-custombb for more information. I hope this answers your question. Cheers, Anders Now we want this stfp run as some daemon or part of sshd daemon itself. Anders: It's already being installed to a package named openssh-sftp We don't have package named openssh-sftp ,we have package named with openssh only Thanks Amit On Tue, Oct 1, 2013 at 1:22 PM, Amit Tomer amittome...@gmail.com wrote: I am new to OpenEmbedded Yocto project and have a requirement to provide sftp-client support on my target board. Sftp-server bins are already packed into final image and is installed at tmp/work/fkm-poky-linux-gnueabi/openssh/6.1p1-r3/package/usr/lib/openssh/ sftp-server Now ,same way Do I have to install stfp client bins also or is there any other way to go about it?? Thanks Amit -- Anders Darander ChargeStorm AB / eStorm AB -- Anders Darander ChargeStorm AB Tel: +46 702 44 84 36 Laxholmstorget 3Email: and...@chargestorm.se 602 21 Norrköping Web: www.chargestorm.se Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Anders Darander ChargeStorm AB Tel: +46 702 44 84 36 Laxholmstorget 3 Email: and...@chargestorm.se 602 21 Norrköping Web: www.chargestorm.se Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel access of bad area in kernel module
Jack jackrubby2...@gmail.com wrote:
Hi,
I want to set/reset GPIO registers in freescale p1022 processor. I saw
a
hello-mod kernel module in yocto and I added it to my image and it
worked.
According to hello-mod kernel module, I created GPIO module like
hello-mod.
But it GPIO module failed when I run it in kernel level. I checked
several
times addresses of registers and it seems accurate.
My code is here :
#include linux/module.h
int init_module(void)
{
volatile uint32_t * Guts_Pmuxcr;
volatile uint32_t * Gpio3_Gpdir;
volatile uint32_t * Gpio3_Gpdat;
// e500 Core View To Power Architecture CCSR: 0x0_FF70_
// GUTS_PMUXCR:Alternate Function Signal Multiplex Control Register
Guts_Pmuxcr = (volatile uint32_t *)(0xFF7E0060);
// GPIO3_GPDIR: GPIO3 direction register
Gpio3_Gpdir = (volatile uint32_t *)(0xFF70F200);
// GPIO3_GPDAT: GPIO3 data register
Gpio3_Gpdat = (volatile uint32_t *)(0xFF70F208);
You should generally a of trying to dereference physical addresses, or you
should explicitly declare them as such.
If suggest looking for some info on using GPIO on your CPU. Unfortunately, I've
not used the p1022, so I can't really help you.
http://linuxppc.10917.n7.nabble.com/Re-GPIO-IRQ-on-P1022-td59356.html discusses
some IRQ issues, though you should be able to use the codes as an example of
the GPIO framework and how to use it.
Cheers,
Anders
// Enable GPIO3[10]: IRQ_DEBUG1_GPIO FIELD [BIT 26] set to 1
*(Guts_Pmuxcr) = 0x0010;
// Set Direction for GPIO3[10] to Output: FIELD DR10 [BIT 10] set to
'1'
*(Gpio3_Gpdir) = 0x0020;
// Set GPIO3[10] to '0': FIELD D10 [BIT 10] set to '0'
*(Gpio3_Gpdat) = 0x;
printk(Hello World!\n);
return 0;
}
void cleanup_module(void)
{
printk(Goodbye Cruel World!\n);
}
MODULE_LICENSE(GPL);
When I write insmod GPIO.ko in the terminal I get error these errors:
Unable to handle kernel paging request for data at address 0xff7e0060
faulting instruction address: 0xf107e05c
Oops: Kernel access of bad area, sig: 11 [#1]
..
.
How can I solve this problem?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Anders Darander
ChargeStorm AB Tel: +46 702 44 84 36
Laxholmstorget 3 Email: and...@chargestorm.se
602 21 Norrköping Web: www.chargestorm.se
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] nativesdk-dbus not shipped for meta-toolchain-qt
Hello We are trying to bitbake meta-toolchain-qt with master and dora. Both launch this error: ERROR: QA Issue: nativesdk-dbus: Files/directories were installed but not shipped /run /run/dbus ERROR: QA run found fatal errors. Please consider fixing them. We compare it to dylan dbus. We found that dora is creating a package-split named nativesdk-dbus with the symbolink link run at build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-dbus/1.6.10-r6.0/packages-split/nativesdk-dbus/opt/poky/1.5/sysroots/i686-pokysdk-linux/var. That link is pointing to /run host directory (a bad thing, we suppose). That link in dylan is pointing to volatile/run (a folder inside the package-split) We try to manually delete the link and recreate it and the folders, but bitbake clean everything and it create again. Any clue about how to solve this? Thank you ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] [eclipse-poky-kepler] sdk.remotetools: use xterm for latencytop
Use xterm instead of vt100 in order to avoid having
unreadable output for latencytop due to some control characters.
Signed-off-by: Tudor Florea tudor.flo...@enea.com
---
.../src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
index e931388..1ef34cb 100644
---
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
+++
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/actions/LatencytopHandler.java
@@ -13,7 +13,7 @@ package org.yocto.sdk.remotetools.actions;
public class LatencytopHandler extends DialogHandler {
- private static String initCmd=export
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin; cd; sudo latencytop\r;
+ private static String initCmd=export TERM=xterm; export
PATH=$PATH:/usr/local/sbin:/usr/sbin:/sbin; cd; sudo latencytop\r;
@Override
protected String getInitCmd() {
--
1.7.10.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Can I extend split_and_strip_files() in packages.bbclass with Erlang beam support ?
Ok, so now I am at it again :) The package.bbclass is missing support for stripping .beam files. Nothing strange about that. But, now I wish to extend this class with support for erlang .beam files. Initially I do not wish to add this functionality directly into package.bbclass since it will require an erlang execution environment + an erlang escript to run. I do not know if we want that ;) Is it possible to extend the split_and_strip_files() function in some other way using eg the _append postfix? Since this function is a real a beast (with good reason), copying it and making it a strict beam detector (instead of elf) might not be the most attractive solution though :( I assume I need to sneak in the beam stripping in the middle of the processing somewhere since once split_and_strip_files() is completed, actual packaging will commence, and after that it will be too late. Any ideas? Might patching package.bbclass be an alternative? In that case, how to avoid dragging in an erlang-native dependency into package.bbclass if it is not needed? (also considering erlang is not yet officially supported by Yocto/OE-core). Thanks. Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] meta-yocto: Removed obsolete distros from SANITY_TESTED_DISTROS in poky.conf
Removed CentOS-6.3, Fedora-17, Debian-6.0 and Poky-1.3 from SANITY_TESTED_DISTROS. Signed-off-by: Alexandru Palalau alexandrux.pala...@intel.com --- meta-yocto/conf/distro/poky.conf | 4 1 file changed, 4 deletions(-) diff --git a/meta-yocto/conf/distro/poky.conf b/meta-yocto/conf/distro/poky.conf index 4752356..465dbb9 100644 --- a/meta-yocto/conf/distro/poky.conf +++ b/meta-yocto/conf/distro/poky.conf @@ -72,18 +72,14 @@ CONNECTIVITY_CHECK_URIS ?= \ http://bugzilla.yoctoproject.org/report.cgi; SANITY_TESTED_DISTROS ?= \ -Poky-1.3 \n \ Poky-1.4 \n \ Poky-1.5 \n \ Ubuntu-12.04 \n \ Ubuntu-12.10 \n \ Ubuntu-13.04 \n \ -Fedora-17 \n \ Fedora-18 \n \ Fedora-19 \n \ -CentOS-6.3 \n \ CentOS-6.4 \n \ -Debian-6.0 \n \ Debian-6.0.7 \n \ Debian-7.0 \n \ Debian-7.1 \n \ -- 1.8.1.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem finding -lgcc when using SDK toolchain
On Oct 1, 2013, at 6:16 AM, Hans Beckérus hans.becke...@gmail.com wrote:
Hello. We have stumbled into a problem when using ld directly instead
of going through the gcc frontend.
A simple operation like this fails:
${CC} -c hello_world.c
${LD} hello_world.o -lgcc
arm-poky-linux-gnueabi-ld: cannot find -lgcc
And yes, I know -lgcc is not required in this case to compile this
one, but this is only a simple reproducer.
The real issue was discovered when trying to build U-Boot from the SDK.
To resolve this problem we are forced to provide
-Lsysroot/usr/lib/arm-poky-linux-gnueabi/4.7.2 to LDFLAGS.
But that should not be needed, should it? Anyone else bumped into this
problem? Are there any real solutions.
I am starting to think it has to do with the hardcoded installation
path in the binaries maybe?
I doubt that infact we try hard to keep it relocatable. The problem is you are
interpreting
--sysroot option to do more than what its supposed to do. when linking it only
affects INPUT, GROUP
and SEARCH_DIR linker script variables and if you look at the linker script
path to libgcc is not
specified in SEARCH_DIR, thats where gcc driver comes handy in figuring out
where the right libgcc is installed
and sometimes when you have complex multilib environments thats very handy.
linker does not know
anything about libgcc its just another library for it.
however you could do something like
${CC} -print-libgcc-file-name or ${CC} -print-file-name=libgcc.a
to get to the library
and specify that in your linker cmdline
-Khem
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem finding -lgcc when using SDK toolchain
On 2013-10-01 7:35, Khem Raj wrote:
On Oct 1, 2013, at 6:16 AM, Hans Beckérus hans.becke...@gmail.com wrote:
Hello. We have stumbled into a problem when using ld directly instead
of going through the gcc frontend.
A simple operation like this fails:
${CC} -c hello_world.c
${LD} hello_world.o -lgcc
arm-poky-linux-gnueabi-ld: cannot find -lgcc
And yes, I know -lgcc is not required in this case to compile this
one, but this is only a simple reproducer.
The real issue was discovered when trying to build U-Boot from the SDK.
To resolve this problem we are forced to provide
-Lsysroot/usr/lib/arm-poky-linux-gnueabi/4.7.2 to LDFLAGS.
But that should not be needed, should it? Anyone else bumped into this
problem? Are there any real solutions.
I am starting to think it has to do with the hardcoded installation
path in the binaries maybe?
I doubt that infact we try hard to keep it relocatable. The problem is you
are interpreting
--sysroot option to do more than what its supposed to do. when linking it
only affects INPUT, GROUP
and SEARCH_DIR linker script variables and if you look at the linker script
path to libgcc is not
specified in SEARCH_DIR, thats where gcc driver comes handy in figuring out
where the right libgcc is installed
and sometimes when you have complex multilib environments thats very handy.
linker does not know
anything about libgcc its just another library for it.
Hi Khem, thanks for your time. I am sure I put too much value into --sysroot,
but what still strikes me a bit odd is why the simple reproducer I showed
before works just fine using the local host gcc and ld? It seems to have no
issues in finding libgcc.a?
So what you are saying is that it is actually expected that U-Boot build will
fail when compiled through the SDK toolchain directly without adding additional
options to the linker? Is that also what the u-boot recipe is doing? After all,
it works fine to bitbake u-boot.
however you could do something like
${CC} -print-libgcc-file-name or ${CC} -print-file-name=libgcc.a
to get to the library
and specify that in your linker cmdline
Ok, guess it will simply give me the same path as we are currently hardcoding,
but if the toolchain moves your solution is definitely to prefer.
Thanks for the tip. Did only not know about the --print-sysroot command until
now.
-Khem
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, October 01, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US Canada).
Attendees: Mark, Michael, Cristian, Darren, Corneliu, Paul, Tom, JeffP, Jessica, ScottR, Saul, Nitin, Beth, AlexG, Ross, Song Agenda: * Opens collection - 5 min (Song) * Yocto 1.5 status - 10 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status - Bug fixing: Thanks to the team, we resolved 59 bugs in the past week. WDD number is down significantly. Great work. Let's keep it up to bring the WDD number down further. - QA: Full pass QA report on the last RC is out on the public mailing list. There are some meta-intel BSP problems. Nitin already have a fix, no impact to oe-core. - Build: doing RC build today, QA will do targeted testing for feature verification, Jason's patches for supporting iso EFI images might need more testing too. - RP may not be available. But waiting for him to pull in more patches before the RC build. - Partitioning: all patches are sent, cleanup work is done. Waiting for Richard to pull the patches. * SWAT team rotation: Saul * Opens - 10 min * Team Sharing - 20 min - Christian: mainly bug fixing for the moment, working on DNS issue, etc. - MichaelH: commercial data center is coming online. Very short downtime. Will have much faster connection. Nothing will happen today. Will be sometime this week. In plan. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ${libdir} usage
Hi,
I'm currently putting together a bunch of recipes to install some cpan
modules. I had some complaints by bitbake about files being installed
but not shipped.
I figured that I need to populate FILES_{PN} but I'm not clear about
what I should do with it: use ${libdir}, use usr/* ? Knowing that my
image(s) directories mostly contain usr/lib/perl/* and sometimes usr/bin/*
What's the best practice ? That'll save me some time when I send the
patch :)
Thanks for your help
Jay
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH 1/1] standard.cfg: add an entry for CONFIG_INPUT_EVDEV
From: Nitin A Kamble nitin.a.kam...@intel.com The evdev kernel driver is needed to create /dev/input/event* devices. These devices are used by Xserver to connect to keyboard mouse kind of input devices. Without this change some of the BSPs need AutoAddDevices = false in their xorg.conf, which is considered as an undesired hack around the issue. Fixes Bug: [YOCTO #5279] Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta/cfg/kernel-cache/ktypes/standard/standard.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/cfg/kernel-cache/ktypes/standard/standard.cfg b/meta/cfg/kernel-cache/ktypes/standard/standard.cfg index a67adb5..b1dfc0c 100644 --- a/meta/cfg/kernel-cache/ktypes/standard/standard.cfg +++ b/meta/cfg/kernel-cache/ktypes/standard/standard.cfg @@ -536,6 +536,7 @@ CONFIG_SLIP_MODE_SLIP6=y # # Userland interfaces # +CONFIG_INPUT_EVDEV=y # # Input Device Drivers -- 1.8.1.4 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 0/1] commit for v3.10 linux-yocto repo, meta branch
From: Nitin A Kamble nitin.a.kam...@intel.com This adds a missing evdev kernel driver support in the standard.cfg of the v3.10 kernel. Thanks, Nitin The following changes since commit dad2b7e1ceed654fba89907f3e14050007699b90: common-pc-64: add kernel CONFIG options for sugarbay platform (2013-09-25 15:21:06 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib nitin/3.10-meta http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=nitin/3.10-meta Nitin A Kamble (1): standard.cfg: add an entry for CONFIG_INPUT_EVDEV meta/cfg/kernel-cache/ktypes/standard/standard.cfg | 1 + 1 file changed, 1 insertion(+) -- 1.8.1.4 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 1/1] standard.cfg: add an entry for CONFIG_INPUT_EVDEV
From: Nitin A Kamble nitin.a.kam...@intel.com The evdev kernel driver is needed to create /dev/input/event* devices. These devices are used by Xserver to connect to keyboard mouse kind of input devices. Without this change some of the BSPs need AutoAddDevices = false in their xorg.conf, which is considered as an undesired hack around the issue. Fixes Bug: [YOCTO #5279] Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com --- meta/cfg/kernel-cache/ktypes/standard/standard.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/cfg/kernel-cache/ktypes/standard/standard.cfg b/meta/cfg/kernel-cache/ktypes/standard/standard.cfg index 8cb4b6b..3dcb718 100644 --- a/meta/cfg/kernel-cache/ktypes/standard/standard.cfg +++ b/meta/cfg/kernel-cache/ktypes/standard/standard.cfg @@ -537,6 +537,7 @@ CONFIG_SLIP_MODE_SLIP6=y # # Userland interfaces # +CONFIG_INPUT_EVDEV=y # # Input Device Drivers -- 1.8.1.4 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
