I just made available a new Linaro kernel merge result at the following location:
http://git.linaro.org/?p=linux/arm_next.git%3Ba=summary
The process we're experimenting at the moment for the production of this kernel is described on this page:
https://wiki.ubuntu.com/Specs/M/ARMKernelVersionAlignment
This is the merge result from the following branches:
Linus' v2.6.35-rc5 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Ubuntu Maverick at commit 78e9e778 git://kernel.ubuntu.com/ubuntu/ubuntu-maverick.git
RMK's devel branch at commit 3712d8e6 http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm.git
Catalin Marinas' "rebased" branch at commit 3a9a55c7 git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-2.6-cm.git
Will Deacon's "for-linaro" branch at commit 6741018f git://repo.or.cz/linux-2.6/linux-wd.git
Uwe Kleine-König's "arm/booting" branch at commit e69edc79 git://git.pengutronix.de/git/ukl/linux-2.6.git (this also contains patches from Eric Miao for automatic ZRELADDR)
The security branch was dropped as it has been merged into RMK's devel branch at this point.
This has been tagged with "linaro_merge_100712" and the tag message also has the above info. This is also available through the following gitweb link:
http://git.linaro.org/gitweb?p=linux/arm_next.git%3Ba=tag%3Bh=linaro_merge_1...
The previous merge result is still available through the tag "linaro_merge_100616" for reference.
Please contact me if you have any issue with this tree. Positive feedback is also fine! ;-)
Nicolas
On Tuesday 13 July 2010, Nicolas Pitre wrote:
I just made available a new Linaro kernel merge result at the following location:
http://git.linaro.org/?p=linux/arm_next.git;a=summary
Very nice!
Please contact me if you have any issue with this tree. Positive feedback is also fine! ;-)
I'm wondering if we can split the merged ARM kernel tree from the Ubuntu patches. I'm not normally building ubuntu packages when trying out kernels, and a lot of the stuff in the ubuntu tree is not heading for mainline inclusion any time soon.
Obviously we need the ubuntu+linaro tree as well, especially to build the packages, but I'm personally more interested in the linaro (minus ubuntu) patches that are headed upstream.
Arnd
On Tue, Jul 13, 2010, Arnd Bergmann wrote:
I'm wondering if we can split the merged ARM kernel tree from the Ubuntu patches. I'm not normally building ubuntu packages when trying out kernels, and a lot of the stuff in the ubuntu tree is not heading for mainline inclusion any time soon.
Obviously we need the ubuntu+linaro tree as well, especially to build the packages, but I'm personally more interested in the linaro (minus ubuntu) patches that are headed upstream.
I'm +1 on this; it's something which has bugged me for a while.
We need a version of the tree with the Ubuntu stuff merged, as to prepare Ubuntu packages, but our official main arm_next doesn't need to carry the non-upstream Ubuntu bits. (Carrying the Ubuntu bits which are going upstream soon is useful though.)
It's an extra burden, but we want arm_next.git to be upstreamish. I think John Rigby and Nicolas should see how to best handle the Ubuntu bits, but our tree should look like an official upstream linux tree with additional good stuff and sugar on top. :-)
On Tue, 13 Jul 2010, Loïc Minier wrote:
On Tue, Jul 13, 2010, Arnd Bergmann wrote:
I'm wondering if we can split the merged ARM kernel tree from the Ubuntu patches. I'm not normally building ubuntu packages when trying out kernels, and a lot of the stuff in the ubuntu tree is not heading for mainline inclusion any time soon.
Obviously we need the ubuntu+linaro tree as well, especially to build the packages, but I'm personally more interested in the linaro (minus ubuntu) patches that are headed upstream.
I'm +1 on this; it's something which has bugged me for a while.
OK, I have no problem with that. I don't know the Ubuntu kernel tree well myself. I initially thought about merging it as it could contain generic features that the Linaro kernel could benefit from. But I don't know exactly what those are. And I also wanted to shake out any merge issues in the perspective of having the Linaro tree merged back into the Ubuntu kernel tree at some point before a release. Maybe it is best to keep the Ubuntu kernel free from the Linaro stuff after all. In either cases I don't have a strong opinion.
We need a version of the tree with the Ubuntu stuff merged, as to prepare Ubuntu packages, but our official main arm_next doesn't need to carry the non-upstream Ubuntu bits. (Carrying the Ubuntu bits which are going upstream soon is useful though.)
They would need to be in a separate branch in the Maverick repository.
It's an extra burden, but we want arm_next.git to be upstreamish. I think John Rigby and Nicolas should see how to best handle the Ubuntu bits, but our tree should look like an official upstream linux tree with additional good stuff and sugar on top. :-)
OK. I'll kick out the Maverick branch from the next rebuild.
Nicolas
On Tue, Jul 13, 2010, Nicolas Pitre wrote:
OK, I have no problem with that. I don't know the Ubuntu kernel tree well myself. I initially thought about merging it as it could contain generic features that the Linaro kernel could benefit from. But I don't know exactly what those are. And I also wanted to shake out any merge issues in the perspective of having the Linaro tree merged back into the Ubuntu kernel tree at some point before a release. Maybe it is best to keep the Ubuntu kernel free from the Linaro stuff after all. In either cases I don't have a strong opinion.
I don't think we actually want to keep the Ubuntu kernel free from the Linaro stuff, but I think we want to keep the Linaro tree free from the Ubuntu patches. Ubuntu takes integrates kernel trees like we do, and we could integrate the patches in the Ubuntu tree which are going upstream if that's useful to Linaro folks, but since things in the Ubuntu tree are NOT going upstream like e.g. aufs, we can't pull it wholesale in our main tree.
It would however make sense to merge with Ubuntu in another tree aimed at Ubuntu's consumption, or at building Ubuntu-alike images. I also think we should offer our Linaro changes to Ubuntu ARM topic trees if they will take them. Let's go over this at the sprint.
We need a version of the tree with the Ubuntu stuff merged, as to prepare Ubuntu packages, but our official main arm_next doesn't need to carry the non-upstream Ubuntu bits. (Carrying the Ubuntu bits which are going upstream soon is useful though.)
They would need to be in a separate branch in the Maverick repository.
Exactly; e.g. linaro-arm branch or linaro branch in ubuntu/ubuntu-maverick.git.
OK. I'll kick out the Maverick branch from the next rebuild.
Thanks
Two things: 1) leaving the Ubuntu stuff out is fine with me. 2) What config works with this. I have only tried building with Ubuntu configs which I had to update. I just took the default for the new stuff. With that I get weird errors in some scsi driver. Looks like I just need to turn it off for arm:
/home/jcrigby/work/git-trees/kernelbuild/linux/drivers/scsi/ips.c:210: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" CC [M] drivers/scsi/megaraid.o CC [M] drivers/scsi/initio.o CC [M] drivers/scsi/a100u2w.o CC [M] drivers/scsi/3w-xxxx.o CC [M] drivers/scsi/3w-9xxx.o CC [M] drivers/scsi/3w-sas.o CC [M] drivers/scsi/libsrp.o /home/jcrigby/work/git-trees/kernelbuild/linux/drivers/scsi/3w-9xxx.c: In function 'twa_interrupt': /home/jcrigby/work/git-trees/kernelbuild/linux/drivers/scsi/3w-9xxx.c:1246: error: expected expression before 'do' /home/jcrigby/work/git-trees/kernelbuild/linux/drivers/scsi/3w-9xxx.c:1253: error: expected expression before 'do' /home/jcrigby/work/git-trees/kernelbuild/linux/drivers/scsi/3w-9xxx
John
On Tue, Jul 13, 2010 at 12:29 PM, Nicolas Pitre nicolas.pitre@canonical.com wrote:
On Tue, 13 Jul 2010, Loïc Minier wrote:
On Tue, Jul 13, 2010, Arnd Bergmann wrote:
I'm wondering if we can split the merged ARM kernel tree from the Ubuntu patches. I'm not normally building ubuntu packages when trying out kernels, and a lot of the stuff in the ubuntu tree is not heading for mainline inclusion any time soon.
Obviously we need the ubuntu+linaro tree as well, especially to build the packages, but I'm personally more interested in the linaro (minus ubuntu) patches that are headed upstream.
I'm +1 on this; it's something which has bugged me for a while.
OK, I have no problem with that. I don't know the Ubuntu kernel tree well myself. I initially thought about merging it as it could contain generic features that the Linaro kernel could benefit from. But I don't know exactly what those are. And I also wanted to shake out any merge issues in the perspective of having the Linaro tree merged back into the Ubuntu kernel tree at some point before a release. Maybe it is best to keep the Ubuntu kernel free from the Linaro stuff after all. In either cases I don't have a strong opinion.
We need a version of the tree with the Ubuntu stuff merged, as to prepare Ubuntu packages, but our official main arm_next doesn't need to carry the non-upstream Ubuntu bits. (Carrying the Ubuntu bits which are going upstream soon is useful though.)
They would need to be in a separate branch in the Maverick repository.
It's an extra burden, but we want arm_next.git to be upstreamish. I think John Rigby and Nicolas should see how to best handle the Ubuntu bits, but our tree should look like an official upstream linux tree with additional good stuff and sugar on top. :-)
OK. I'll kick out the Maverick branch from the next rebuild.
Nicolas _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, 13 Jul 2010, John Rigby wrote:
Two things:
- leaving the Ubuntu stuff out is fine with me.
- What config works with this. I have only tried building with
Ubuntu configs which I had to update. I just took the default for the new stuff. With that I get weird errors in some scsi driver. Looks like I just need to turn it off for arm:
Many options used on X86 are effectively useless on ARM. Many ARM targets even don't have PCI.
Nicolas
Here is an update. First, I am still getting errors of the form:
/home/jcrigby/work/git-trees/kernelbuild/linux/drivers/mtd/onenand/onenand_sim.c:142: error: expected expression before 'do'
The 'do' here is from arch/arm/include/asm/io.h: #define writew(v,c) do { wmb(); writew_relaxed(v,c); } while (0)
That looks ok until you find out how it is used in drivers/mtd/onenand/onenand_sim.c:
#define ONENAND_SET_WP_STATUS(v, this) \ (writew(v, this->base + ONENAND_REG_WP_STATUS))
The parens around it make the valid statement into an invalid expression.
Second, on omap I was getting errors in arch/arm/plat-omap/gpio.c:
/home/jcrigby/work/git-trees/kernelbuild/linux/arch/arm/plat-omap/gpio.c: In function 'gpio_irq_type': /home/jcrigby/work/git-trees/kernelbuild/linux/arch/arm/plat-omap/gpio.c:906: error: 'irq_desc' undeclared (first use in this function)
I got around this problem by turning off sparse irq's.
Thanks John
On Tue, Jul 13, 2010 at 7:51 PM, Nicolas Pitre nicolas.pitre@canonical.com wrote:
On Tue, 13 Jul 2010, John Rigby wrote:
Two things:
- leaving the Ubuntu stuff out is fine with me.
- What config works with this. I have only tried building with
Ubuntu configs which I had to update. I just took the default for the new stuff. With that I get weird errors in some scsi driver. Looks like I just need to turn it off for arm:
Many options used on X86 are effectively useless on ARM. Many ARM targets even don't have PCI.
Nicolas
On Wed, Jul 14, 2010 at 2:05 PM, John Rigby john.rigby@linaro.org wrote:
Here is an update. First, I am still getting errors of the form:
/home/jcrigby/work/git-trees/kernelbuild/linux/drivers/mtd/onenand/onenand_sim.c:142: error: expected expression before 'do'
The 'do' here is from arch/arm/include/asm/io.h: #define writew(v,c) do { wmb(); writew_relaxed(v,c); } while (0)
That looks ok until you find out how it is used in drivers/mtd/onenand/onenand_sim.c:
#define ONENAND_SET_WP_STATUS(v, this) \ (writew(v, this->base + ONENAND_REG_WP_STATUS))
The parens around it make the valid statement into an invalid expression.
Second, on omap I was getting errors in arch/arm/plat-omap/gpio.c:
/home/jcrigby/work/git-trees/kernelbuild/linux/arch/arm/plat-omap/gpio.c: In function 'gpio_irq_type': /home/jcrigby/work/git-trees/kernelbuild/linux/arch/arm/plat-omap/gpio.c:906: error: 'irq_desc' undeclared (first use in this function)
I got around this problem by turning off sparse irq's.
Mm... I should have made SPARSE_IRQ default to 'n', and make sub-arch that supports this to select, instead of making it a visible option.
Thanks John
On Tue, Jul 13, 2010 at 7:51 PM, Nicolas Pitre nicolas.pitre@canonical.com wrote:
On Tue, 13 Jul 2010, John Rigby wrote:
Two things:
- leaving the Ubuntu stuff out is fine with me.
- What config works with this. I have only tried building with
Ubuntu configs which I had to update. I just took the default for the new stuff. With that I get weird errors in some scsi driver. Looks like I just need to turn it off for arm:
Many options used on X86 are effectively useless on ARM. Many ARM targets even don't have PCI.
Nicolas
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wed, 14 Jul 2010, Eric Miao wrote:
On Wed, Jul 14, 2010 at 2:05 PM, John Rigby john.rigby@linaro.org wrote:
Here is an update. First, I am still getting errors of the form:
/home/jcrigby/work/git-trees/kernelbuild/linux/drivers/mtd/onenand/onenand_sim.c:142: error: expected expression before 'do'
The 'do' here is from arch/arm/include/asm/io.h: #define writew(v,c) do { wmb(); writew_relaxed(v,c); } while (0)
That looks ok until you find out how it is used in drivers/mtd/onenand/onenand_sim.c:
#define ONENAND_SET_WP_STATUS(v, this) \ (writew(v, this->base + ONENAND_REG_WP_STATUS))
The parens around it make the valid statement into an invalid expression.
Second, on omap I was getting errors in arch/arm/plat-omap/gpio.c:
/home/jcrigby/work/git-trees/kernelbuild/linux/arch/arm/plat-omap/gpio.c: In function 'gpio_irq_type': /home/jcrigby/work/git-trees/kernelbuild/linux/arch/arm/plat-omap/gpio.c:906: error: 'irq_desc' undeclared (first use in this function)
I got around this problem by turning off sparse irq's.
Mm... I should have made SPARSE_IRQ default to 'n', and make sub-arch that supports this to select, instead of making it a visible option.
You may still send RMK an additional patch making that change. I don't think there is a real need to expose this config to users.
Nicolas
On Wed, 14 Jul 2010, John Rigby wrote:
Here is an update. First, I am still getting errors of the form:
/home/jcrigby/work/git-trees/kernelbuild/linux/drivers/mtd/onenand/onenand_sim.c:142: error: expected expression before 'do'
The 'do' here is from arch/arm/include/asm/io.h: #define writew(v,c) do { wmb(); writew_relaxed(v,c); } while (0)
That looks ok until you find out how it is used in drivers/mtd/onenand/onenand_sim.c:
#define ONENAND_SET_WP_STATUS(v, this) \ (writew(v, this->base + ONENAND_REG_WP_STATUS))
The parens around it make the valid statement into an invalid expression.
I know that Catalin faced a similar issue with another driver already resulting from his patch. I'll forward this to him so to have this issue resolved upstream as well.
Nicolas
On Wed, 2010-07-14 at 07:05 +0100, John Rigby wrote:
Here is an update. First, I am still getting errors of the form:
/home/jcrigby/work/git-trees/kernelbuild/linux/drivers/mtd/onenand/onenand_sim.c:142: error: expected expression before 'do'
The 'do' here is from arch/arm/include/asm/io.h: #define writew(v,c) do { wmb(); writew_relaxed(v,c); } while (0)
That looks ok until you find out how it is used in drivers/mtd/onenand/onenand_sim.c:
#define ONENAND_SET_WP_STATUS(v, this) \ (writew(v, this->base + ONENAND_REG_WP_STATUS))
The parens around it make the valid statement into an invalid expression.
This was discussed recently on the ARM Linux list. The conclusion was that using brackets around writew() is dangerous as it gives writew() a type and the compiler may generate code which forces a read back from the register being written. Using inline functions for writew() has some performance impact (it seems to add around 78K in size to the Linux kernel).
So we could change the driver above to remove the brackets but any other suggestion is welcome.
-
Arnd Bergmann -
Catalin Marinas -
Eric Miao -
John Rigby -
Loïc Minier -
Nicolas Pitre -
Nicolas Pitre