summaryrefslogtreecommitdiff
path: root/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb
Commit message (Collapse)AuthorAgeFilesLines
* linux-yocto: clean configuration for v3.0.4Bruce Ashfield2011-09-051-1/+1
| | | | | | | | | | | | Fixes [YOCTO #940] Since v3.0.4 is likely the last stable update in the the release timeframe a configuration audit was performed. This updates the SRCREV to remove obselete, and improperly defined configuration items. With this, all qemu* BSPs configure with no warnings. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto: update to v3.0.4Bruce Ashfield2011-09-051-3/+3
| | | | | | | | The v3.0.4 stable kernel is available and it can now be merged into linux-yocto. Build and boot tested on all qemu* machines. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto-rt: qemumips: fix boot panicBruce Ashfield2011-08-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Fixes [YOCTO #1392] Updating the SRCREVs to pickup: [ mips/rt: convert cascade interrupt non threaded The preempt_rt kernel forces all irq interrupts to be threaded, but special interrupts can be excluded from this conversion. The cascade interrupt should be part of these exceptions. In this case, irq2 is initialized before "kthreadd" task, which converts irq interrupt to threaded. If this irq is threaded, the kernel calls "try_to_wake_up" function to wake up "kthreadd" task, but at that moment, "kthreadd" task has no been initialize and try_to_wake_up wakes up a NULL task. Signed-off-by: Liming Wang <liming.wang@windriver.com> ] Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
* linux-yocto: update meta SRCREV to sync version stringsBruce Ashfield2011-08-251-2/+2
| | | | | | | | | | | During the update of the bitbake recipe's string to 3.0.3 the internal version marker in the kernel stayed at v3.0. This meant that kernel configuration auditing the constructed file couldn't be found and audit warnings were thrown. This syncs all the recipes and get back to clean configurations. Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-yocto-rt: update qemuppc support and streamline variablesBruce Ashfield2011-08-241-7/+4
| | | | | | | | | | | | | | | | | | Fixes [YOCTO #1391] Fixes [YOCTO #1389] qemuppc must have a dedicated branch for -rt support, since it has board specific patches that are not suitable for a common location. This fixes the boot by propagating some common fixes and by syncing to the latest meta-configuration. There are some variables that are now in linux-yocto.inc and need not be defined by the kernel recipe itself, so we can safely remove them with no impact on the build. CC: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Move meta-rt recipes to oe-core (meta)Darren Hart2011-08-121-0/+46
Keeping the rt recipes in their own layer has led to maintenance issues, particularly with the linux-yocto-rt recipes. As these kernel types are part of the same linux-yocto source repository, it seems reasonable to include the rt kernel recipes alongside the standard recipes. A new recipes-rt directory for the other recipes provides adequate separation and eliminates the need for a separate layer. As there is no meta-rt/conf/layer.conf to force the kernel, users must now specify the rt kernel in their local.conf or in the machine.conf: PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt" The merging of the rt recipes into the core also eliminates complications with multiple layer dependencies for new BSP layers. Having to either separate RT BSPs from standard BSPs or force users to add meta-rt to bblayers even when not building an RT BSP (because the RT BSPs in the same layer would fail to parse without it) was sub-optimal at best. Signed-off-by: Darren Hart <dvhart@linux.intel.com>