[yocto] kernel source code
I have run below command bitbake -c fetchall core-image-minimal It has created downloads directory and packages source codes are there inside, but i am not able to find the kernel and u-boot source code. I have build core-image-minimal without internet connectivity, and kernel and u-boot have also built properly. I am not getting from where it is taking the source code for kernel and u-boot. I am building yocto sdk for imx6l evolution kit and i have checked out daisy branch. Please suggest where can be the source code for kernel and u-boot before build but after running fetchall command. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QEMU in SDK
Good day ALL, I was wondering if it's possible to automatically add QEMU dependencies (kernel and ext3 files) into the script generated by do_populate_sdk? Then after running the generated SDK script, the images will reside in /path/to/sysroots/xxx-poky-xxx/tmp/images? Then just add an environment variable to the environment script to locate the images path. Is this possible? The intention is to run QEMU in a host machine with extracted SDK. Any suggestions on other better ways to run QEMU in another machine w/ SDK would be great. Thanks, Joseph -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QEMU in SDK
Hi Joseph, Maybe you can use adt-installer. http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#using-the-adt-installer Best Regards Chong On 07/08/2014 02:15 PM, Joseph Andrew de la Peña wrote: Good day ALL, I was wondering if it's possible to automatically add QEMU dependencies (kernel and ext3 files) into the script generated by do_populate_sdk? Then after running the generated SDK script, the images will reside in /path/to/sysroots/xxx-poky-xxx/tmp/images? Then just add an environment variable to the environment script to locate the images path. Is this possible? The intention is to run QEMU in a host machine with extracted SDK. Any suggestions on other better ways to run QEMU in another machine w/ SDK would be great. Thanks, Joseph -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel source code
On 07/08/2014 02:04 PM, jags gediya wrote: I have run below command bitbake -c fetchall core-image-minimal It has created downloads directory and packages source codes are there inside, but i am not able to find the kernel and u-boot source code. By default, the kernel-source code is: builddir/downloads/git2/git.yoctoproject.org.linux-yocto-3.14.git And the u-boot is: builddir/downloads/git2/git.denx.de.u-boot.git You can check the SRC_URI in the recipe to figure out the source type, they will be in DL_DIR if tarball, and DL_DIR/git2 if git, the similar to svn (DL_DIR/svn) and others. Usually, the bitbake -e recipe recipe.py then look at recipe.py helps. // Robert I have build core-image-minimal without internet connectivity, and kernel and u-boot have also built properly. I am not getting from where it is taking the source code for kernel and u-boot. I am building yocto sdk for imx6l evolution kit and i have checked out daisy branch. Please suggest where can be the source code for kernel and u-boot before build but after running fetchall command. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QEMU in SDK
Good day Chong, Actually, I have used ADT (Section 3.4 Optionally Building a Toolchain Installer). I used the method -c populate_sdk and it generated a toolchain script from my existing build workdir's core-image-XXX. I ran the toolchain and it generated a sysroots dir to /path/to/sysroots (SDK_PATH). Here's the directory structure: + SDK_PATH --- + environment-setup-XXX --- + site-config-XXX --- + sysroots (dir) -- + XXX-poky-linux (dir) -- + XXX-pokysdk-linux (dir) --- + version-XXX The poky-linux dir does not contain a build dir and nowhere are the images (kernel and ext3) to be found. Thus, the main problem is how can I ran qemu with my SDK setup. This would lead to my sub question: since QEMU needs the kernel and ext3 files, how can I automatically copy these images from my existing build workdir to the newly created SDK dir. Thanks, Joseph On Tue, Jul 8, 2014 at 3:26 PM, Chong Lu chong...@windriver.com wrote: Hi Joseph, Maybe you can use adt-installer. http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#using-the-adt-installer Best Regards Chong On 07/08/2014 02:15 PM, Joseph Andrew de la Peña wrote: Good day ALL, I was wondering if it's possible to automatically add QEMU dependencies (kernel and ext3 files) into the script generated by do_populate_sdk? Then after running the generated SDK script, the images will reside in /path/to/sysroots/xxx-poky-xxx/tmp/images? Then just add an environment variable to the environment script to locate the images path. Is this possible? The intention is to run QEMU in a host machine with extracted SDK. Any suggestions on other better ways to run QEMU in another machine w/ SDK would be great. Thanks, Joseph -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QEMU in SDK
I mean you can use adt-installer to make your sdk environment. (3.1.1. Using the ADT Installer) After you run adt-installer script, you can get kernel and rootfs in download_image directory. Best Regards Chong On 07/08/2014 05:39 PM, Joseph Andrew de la Peña wrote: Good day Chong, Actually, I have used ADT (Section 3.4 Optionally Building a Toolchain Installer). I used the method -c populate_sdk and it generated a toolchain script from my existing build workdir's core-image-XXX. I ran the toolchain and it generated a sysroots dir to /path/to/sysroots (SDK_PATH). Here's the directory structure: + SDK_PATH --- + environment-setup-XXX --- + site-config-XXX --- + sysroots (dir) -- + XXX-poky-linux (dir) -- + XXX-pokysdk-linux (dir) --- + version-XXX The poky-linux dir does not contain a build dir and nowhere are the images (kernel and ext3) to be found. Thus, the main problem is how can I ran qemu with my SDK setup. This would lead to my sub question: since QEMU needs the kernel and ext3 files, how can I automatically copy these images from my existing build workdir to the newly created SDK dir. Thanks, Joseph On Tue, Jul 8, 2014 at 3:26 PM, Chong Lu chong...@windriver.com mailto:chong...@windriver.com wrote: Hi Joseph, Maybe you can use adt-installer. http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#using-the-adt-installer Best Regards Chong On 07/08/2014 02:15 PM, Joseph Andrew de la Peña wrote: Good day ALL, I was wondering if it's possible to automatically add QEMU dependencies (kernel and ext3 files) into the script generated by do_populate_sdk? Then after running the generated SDK script, the images will reside in /path/to/sysroots/xxx-poky-xxx/tmp/images? Then just add an environment variable to the environment script to locate the images path. Is this possible? The intention is to run QEMU in a host machine with extracted SDK. Any suggestions on other better ways to run QEMU in another machine w/ SDK would be great. Thanks, Joseph -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] GDB related issue on host machine
Hi, I am new to this forum. I am facing some difficulties in debugging a.out on host os(without target connection). Using powerpc-poky-linux-gdb a.out. Once entered to gdb did below steps set sysroot /home/../ppc/sysroots/ppc7400-poky-linux file a.out b main continue shows message The program is not being run. If I execute run gives The program is not being run. Any help is appreciated. :) Thanks. This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Aarch64 support
Hi Maxin, Thanks for your suggestion for the same. But that git repository for meta-aarch64 is not working. Thanks and regards Atul On 8 Jul 2014 01:25, Maxin B. John maxin.j...@enea.com wrote: Hi Atul, On Tue, Jul 08, 2014 at 12:41:22AM +0530, atulkumar singh wrote: Hi All, Is there support for Aarch64(64 bit ARMv8) available right now? Yes. Aarch64 support is available in meta-linaro/meta-aarch64 URL: http://git.linaro.org/?p=openembedded/meta-linaro.git If so then what i need to mention as a MACHINE in local.conf. You can choose between: 1. genericarmv8b - generic armv8 big endian machine 2. genericarmv8 - generic armv8 machine Please let me know with your valuable suggestion if any. Please use http://layers.openembedded.org/ to search Machine/Layers/Recipes supported by OpenEmbedded. Thanks and regards, Atul Best Regards, Maxin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Aarch64 support
Hi Atul, On Tue, Jul 08, 2014 at 03:57:44PM +0530, atulkumar singh wrote: Hi Maxin, Thanks for your suggestion for the same. But that git repository for meta-aarch64 is not working. It works for me .. # git clone git://git.linaro.org/openembedded/meta-linaro.git Thanks and regards Atul Best Regards, Maxin On 8 Jul 2014 01:25, Maxin B. John maxin.j...@enea.com wrote: Hi Atul, On Tue, Jul 08, 2014 at 12:41:22AM +0530, atulkumar singh wrote: Hi All, Is there support for Aarch64(64 bit ARMv8) available right now? Yes. Aarch64 support is available in meta-linaro/meta-aarch64 URL: http://git.linaro.org/?p=openembedded/meta-linaro.git If so then what i need to mention as a MACHINE in local.conf. You can choose between: 1. genericarmv8b - generic armv8 big endian machine 2. genericarmv8 - generic armv8 machine Please let me know with your valuable suggestion if any. Please use http://layers.openembedded.org/ to search Machine/Layers/Recipes supported by OpenEmbedded. Thanks and regards, Atul Best Regards, Maxin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] some wiki pages on building your very first poky/yocto project
not sure if others will find this useful but i'm teaching an oe/poky/yocto course in a couple weeks, and i decided to slap together some publicly-readable wiki pages that i plan on sending ahead of time to upcoming students to walk them through setting up their development host, and downloading, and finally building their very first project, the purpose being so that when i show up that first morning, everyone has a build host ready to go and we don't have to waste any time downloading packages and layers and so on. everything falls off of this new top-level wiki page of mine: http://www.crashcourse.ca/wiki/index.php/Poky and the plan is for impending students to read and work through the sections: * Setting up your build host * Doing your first build there's lots more coming, but those first two sections should act as pre-class preparation. i'm still adding stuff to them, but if anyone has any thoughts on what else to put there, feel free. it's all very ad hoc, but i really want to avoid wasted time the first morning of the course screwing around with build hosts. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Aarch64 support
On 8 July 2014 13:27, atulkumar singh atul.singh...@gmail.com wrote: Hi Maxin, Thanks for your suggestion for the same. But that git repository for meta-aarch64 is not working. What do you mean by not working. We produce daily builds and they're tested. Thanks and regards Atul On 8 Jul 2014 01:25, Maxin B. John maxin.j...@enea.com wrote: Hi Atul, On Tue, Jul 08, 2014 at 12:41:22AM +0530, atulkumar singh wrote: Hi All, Is there support for Aarch64(64 bit ARMv8) available right now? Yes. Aarch64 support is available in meta-linaro/meta-aarch64 URL: http://git.linaro.org/?p=openembedded/meta-linaro.git If so then what i need to mention as a MACHINE in local.conf. You can choose between: 1. genericarmv8b - generic armv8 big endian machine 2. genericarmv8 - generic armv8 machine Please let me know with your valuable suggestion if any. Please use http://layers.openembedded.org/ to search Machine/Layers/Recipes supported by OpenEmbedded. Thanks and regards, Atul Best Regards, Maxin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Cheers, -- Fathi Boudra Linaro.org | Open source software for ARM SoCs -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, July 8, 2014 8:00 AM US Pacific Time
Agenda: * Opens collection - 5 min (Stephen) * Yocto 1.7 status - 5 min (Stephen/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.7_Status https://wiki.yoctoproject.org/wiki/Yocto_1.7_Schedule https://wiki.yoctoproject.org/wiki/Yocto_1.7_Features * SWAT team rotation: Ross - Cristian https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team * Opens - 10 min * Team Sharing - 10 min We encourage people attending the meeting to logon the Yocto Project IRC chancel during the meeting (optional): Yocto IRC: http://webchat.freenode.net/?channels=#yocto IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html Conference Details: Company: WIND RIVER SYS Ready-Access Number: 8007302996/9139049836 Access Code: 2705751 For International numbers see: https://www.yoctoproject.org/tools-resources/community/weekly-technical-call Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Aarch64 support
Hi Fathi and Maxin, Thanks as you are helping me in sorting out my issue for Aarch64 support in meta-toolchain while building bitbake for yocto. And not working means if we go into the machine/layer/recipes link and under the meta-aarch64 layer the git repository link which is mention is not working. Please let me know with your valuable suggestion. Thanks and regards, Atul On 8 Jul 2014 18:14, Fathi Boudra fathi.bou...@linaro.org wrote: On 8 July 2014 13:27, atulkumar singh atul.singh...@gmail.com wrote: Hi Maxin, Thanks for your suggestion for the same. But that git repository for meta-aarch64 is not working. What do you mean by not working. We produce daily builds and they're tested. Thanks and regards Atul On 8 Jul 2014 01:25, Maxin B. John maxin.j...@enea.com wrote: Hi Atul, On Tue, Jul 08, 2014 at 12:41:22AM +0530, atulkumar singh wrote: Hi All, Is there support for Aarch64(64 bit ARMv8) available right now? Yes. Aarch64 support is available in meta-linaro/meta-aarch64 URL: http://git.linaro.org/?p=openembedded/meta-linaro.git If so then what i need to mention as a MACHINE in local.conf. You can choose between: 1. genericarmv8b - generic armv8 big endian machine 2. genericarmv8 - generic armv8 machine Please let me know with your valuable suggestion if any. Please use http://layers.openembedded.org/ to search Machine/Layers/Recipes supported by OpenEmbedded. Thanks and regards, Atul Best Regards, Maxin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Cheers, -- Fathi Boudra Linaro.org | Open source software for ARM SoCs -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Aarch64 support
Hi Atul, On Tue, Jul 08, 2014 at 07:43:03PM +0530, atulkumar singh wrote: Hi Fathi and Maxin, Thanks as you are helping me in sorting out my issue for Aarch64 support in meta-toolchain while building bitbake for yocto. And not working means if we go into the machine/layer/recipes link and under the meta-aarch64 layer the git repository link which is mention is not working. Please let me know with your valuable suggestion. The meta-aarch64 is present in meta-linaro repository. Clone meta-linaro : # git clone git://git.linaro.org/openembedded/meta-linaro.git # cd meta-linaro/meta-aarch64 Thanks and regards, Atul On 8 Jul 2014 18:14, Fathi Boudra fathi.bou...@linaro.org wrote: On 8 July 2014 13:27, atulkumar singh atul.singh...@gmail.com wrote: Best Regards, Maxin snip -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH 01/17] net: lsi_acp_net: Added new string to DT match
From: Anders Berg anders.b...@lsi.com
Add a the vendor prefixed compatible string to the match table.
Signed-off-by: Anders Berg anders.b...@lsi.com
---
drivers/net/ethernet/lsi/lsi_acp_net.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/lsi/lsi_acp_net.c
b/drivers/net/ethernet/lsi/lsi_acp_net.c
index 5589619..de1e895 100644
--- a/drivers/net/ethernet/lsi/lsi_acp_net.c
+++ b/drivers/net/ethernet/lsi/lsi_acp_net.c
@@ -2078,7 +2078,8 @@ static int __devexit appnic_drv_remove(struct
platform_device *pdev)
}
static const struct of_device_id appnic_dt_ids[] = {
- { .compatible = acp-femac, }
+ { .compatible = lsi,acp-femac },
+ { .compatible = acp-femac }
};
MODULE_DEVICE_TABLE(of, appnic_dt_ids);
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 04/17] i2c: axxia: Minor cleanup (cosmetic)
From: Anders Berg anders.b...@avagotech.com
Remove unused definitions and remove redundant variable.
Signed-off-by: Anders Berg anders.b...@avagotech.com
---
drivers/i2c/busses/i2c-axxia.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
index db1a2d3..7355975 100644
--- a/drivers/i2c/busses/i2c-axxia.c
+++ b/drivers/i2c/busses/i2c-axxia.c
@@ -49,8 +49,6 @@ struct i2c_regs {
__le32 mst_tx_xfer;
__le32 mst_addr_1;
__le32 mst_addr_2;
-#define CHIP_READ(_chip) (((_chip) 1) | 1)
-#define CHIP_WRITE(_chip) (((_chip) 1) | 0)
__le32 mst_data;
__le32 mst_tx_fifo;
__le32 mst_rx_fifo;
@@ -115,9 +113,7 @@ struct axxia_i2c_dev {
struct i2c_adapter adapter;
/* clock reference for i2c input clock */
struct clk *i2c_clk;
- /* ioremapped registers cookie */
- void __iomem *base;
- /* pointer to register struct */
+ /* pointer to registers */
struct i2c_regs __iomem *regs;
/* irq number */
int irq;
@@ -365,7 +361,7 @@ axxia_i2c_isr(int irq, void *_dev)
/* Transfer error? */
idev-msg_err = status MST_STATUS_ERR;
i2c_int_disable(idev, ~0);
- dev_err(idev-dev, error %s, rx=%u/%u tx=%u/%u\n,
+ dev_dbg(idev-dev, error %s, rx=%u/%u tx=%u/%u\n,
status_str(status),
readl(idev-regs-mst_rx_bytes_xfrd),
readl(idev-regs-mst_rx_xfer),
@@ -439,13 +435,13 @@ axxia_i2c_xfer_msg(struct axxia_i2c_dev *idev, struct
i2c_msg *msg)
i2c_int_enable(idev, int_mask);
ret = wait_for_completion_timeout(idev-msg_complete,
- I2C_XFER_TIMEOUT);
+ I2C_XFER_TIMEOUT);
i2c_int_disable(idev, int_mask);
WARN_ON(readl(idev-regs-mst_command) 0x8);
- if (WARN_ON(ret == 0)) {
+ if (ret == 0) {
dev_warn(idev-dev, xfer timeout (%#x)\n, msg-addr);
axxia_i2c_init(idev);
return -ETIMEDOUT;
@@ -471,7 +467,7 @@ axxia_i2c_stop(struct axxia_i2c_dev *idev)
writel(0xb, idev-regs-mst_command);
i2c_int_enable(idev, int_mask);
ret = wait_for_completion_timeout(idev-msg_complete,
- I2C_STOP_TIMEOUT);
+ I2C_STOP_TIMEOUT);
i2c_int_disable(idev, int_mask);
if (ret == 0)
return -ETIMEDOUT;
@@ -500,11 +496,11 @@ axxia_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
static u32
axxia_i2c_func(struct i2c_adapter *adap)
{
- return I2C_FUNC_I2C |
- I2C_FUNC_10BIT_ADDR |
- I2C_FUNC_SMBUS_EMUL |
- I2C_FUNC_SMBUS_BLOCK_DATA;
-
+ u32 caps = (I2C_FUNC_I2C |
+ I2C_FUNC_10BIT_ADDR |
+ I2C_FUNC_SMBUS_EMUL |
+ I2C_FUNC_SMBUS_BLOCK_DATA);
+ return caps;
}
static const struct i2c_algorithm axxia_i2c_algo = {
@@ -554,7 +550,6 @@ axxia_i2c_probe(struct platform_device *pdev)
goto err_cleanup;
}
- idev-base = base;
idev-regs = (struct __iomem i2c_regs*)base;
idev-i2c_clk = i2c_clk;
idev-dev = pdev-dev;
@@ -627,7 +622,7 @@ axxia_i2c_remove(struct platform_device *pdev)
i2c_del_adapter(idev-adapter);
free_irq(idev-irq, idev);
clk_put(idev-i2c_clk);
- iounmap(idev-base);
+ iounmap(idev-regs);
kfree(idev);
return 0;
}
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, July 8, 2014 8:00 AM US Pacific Time
Attendees: Stephen, Michael, Bruce, Tom, David, Saul, Jefro, Nitin, Belen, Richard, Mathew, Alex G., Doug, Alex D., * Opens collection - 5 min (Stephen) * Yocto 1.7 status - 5 min (Stephen/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.7_Status https://wiki.yoctoproject.org/wiki/Yocto_1.7_Schedule https://wiki.yoctoproject.org/wiki/Yocto_1.7_Features We had a number of bugs in YP 1.7 M1 rc1 and so to give us time to fix them we did a 1.5.3 build holding off YP 1.7 M1 rc2. It failed in AB. So Monday we did a build on YP 1.7 M1 rc2 with fixes and it should be out of QA later this week. We will do a build shortly again on YP 1.5.3 with fixes to allow it to run in AB successfully. We should QA YP 1.5.3 next week. * SWAT team rotation: Richard - Ross https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team * Opens - 10 min Stephen for Denys - It was suggested that we move the bi-weekly schedule to starting next week. This will allow Denys to attend more often. * Team Sharing - 10 min Michael - We has some data loss last week and believe all data has been restored, but if anyone has issues with the data that was restored, please work with Michael. Richard - We have made some changes to the shared libraries and we have added some package dependency checking. Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * Work Telephone: (503) 712-0534 *Cell:(208) 244-4460 * Email: stephen.k.jol...@intel.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] core-image-weston: do_rootfs failure installing libcogl
I am attempting to build core-image-weston with Poky from Master. It fails creating the rootfs when smart tries to install libcogl (details at the end): error: libcogl20-1.18.0-r0@i586 conflicts with libcogl-path20-1.18.0-r0@i586 I have searched for this issue in Bugzilla and across the web. No luck. Is that something anyone here knows about? Thanks, Rudi Build Configuration: BB_VERSION= 1.23.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Fedora-18 TARGET_SYS= i586-poky-linux MACHINE = qemux86 DISTRO= poky DISTRO_VERSION= 1.6+snapshot-20140708 TUNE_FEATURES = m32 i586 TARGET_FPU= meta meta-yocto meta-yocto-bsp= master:a5531a2b8983318b99c119a87b78a92cf84160b8 NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: Unable to install packages. Command '/run/media/rudi/SanDisk-256G/develop/yocto/yocto-git/x86/tmp/sysroots/x86_64-linux/usr/bin/smart --data-dir=/run/media/rudi/SanDisk-256G/develop/yocto/yocto-git/x86/tmp/work/qemux86-poky-linux/core-image-weston/1.0-r0/rootfs/var/lib/smart install -y packagegroup-core-ssh-dropbear@all psplash@i586 libclutter-1.0-examples@i586 packagegroup-base-extended@qemux86 smartpm@i586 packagegroup-core-tools-debug@qemux86 packagegroup-core-eclipse-debug@all weston@i586 weston-init@all gtk+3-demo@i586 weston-examples@i586 packagegroup-core-sdk@all packagegroup-core-standalone-sdk-target@all rpm@i586 packagegroup-core-boot@qemux86 locale-base-en-us@i586 locale-base-en-gb@i586' returned 1: Loading cache... Updating cache... [100%] Computing transaction...error: Can't install libcogl-path20-1.18.0-r0@i586: unable to install provider for libcogl20 = 1.18.0: error: libcogl20-1.18.0-r0@i586 conflicts with libcogl-path20-1.18.0-r0@i586 ERROR: Function failed: do_rootfs E -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] MIPI for Intel E3800 Bay Trail
This question is lesser a matter of YP but probably of upstream support. Nevertheless, the YP kernel experts would certainly know. Which, if any, of the YP kernels provide MIPI drivers for the Intel E3800? Thanks, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] core-image-weston: do_rootfs failure installing libcogl
On 8 July 2014 18:28, Rudolf Streif rstr...@linuxfoundation.org wrote: I am attempting to build core-image-weston with Poky from Master. It fails creating the rootfs when smart tries to install libcogl (details at the end): error: libcogl20-1.18.0-r0@i586 conflicts with libcogl-path20-1.18.0-r0@i586 That's interesting, I just built core-image-weston from master and it worked fine. Then again looking at the packages generated and their contents, something very strange is happening :/ Can you file a bug? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Minimalist Initrd
On 6 July 2014 04:57, Jeremy Moles cubic...@gmail.com wrote: I've encountered a scenario wherein I have only (and this constraint can't be worked around) 13MB of space into which I can place a JFFS2 image which can be used to continue the system startup (which is initially started by an older version of uboot). I'm having trouble finding a clean solution within the Yocto/OE world for this issue. Thus far, I've been using an old, generic, super-tiny ARM-based initrd I made years ago which just does a few (proprietary) things in the linux and then fires off /sbin/init in the real filesystem. What I need now, however, is a recipe (or perhaps hints on where to start when rolling my own recipe) for generating little more than an image (JFFS2 or cpio.gz) with busybox in it. I can handle the rest view function overrides, I just need the base startup. This sounds exactly like what core-image-minimal-initramfs is for. If it's not what you want, it certainly demonstrates how to trim an image down in size. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] MIPI for Intel E3800 Bay Trail
I don't know what MIPI is but the Baytrail platform is supported from v3.13 as far as I remember. Tirsdag den 8. juli 2014 12:14:10 skrev Rudolf Streif: This question is lesser a matter of YP but probably of upstream support. Nevertheless, the YP kernel experts would certainly know. Which, if any, of the YP kernels provide MIPI drivers for the Intel E3800? Thanks, Rudi -- Søren Holm -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] IMAGE_INSTALL
Hi All, I want to include coreutils package in my image. I have included IMAGE_INSTALL += \ coreutils \ in my image file. But, I do not see any coreutils package in tmp folder. Let me know if my understanding is wrong. Thanks Regards, Bharath Chandra Elluru. Contact Number:785-979-4875. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] MIPI for Intel E3800 Bay Trail
Søren, Thank you for your response. Yes, Bay Trail is essentially supported however I do not know if there are any MIPI drivers available for that platform. MIPI stands for the Mobile Industry Processor Interface. The standard is created by the MIPI Alliance (http://www.mipi.org). Intel Bay Trail E3800 chips support it and so do Freescale i.MX6. The standard defines multiple interfaces. In this case it's mostly about the camera interface. Thanks, Rudi On Tue, Jul 8, 2014 at 2:56 PM, Søren Holm s...@sgh.dk wrote: I don't know what MIPI is but the Baytrail platform is supported from v3.13 as far as I remember. Tirsdag den 8. juli 2014 12:14:10 skrev Rudolf Streif: This question is lesser a matter of YP but probably of upstream support. Nevertheless, the YP kernel experts would certainly know. Which, if any, of the YP kernels provide MIPI drivers for the Intel E3800? Thanks, Rudi -- Søren Holm -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_INSTALL
Hi Bharath, IMAGE_INSTALL += \ coreutils \ You may want to post your entire recipe. in my image file. But, I do not see any coreutils package in tmp folder. Let me know if my understanding is wrong. It should be in tmp/work/i586-poky-linux/coreutils/ if you are building for x86. Did you check your image too? Best regards, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] core-image-weston: do_rootfs failure installing libcogl
Can you file a bug? Thanks, Ross. Done. 6514 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_INSTALL
Hi Rudolf, I need to include only coreutils package in my image. I have written a recipe file as follows My recipe file is as follows: DESCRIPTION = A test image for Gumstix boards. LICENSE = CLOSED IMAGE_INSTALL += \ coreutils \ Thanks, Bharath. On Tue, Jul 8, 2014 at 5:42 PM, Rudolf Streif rstr...@linuxfoundation.org wrote: Hi Bharath, IMAGE_INSTALL += \ coreutils \ You may want to post your entire recipe. in my image file. But, I do not see any coreutils package in tmp folder. Let me know if my understanding is wrong. It should be in tmp/work/i586-poky-linux/coreutils/ if you are building for x86. Did you check your image too? Best regards, Rudi -- Thanks Regards, Bharath Chandra Elluru. Contact Number:785-979-4875. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] IMAGE_INSTALL
Hi Barath, That alone won't work. You can either quick and dirty add IMAGE_INSTALL_append = coreutils to your conf/local.conf file or you write your recipe but it will need to include another image recipe: DESCRIPTION = A test image for Gumstix boards. LICENSE = CLOSED require recipes-core/images/core-image-base.bb IMAGE_INSTALL += \ coreutils \ then you can build your image with bitbake -k myimage given that you named you recipe above myimage.bb Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] yocto-1.5.3.rc1 now available
The first release candidate for 1.5.3 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-1.5.3.rc1 bitbake 3bb3f1823bdd46ab34577d43f1e39046a32bca77 eclipse-poky-juno 79cd3c6ff119526f3f85567253450d2e857afed0 eclipse-poky-kepler e2cc15b1549d197ab15073f52274401d0fd86686 meta-fsl-arm 5fdb620c09df11e70434092f675c891e0ba84108 meta-fsl-ppc 40465bac88ca28b554cff35346341d19552548bf meta-intel 7203d4de60f69190b5eae308ed2d09edbc63ea1f meta-minnow 9aa60d0eaf03fe30670acf581eaf7e57c76b5f99 meta-qt3 4772424ab69908d4e3b9d6d4717ca889468e6acd oecore 026d26e3b6c2f608cc03aa00fe1fb1ace9e070d8 poky dc743744d8e3a9caef577aeab6b7f51bc08ded17 -- Elizabeth Flanagan Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH 00/17] LSI AXXIA updates to 3.4 standard/axxia/base
Updates to 2sc and additions to the 3500 Anders Berg (12): net: lsi_acp_net: Added new string to DT match ARM: dts: axxia: Corrected IRQ for memory contollers ARM: axxia: Support MSI on both PCIe controllers i2c: axxia: Minor cleanup (cosmetic) i2c: axxia: Report spurious IRQ i2c: axxia: Fix broken smbus block read i2c: axxia: Fall back to polling mode when no IRQ ARM: axxia: Fix .init section mismatch spi: pl022: Fix .init section mismatch gpio: pl061: Fix .init section mismatch misc: lsi-smmon: Bug when probing with IRQ pending misc: lsi-smmon: Add parameter panic_on_fatal John Jacques (4): arch/powerpc: Updated Device Trees for Axxia (3400/3500) arch/powerpc: Update the Axxia NAND Driver to support 3500 kernel/smp: Allow smp_call_function_single() to be called with a function that doesn't return. arch/powerpc: Reset Updates for Axxia SangeethaRao (1): powerpc/sysdev/lsi:adding 3500 PCIe inbound mapping support arch/arm/boot/dts/axm55xx.dts |4 +- arch/arm/mach-axxia/pci.c | 75 --- arch/powerpc/boot/dts/acp342x.dts | 347 +--- arch/powerpc/boot/dts/acp344x.dts | 164 ++- arch/powerpc/boot/dts/acp35xx.dts | 73 +++ arch/powerpc/sysdev/lsi_pci.c | 40 +++- arch/powerpc/sysdev/ppc4xx_soc.c | 73 ++- drivers/gpio/gpio-pl061.c |2 +- drivers/i2c/busses/i2c-axxia.c | 109 ++ drivers/misc/lsi-smmon.c | 58 -- drivers/mtd/nand/lsi_acp_nand.c| 171 +--- drivers/net/ethernet/lsi/lsi_acp_net.c |3 +- drivers/spi/spi-pl022.c|4 +- kernel/smp.c | 24 ++- 14 files changed, 699 insertions(+), 448 deletions(-) -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 02/17] ARM: dts: axxia: Corrected IRQ for memory contollers
From: Anders Berg anders.b...@lsi.com
The interrupt numbers for the memory controllers was wrong (conflicting with
assigned range for PCI MSI. This would cause a device using MSI to fail to
request its IRQ.
Signed-off-by: Anders Berg anders.b...@lsi.com
---
arch/arm/boot/dts/axm55xx.dts |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/axm55xx.dts b/arch/arm/boot/dts/axm55xx.dts
index 826a6e6..91d3f42 100644
--- a/arch/arm/boot/dts/axm55xx.dts
+++ b/arch/arm/boot/dts/axm55xx.dts
@@ -198,13 +198,13 @@
sm0@0022 {
compatible = lsi,smmon;
reg = 0 0x0022 0 0x1000;
- interrupts = 0 192 4;
+ interrupts = 0 161 4;
};
sm1@0022 {
compatible = lsi,smmon;
reg = 0 0x000f 0 0x1000;
- interrupts = 0 193 4;
+ interrupts = 0 160 4;
};
gpdma@202014 {
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 06/17] i2c: axxia: Fix broken smbus block read
From: Anders Berg anders.b...@avagotech.com
Changed the initial transfer size on block reads from 1 to
I2C_SMBUS_BLOCK_MAX. The size is adjusted when the first byte (block
length) is received. Having the initial size set to 1 could cause the
controller to stop the transfer after the block length byte, if the
transfer length register wasn't updated in time.
Signed-off-by: Anders Berg anders.b...@avagotech.com
---
drivers/i2c/busses/i2c-axxia.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
index e965793..15d5f0d 100644
--- a/drivers/i2c/busses/i2c-axxia.c
+++ b/drivers/i2c/busses/i2c-axxia.c
@@ -271,15 +271,18 @@ axxia_i2c_empty_rx_fifo(struct axxia_i2c_dev *idev)
while (0 bytes_to_transfer--) {
int c = readl(idev-regs-mst_data);
if (idev-msg_xfrd == 0 i2c_m_recv_len(msg)) {
- if (c == 0 || c I2C_SMBUS_BLOCK_MAX) {
+ /*
+* Check length byte for SMBus block read
+*/
+ if (c = 0) {
idev-msg_err = -EPROTO;
i2c_int_disable(idev, ~0);
- dev_err(idev-dev,
- invalid SMBus block size (%d)\n, c);
complete(idev-msg_complete);
break;
+ } else if (c I2C_SMBUS_BLOCK_MAX) {
+ c = I2C_SMBUS_BLOCK_MAX;
}
- msg-len += c;
+ msg-len = 1 + c;
writel(msg-len, idev-regs-mst_rx_xfer);
}
msg-buf[idev-msg_xfrd++] = c;
@@ -402,7 +405,10 @@ axxia_i2c_xfer_msg(struct axxia_i2c_dev *idev, struct
i2c_msg *msg)
/* TX 0 bytes */
writel(0, idev-regs-mst_tx_xfer);
/* RX # bytes */
- writel(msg-len, idev-regs-mst_rx_xfer);
+ if (i2c_m_recv_len(msg))
+ writel(I2C_SMBUS_BLOCK_MAX, idev-regs-mst_rx_xfer);
+ else
+ writel(msg-len, idev-regs-mst_rx_xfer);
} else {
/* TX # bytes */
writel(msg-len, idev-regs-mst_tx_xfer);
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 08/17] ARM: axxia: Fix .init section mismatch
From: Anders Berg anders.b...@avagotech.com
Signed-off-by: Anders Berg anders.b...@avagotech.com
---
arch/arm/mach-axxia/pci.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-axxia/pci.c b/arch/arm/mach-axxia/pci.c
index 0f94403..ae6eaf8 100644
--- a/arch/arm/mach-axxia/pci.c
+++ b/arch/arm/mach-axxia/pci.c
@@ -576,7 +576,7 @@ pcie_msi_irq_handler(unsigned int irq, struct irq_desc
*desc)
/* PCIe setup function */
-static int axxia_pcie_setup(int portno, struct pci_sys_data *sys)
+static __devinit int axxia_pcie_setup(int portno, struct pci_sys_data *sys)
{
struct axxia_pciex_port *port = axxia_pciex_ports[sys-domain];
u32 pci_config, pci_status, link_state;
@@ -757,7 +757,7 @@ pcie_alloc_msi_table(struct pci_dev *pdev, struct
axxia_pciex_port *port)
/*
* Scan PCIe bus
*/
-static struct pci_bus __init *
+static __devinit struct pci_bus *
axxia_pcie_scan_bus(int nr, struct pci_sys_data *sys)
{
if (WARN_ON(nr = PCIE_MAX_PORTS))
@@ -769,7 +769,7 @@ axxia_pcie_scan_bus(int nr, struct pci_sys_data *sys)
-static int __init
+static __devinit int
axxia_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
struct pci_sys_data *sys = dev-sysdata;
@@ -788,7 +788,7 @@ static struct irq_chip axxia_msi_chip = {
/* Port definition struct */
-static struct hw_pci axxia_pcie_hw[] = {
+static struct hw_pci axxia_pcie_hw[] __initdata = {
[0] = {
.nr_controllers = 1,
.domain = 0,
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 10/17] gpio: pl061: Fix .init section mismatch
From: Anders Berg anders.b...@avagotech.com
Signed-off-by: Anders Berg anders.b...@avagotech.com
---
drivers/gpio/gpio-pl061.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 9d35136..3d0e9fc 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -390,7 +390,7 @@ static const struct dev_pm_ops pl061_dev_pm_ops = {
#endif
#ifdef CONFIG_ARM_AMBA
-static int __init pl061_amba_probe(struct amba_device *dev, struct amba_id *id)
+static int pl061_amba_probe(struct amba_device *dev, const struct amba_id *id)
{
return pl061_probe(dev-dev, dev-res, dev-irq[0], NULL);
}
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 11/17] misc: lsi-smmon: Bug when probing with IRQ pending
From: Anders Berg anders.b...@avagotech.com
We must not call the ncr_write function to unmask interrupts with
the memory controller interrupt enabled, as this could cause the ISR to
be invoked before ncr_write has released the lock used to serialize
register accesses.
To avoid this, temporarily disable the IRQ line while unmasking the
interrupt sources in the controller.
Signed-off-by: Anders Berg anders.b...@avagotech.com
---
drivers/misc/lsi-smmon.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/misc/lsi-smmon.c b/drivers/misc/lsi-smmon.c
index fe0d9e0..d263df9 100644
--- a/drivers/misc/lsi-smmon.c
+++ b/drivers/misc/lsi-smmon.c
@@ -200,8 +200,8 @@ smmon_probe(struct platform_device *pdev)
{
struct sm_dev *sm;
struct resource *io;
- struct resource *irq;
- u32 mask = SM_INT_MASK;
+ int irq;
+ u32 mask;
int rc = 0;
sm = devm_kzalloc(pdev-dev, sizeof *sm, GFP_KERNEL);
@@ -218,26 +218,37 @@ smmon_probe(struct platform_device *pdev)
}
sm-region = io-start;
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!irq) {
- rc = -EINVAL;
+ /* Disable all memory controller interrupts */
+ mask = 0x;
+ ncr_write(sm-region, 0x414, 4, mask);
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ rc = irq;
goto out;
}
- rc = devm_request_irq(pdev-dev, irq-start, smmon_isr,
- IRQF_ONESHOT, dev_name(pdev-dev), pdev);
+ rc = devm_request_irq(pdev-dev, irq, smmon_isr,
+ IRQF_ONESHOT, dev_name(pdev-dev), sm);
if (rc)
goto out;
- /* Enable memory controller interrupts */
- ncr_write(sm-region, 0x414, 4, mask);
-
rc = sysfs_create_group(pdev-dev.kobj, smmon_attr_group);
if (rc)
goto out;
dev_set_drvdata(pdev-dev, sm);
pr_info(%s: Memory controller monitor\n, dev_name(pdev-dev));
+
+ /* Enable memory controller interrupts. We need to disable the
+* interrupt while unmasking it, since otherwise there will be a
+* locking conflict in ncr_write/ncr_read when the ISR tries to read
+* interrupt status.
+*/
+ disable_irq(irq);
+ mask = SM_INT_MASK;
+ ncr_write(sm-region, 0x414, 4, mask);
+ enable_irq(irq);
out:
return rc;
}
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 09/17] spi: pl022: Fix .init section mismatch
From: Anders Berg anders.b...@avagotech.com
Signed-off-by: Anders Berg anders.b...@avagotech.com
---
drivers/spi/spi-pl022.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 1204d69..12b925b 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2287,8 +2287,8 @@ static struct vendor_data vendor_db5500_pl023 = {
.loopback = true,
};
-static int __init
-pl022_amba_probe(struct amba_device *adev, struct amba_id *id)
+static int
+pl022_amba_probe(struct amba_device *adev, const struct amba_id *id)
{
struct pl022 *pl022 = NULL;
int ret;
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 14/17] arch/powerpc: Updated Device Trees for Axxia (3400/3500)
From: John Jacques john.jacq...@lsi.com
Also added the 6th Core to the Default 3500 Device Tree
Signed-off-by: John Jacques john.jacq...@lsi.com
---
arch/powerpc/boot/dts/acp342x.dts | 347 +++--
arch/powerpc/boot/dts/acp344x.dts | 164 --
arch/powerpc/boot/dts/acp35xx.dts | 73
3 files changed, 323 insertions(+), 261 deletions(-)
diff --git a/arch/powerpc/boot/dts/acp342x.dts
b/arch/powerpc/boot/dts/acp342x.dts
index 6e02a8c..28a0a13 100644
--- a/arch/powerpc/boot/dts/acp342x.dts
+++ b/arch/powerpc/boot/dts/acp342x.dts
@@ -1,10 +1,10 @@
/*
- * Device Tree Source for IBM Embedded PPC 476 Platform
+ * Device Tree Source for LSI Axxia ACP342x.
*
- * Copyright 2009 Torez Smith, IBM Corporation.
+ * Copyright 2013, LSI Corporation.
*
* Based on earlier code:
- * Copyright (c) 2006, 2007 IBM Corp.
+ * Copyright (c) 2009, 2006, 2007 IBM Corp.
* Josh Boyer jwbo...@linux.vnet.ibm.com, David Gibson d...@au1.ibm.com
*
* This file is licensed under the terms of the GNU General Public
@@ -17,165 +17,187 @@
/memreserve/ 0x 0x0040;
/ {
-#address-cells = 2;
-#size-cells = 1;
-model = ibm,acpx1-4xx;
-compatible = ibm,acpx1-4xx,ibm,47x-AMP;
-dcr-parent = {/cpus/cpu@0};
-
-aliases {
-serial0 = UART0;
-serial1 = UART1;
-rapidio0 = rio0;
+ #address-cells = 2;
+ #size-cells = 1;
+ model = ibm,acpx1-4xx;
+ compatible = lsi,acp3420, lsi,acp, ibm,acpx1-4xx;
+ dcr-parent = {/cpus/cpu@0};
+
+ aliases {
+ serial0 = UART0;
+ serial1 = UART1;
ethernet0 = FEMAC;
-};
+ rapidio0 = SRIO0;
+ };
-cpus {
-#address-cells = 1;
-#size-cells = 0;
-
-cpu@0 {
-device_type = cpu;
-model = PowerPC,4xx; // real CPU changed in sim
-reg = 0;
-clock-frequency = 0x5f5e1000;
-timebase-frequency = 0x5f5e1000;
-i-cache-line-size = 32;
-d-cache-line-size = 32;
-i-cache-size = 32768;
-d-cache-size = 32768;
-dcr-controller;
-dcr-access-method = native;
-status = ok;
-reset-type = 3; // 1=core, 2=chip, 3=system (default)
-};
-};
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ device_type = cpu;
+ model = PowerPC,4xx; // real CPU changed in sim
+ reg = 0;
+ clock-frequency = 0; // filled in by U-Boot
+ timebase-frequency = 0; // filled in by U-Boot
+ i-cache-line-size = 32;
+ d-cache-line-size = 32;
+ i-cache-size = 32768;
+ d-cache-size = 32768;
+ dcr-controller;
+ dcr-access-method = native;
+ status = ok;
+ reset-type = 3; // 1=core, 2=chip, 3=system (default)
+ };
+
+ cpu@1 {
+ device_type = cpu;
+ model = PowerPC,4xx; // real CPU changed in sim
+ reg = 1;
+ clock-frequency = 0; // filled in by U-Boot
+ timebase-frequency = 0; // filled in by U-Boot
+ i-cache-line-size = 32;
+ d-cache-line-size = 32;
+ i-cache-size = 32768;
+ d-cache-size = 32768;
+ dcr-controller;
+ dcr-access-method = native;
+ status = disabled;
+ enable-method = spin-table;
+ cpu-release-addr = 0 0; // filled in by U-Boot
+ reset-type = 3; // 1=core, 2=chip, 3=system (default)
+ };
+ };
memory@0 {
device_type = memory;
-reg = 0x 0x 0x8000; // filled in by
U-Boot
+reg = 0 0 0; // filled in by U-Boot
};
memory@8000 {
device_type = memory;
-reg = 0x 0x8000 0x8000; // filled in by
U-Boot
+reg = 0 0 0; // filled in by U-Boot
};
-MPIC: interrupt-controller {
-compatible = chrp,open-pic;
-interrupt-controller;
-dcr-reg = 0xffc0 0x0003;
-#address-cells = 0;
-#size-cells = 0;
-#interrupt-cells =
[linux-yocto] [PATCH 12/17] misc: lsi-smmon: Add parameter panic_on_fatal
From: Anders Berg anders.b...@avagotech.com
Added module parameter panic_on_fatal which when set will cause the driver
to call panic() when an uncorrectable ECC error is detected.
Signed-off-by: Anders Berg anders.b...@avagotech.com
---
drivers/misc/lsi-smmon.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/misc/lsi-smmon.c b/drivers/misc/lsi-smmon.c
index d263df9..88f291a 100644
--- a/drivers/misc/lsi-smmon.c
+++ b/drivers/misc/lsi-smmon.c
@@ -24,6 +24,10 @@ static int log = 1;
module_param(log, int, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(log, Log each error to kernel log.);
+static int panic_on_fatal = 1;
+module_param(panic_on_fatal, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(panic_on_fatal, Panic on fatal error.);
+
/*
AXM55xx memory controller interrupt status bits:
@@ -96,18 +100,19 @@ static const u32 event_mask[NR_EVENTS] = {
};
static const struct event_logging {
+ int fatal;
const char *level;
const char *name;
} event_logging[NR_EVENTS] = {
- [EV_ILLEGAL] = {KERN_ERR, Illegal access},
- [EV_MULT_ILLEGAL]= {KERN_ERR, Illegal access},
- [EV_CORR_ECC]= {KERN_NOTICE, Correctable ECC error},
- [EV_MULT_CORR_ECC] = {KERN_NOTICE, Correctable ECC error},
- [EV_UNCORR_ECC] = {KERN_CRIT, Uncorrectable ECC error},
- [EV_MULT_UNCORR_ECC] = {KERN_CRIT, Uncorrectable ECC error},
- [EV_PORT_ERROR] = {KERN_CRIT, Port error},
- [EV_WRAP_ERROR] = {KERN_CRIT, Wrap error},
- [EV_PARITY_ERROR]= {KERN_CRIT, Parity error},
+ [EV_ILLEGAL] = {0, KERN_ERR, Illegal access},
+ [EV_MULT_ILLEGAL]= {0, KERN_ERR, Illegal access},
+ [EV_CORR_ECC]= {0, KERN_NOTICE, Correctable ECC error},
+ [EV_MULT_CORR_ECC] = {0, KERN_NOTICE, Correctable ECC error},
+ [EV_UNCORR_ECC] = {1, KERN_CRIT, Uncorrectable ECC error},
+ [EV_MULT_UNCORR_ECC] = {1, KERN_CRIT, Uncorrectable ECC error},
+ [EV_PORT_ERROR] = {0, KERN_CRIT, Port error},
+ [EV_WRAP_ERROR] = {0, KERN_CRIT, Wrap error},
+ [EV_PARITY_ERROR]= {0, KERN_CRIT, Parity error},
};
struct smmon_attr {
@@ -181,6 +186,10 @@ static irqreturn_t smmon_isr(int interrupt, void *device)
for (i = 0; i NR_EVENTS; ++i) {
if ((status event_mask[i]) != 0) {
++sm-counter[i];
+ if (panic_on_fatal event_logging[i].fatal)
+ panic(%s (%s)\n,
+ event_logging[i].name,
+ dev_name(sm-pdev-dev));
if (log)
printk_ratelimited(%s%s: %s\n,
event_logging[i].level,
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 15/17] arch/powerpc: Update the Axxia NAND Driver to support 3500
From: John Jacques john.jacq...@lsi.com
Signed-off-by: John Jacques john.jacq...@lsi.com
---
drivers/mtd/nand/lsi_acp_nand.c | 171 +--
1 file changed, 93 insertions(+), 78 deletions(-)
diff --git a/drivers/mtd/nand/lsi_acp_nand.c b/drivers/mtd/nand/lsi_acp_nand.c
index 1cac342..07c521e 100644
--- a/drivers/mtd/nand/lsi_acp_nand.c
+++ b/drivers/mtd/nand/lsi_acp_nand.c
@@ -342,16 +342,11 @@ _WRITEL(const char *file, int line, unsigned long value,
unsigned long address)
*/
static void *gpreg_base;
-
-#define LSI_NAND_PECC_BUSY_REGISTER (gpreg_base + 0x00c)
-
-#ifdef CONFIG_ACP_X1V1
-#define LSI_NAND_PECC_BUSY_MASK(1 25)
-#else
-#define LSI_NAND_PECC_BUSY_MASK(1 28)
-#endif
+static void *pecc_busy_register;
+static unsigned long pecc_busy_mask;
#define MAX_READ_BUF 16
+
/*
--
MTD structures
@@ -706,8 +701,8 @@ lsi_nand_command(struct mtd_info *mtd, unsigned int command,
NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
do {
udelay(chip-chip_delay);
- status = READL((void *)LSI_NAND_PECC_BUSY_REGISTER);
- } while (0 != (status LSI_NAND_PECC_BUSY_MASK));
+ status = READL(pecc_busy_register);
+ } while (0 != (status pecc_busy_mask));
/* wait until CHIP_BUSY goes low */
do {
@@ -835,9 +830,9 @@ static int lsi_nand_wait(struct mtd_info *mtd, struct
nand_chip *chip)
#ifdef NOT_USED
if (FL_READING == chip-state || FL_WRITING == chip-state) {
for (;;) {
- status = READL((void *)LSI_NAND_PECC_BUSY_REGISTER);
+ status = READL((void *)pecc_busy_register);
- if (0 == (status LSI_NAND_PECC_BUSY_MASK))
+ if (0 == (status pecc_busy_mask))
break;
udelay(chip-chip_delay);
@@ -845,9 +840,9 @@ static int lsi_nand_wait(struct mtd_info *mtd, struct
nand_chip *chip)
}
#else
for (;;) {
- status = READL((void *)LSI_NAND_PECC_BUSY_REGISTER);
+ status = READL((void *)pecc_busy_register);
- if (0 == (status LSI_NAND_PECC_BUSY_MASK))
+ if (0 == (status pecc_busy_mask))
break;
udelay(chip-chip_delay);
@@ -3468,15 +3463,17 @@ lsi_nand_init(void)
void *nand_base;
struct device_node *np = NULL;
struct mtd_part_parser_data ppdata;
- static const char *part_probe_types[]
- = { cmdlinepart, ofpart, NULL };
-
- np = of_find_compatible_node(NULL, NULL, lsi,acp3500);
-
- if (NULL != np) {
- printk(KERN_ERR NAND Support is Not Yet Available on 3500\n);
- return -1;
- }
+ static const char *part_probe_types[] =
+ { cmdlinepart, ofpart, NULL };
+ const u32 *reg;
+ int reglen;
+ u64 nand_address;
+ unsigned long nand_length;
+ u64 gpreg_address;
+ unsigned long gpreg_length;
+ const u32 *enabled;
+ unsigned long cr;
+ unsigned long cr_save;
memset(ppdata, 0, sizeof(ppdata));
@@ -3485,74 +3482,92 @@ lsi_nand_init(void)
while (np !of_device_is_compatible(np, acp-nand))
np = of_find_node_by_type(np, nand);
- if (np) {
- const u32 *reg;
- int reglen;
- u64 nand_address;
- unsigned long nand_length;
- u64 gpreg_address;
- unsigned long gpreg_length;
- const u32 *enabled;
+ if (NULL == np) {
+ printk(KERN_ERR No NAND Nodes in Device Tree\n);
- enabled = of_get_property(np, enabled, NULL);
+ return -1;
+ }
- if (!enabled || (enabled (0 == *enabled))) {
- printk(KERN_INFO ACP NAND Controller Isn't
Enabled.\n);
- return -ENODEV;
- }
+ enabled = of_get_property(np, enabled, NULL);
- reg = of_get_property(np, reg, reglen);
-
- if (reg (16 == reglen)) {
- nand_address = of_translate_address(np, reg);
- nand_length = reg[1];
- reg += 2;
- gpreg_address = of_translate_address(np, reg);
- gpreg_length = reg[1];
- printk(KERN_INFO nand_address=0x%08llx
nand_length=0x%lx\n
- gpreg_address=0x%08llx gpreg_length=0x%lx\n,
- nand_address, nand_length,
- gpreg_address, gpreg_length);
- nand_base = ioremap(nand_address, nand_length);
- gpreg_base =
[linux-yocto] [PATCH 17/17] arch/powerpc: Reset Updates for Axxia
From: John Jacques john.jacq...@lsi.com
Signed-off-by: John Jacques john.jacq...@lsi.com
---
arch/powerpc/sysdev/ppc4xx_soc.c | 73 +-
1 file changed, 72 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_soc.c b/arch/powerpc/sysdev/ppc4xx_soc.c
index 0debcc3..5505f46 100644
--- a/arch/powerpc/sysdev/ppc4xx_soc.c
+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
@@ -24,6 +24,9 @@
#include asm/dcr.h
#include asm/dcr-regs.h
#include asm/reg.h
+#ifdef CONFIG_ACP
+#include asm/mpic.h
+#endif
static u32 dcrbase_l2c;
@@ -60,7 +63,7 @@ static irqreturn_t l2c_error_handler(int irq, void *dev)
}
/* Clear parity errors */
- if (sr (L2C_SR_CPE | L2C_SR_TPE)){
+ if (sr (L2C_SR_CPE | L2C_SR_TPE)) {
mtdcr(dcrbase_l2c + DCRN_L2C0_ADDR, 0);
mtdcr(dcrbase_l2c + DCRN_L2C0_CMD, L2C_CMD_CCP | L2C_CMD_CTE);
} else {
@@ -190,6 +193,45 @@ static int __init ppc4xx_l2c_probe(void)
}
arch_initcall(ppc4xx_l2c_probe);
+#ifdef CONFIG_ACP
+
+/*
+ * Issue a core reset.
+ */
+
+void
+acp_jump_to_boot_loader(void *input)
+{
+ mpic_teardown_this_cpu(0);
+ /* This is only valid in the core reset case, so 0x1000. */
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | 0x1000);
+
+ while (1)
+ ; /* Just in case the jump fails. */
+}
+
+/*
+ * Get all other cores to run acp_jump_to_boot_loader() then go
+ * there as well.
+ */
+
+void
+acp_reset_cores(void)
+{
+ int cpu;
+
+ for_each_possible_cpu(cpu) {
+ if (cpu != smp_processor_id())
+ smp_call_function_single(cpu, acp_jump_to_boot_loader,
+NULL, 0);
+ }
+
+ acp_jump_to_boot_loader(NULL);
+}
+
+
+#endif
+
/*
* Apply a system reset. Alternatively a board specific value may be
* provided via the reset-type property in the cpu node.
@@ -214,7 +256,36 @@ void ppc4xx_reset_system(char *cmd)
reset_type = prop[0] 28;
}
+#ifdef CONFIG_ACP
+ if (DBCR0_RST_CORE == reset_type) {
+ acp_reset_cores();
+ } else {
+ /*
+ In this case, reset_type is either chip or system.
+
+ On the AXM3500 (PVR=0x7ff520c1), writing to DBCR0
+ will occasionally stall the system. As a
+ work-around, write to the system control register.
+ */
+
+ u32 pvr_value;
+
+ asm volatile (mfpvr%0 : =r(pvr_value));
+
+ if (0x7ff520c1 == pvr_value) {
+ u32 value;
+
+ value = mfdcrx(0xd0a);
+ value |= 0xab;
+ mtdcrx(0xd0a, value);
+ mtdcrx(0xe00, 1);
+ } else {
+ mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | reset_type);
+ }
+ }
+#else
mtspr(SPRN_DBCR0, mfspr(SPRN_DBCR0) | reset_type);
+#endif
while (1)
; /* Just in case the reset doesn't work */
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 15/17] arch/powerpc: Update the Axxia NAND Driver to support 3500
On 14-07-08 10:22 AM, Charlie Paul wrote:
From: John Jacques john.jacq...@lsi.com
The change is larger than I'd expect to add some new support. Is there a mix
of cleanups and new support in this change ? That's what it looks like.
Bruce
Signed-off-by: John Jacques john.jacq...@lsi.com
---
drivers/mtd/nand/lsi_acp_nand.c | 171 +--
1 file changed, 93 insertions(+), 78 deletions(-)
diff --git a/drivers/mtd/nand/lsi_acp_nand.c b/drivers/mtd/nand/lsi_acp_nand.c
index 1cac342..07c521e 100644
--- a/drivers/mtd/nand/lsi_acp_nand.c
+++ b/drivers/mtd/nand/lsi_acp_nand.c
@@ -342,16 +342,11 @@ _WRITEL(const char *file, int line, unsigned long value,
unsigned long address)
*/
static void *gpreg_base;
-
-#define LSI_NAND_PECC_BUSY_REGISTER (gpreg_base + 0x00c)
-
-#ifdef CONFIG_ACP_X1V1
-#define LSI_NAND_PECC_BUSY_MASK(1 25)
-#else
-#define LSI_NAND_PECC_BUSY_MASK(1 28)
-#endif
+static void *pecc_busy_register;
+static unsigned long pecc_busy_mask;
#define MAX_READ_BUF 16
+
/*
--
MTD structures
@@ -706,8 +701,8 @@ lsi_nand_command(struct mtd_info *mtd, unsigned int command,
NAND_NCE | NAND_CLE | NAND_CTRL_CHANGE);
do {
udelay(chip-chip_delay);
- status = READL((void *)LSI_NAND_PECC_BUSY_REGISTER);
- } while (0 != (status LSI_NAND_PECC_BUSY_MASK));
+ status = READL(pecc_busy_register);
+ } while (0 != (status pecc_busy_mask));
/* wait until CHIP_BUSY goes low */
do {
@@ -835,9 +830,9 @@ static int lsi_nand_wait(struct mtd_info *mtd, struct
nand_chip *chip)
#ifdef NOT_USED
if (FL_READING == chip-state || FL_WRITING == chip-state) {
for (;;) {
- status = READL((void *)LSI_NAND_PECC_BUSY_REGISTER);
+ status = READL((void *)pecc_busy_register);
- if (0 == (status LSI_NAND_PECC_BUSY_MASK))
+ if (0 == (status pecc_busy_mask))
break;
udelay(chip-chip_delay);
@@ -845,9 +840,9 @@ static int lsi_nand_wait(struct mtd_info *mtd, struct
nand_chip *chip)
}
#else
for (;;) {
- status = READL((void *)LSI_NAND_PECC_BUSY_REGISTER);
+ status = READL((void *)pecc_busy_register);
- if (0 == (status LSI_NAND_PECC_BUSY_MASK))
+ if (0 == (status pecc_busy_mask))
break;
udelay(chip-chip_delay);
@@ -3468,15 +3463,17 @@ lsi_nand_init(void)
void *nand_base;
struct device_node *np = NULL;
struct mtd_part_parser_data ppdata;
- static const char *part_probe_types[]
- = { cmdlinepart, ofpart, NULL };
-
- np = of_find_compatible_node(NULL, NULL, lsi,acp3500);
-
- if (NULL != np) {
- printk(KERN_ERR NAND Support is Not Yet Available on 3500\n);
- return -1;
- }
+ static const char *part_probe_types[] =
+ { cmdlinepart, ofpart, NULL };
+ const u32 *reg;
+ int reglen;
+ u64 nand_address;
+ unsigned long nand_length;
+ u64 gpreg_address;
+ unsigned long gpreg_length;
+ const u32 *enabled;
+ unsigned long cr;
+ unsigned long cr_save;
memset(ppdata, 0, sizeof(ppdata));
@@ -3485,74 +3482,92 @@ lsi_nand_init(void)
while (np !of_device_is_compatible(np, acp-nand))
np = of_find_node_by_type(np, nand);
- if (np) {
- const u32 *reg;
- int reglen;
- u64 nand_address;
- unsigned long nand_length;
- u64 gpreg_address;
- unsigned long gpreg_length;
- const u32 *enabled;
+ if (NULL == np) {
+ printk(KERN_ERR No NAND Nodes in Device Tree\n);
- enabled = of_get_property(np, enabled, NULL);
+ return -1;
+ }
- if (!enabled || (enabled (0 == *enabled))) {
- printk(KERN_INFO ACP NAND Controller Isn't
Enabled.\n);
- return -ENODEV;
- }
+ enabled = of_get_property(np, enabled, NULL);
- reg = of_get_property(np, reg, reglen);
-
- if (reg (16 == reglen)) {
- nand_address = of_translate_address(np, reg);
- nand_length = reg[1];
- reg += 2;
- gpreg_address = of_translate_address(np, reg);
- gpreg_length = reg[1];
- printk(KERN_INFO nand_address=0x%08llx
nand_length=0x%lx\n
- gpreg_address=0x%08llx gpreg_length=0x%lx\n,
-
Re: [linux-yocto] [PATCH 16/17] kernel/smp: Allow smp_call_function_single() to be called with a function that doesn't return.
On 14-07-08 10:22 AM, Charlie Paul wrote:
From: John Jacques john.jacq...@lsi.com
When we do a reset (core, not chip or system), the core that is doing the reset
has to
tell all the other cores to reset. To do this, we call
smp_call_function_single().
In this case the function specified in smp_call_function_single() doesn't
return.
The wait parameter (third argument, described as '@wait: If true, wait until
function has completed on other CPUs.') doesn't work as described without the
patch.
We need more explanation here. Why doesn't it work ? Deadlock ?
Something else ?
Signen-off-by: John Jacques john.jacq...@lsi.com
---
kernel/smp.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/kernel/smp.c b/kernel/smp.c
index d5f3238..040b2b1 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -17,14 +17,14 @@
static struct {
struct list_headqueue;
raw_spinlock_t lock;
-} call_function __cacheline_aligned_in_smp =
- {
+} call_function __cacheline_aligned_in_smp = {
Cosmetic change.
.queue = LIST_HEAD_INIT(call_function.queue),
.lock = __RAW_SPIN_LOCK_UNLOCKED(call_function.lock),
};
enum {
CSD_FLAG_LOCK = 0x01,
+ CSD_FLAG_NOWAIT = 0x02,
};
struct call_function_data {
@@ -268,6 +268,8 @@ void generic_smp_call_function_single_interrupt(void)
while (!list_empty(list)) {
struct call_single_data *data;
+ void (*func)(void *);
+ void *info;
data = list_entry(list.next, struct call_single_data, list);
list_del(data-list);
@@ -278,12 +280,21 @@ void generic_smp_call_function_single_interrupt(void)
* so save them away before making the call:
*/
data_flags = data-flags;
-
- data-func(data-info);
+ func = data-func;
+ info = data-info;
Why create these local variables ? func is only used once, and
info in that very same call. Hardly worth modifying the original
code for the change. Keeping the patch footprint small is a
virtue.
/*
+* Unlock before calling func so that func never has
+* to return.
+*
* Unlocked CSDs are valid through generic_exec_single():
*/
+ if ((data_flags CSD_FLAG_LOCK)
+ (data_flags CSD_FLAG_NOWAIT))
To confirm that this is not changing semantics, you now must be both
lock and no wait to unlock, but is no wait the default ? i.e. I
don't see how an existing caller that sets the lock flag, can be
guaranteed to also be 'no wait'.
+ csd_unlock(data);
+
+ func(info);
+
if (data_flags CSD_FLAG_LOCK)
csd_unlock(data);
}
@@ -337,6 +348,9 @@ int smp_call_function_single(int cpu, smp_call_func_t func,
void *info,
csd_lock(data);
+ if (!wait)
+ data-flags |= CSD_FLAG_NOWAIT;
+
data-func = func;
data-info = info;
generic_exec_single(cpu, data, wait);
@@ -672,7 +686,7 @@ EXPORT_SYMBOL(nr_cpu_ids);
/* An arch may set nr_cpu_ids earlier if needed, so this would be redundant */
void __init setup_nr_cpu_ids(void)
{
- nr_cpu_ids = find_last_bit(cpumask_bits(cpu_possible_mask),NR_CPUS) + 1;
+ nr_cpu_ids = find_last_bit(cpumask_bits(cpu_possible_mask), NR_CPUS) +
1;
Cosmetic change that should be dropped.
Bruce
}
/* Called by boot processor to activate the rest. */
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
