Bug#703209: linux: Please Add multiplatform flavour to armhf
OK, I will do that.
Best regards,
Nobuhiro
2013/5/7 Ben Hutchings b...@decadent.org.uk:
I've updated the trunk branch in svn for Linux 3.9, so please go ahead
with this.
Ben.
--
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CABMQnVJdLBwair-S6-K2Eh4dt2ng1nZ08Lp3EXpqAdEz_uh7=w...@mail.gmail.com
Bug#703209: linux: Please Add multiplatform flavour to armhf
I've updated the trunk branch in svn for Linux 3.9, so please go ahead with this. Ben. -- Ben Hutchings If God had intended Man to program, we'd have been born with serial I/O ports. signature.asc Description: This is a digitally signed message part
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Mon, Apr 8, 2013 at 9:41 PM, Hector Oron hector.o...@gmail.com wrote:
Hello,
2013/4/2 Nobuhiro Iwamatsu iwama...@nigauri.org:
Then, the two candidates have come armmp and armv7.
Which do you like?
if there is no other opinions, I would want to decide on armmp.
armmp ++
Thanks!
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CABMQnVL4b3EV1GbOGoW4cYx0GO9qh6qmsyFy=5fvekg762w...@mail.gmail.com
Bug#703209: linux: Please Add multiplatform flavour to armhf
Hello, 2013/4/2 Nobuhiro Iwamatsu iwama...@nigauri.org: Then, the two candidates have come armmp and armv7. Which do you like? if there is no other opinions, I would want to decide on armmp. armmp ++ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAODfWeG=OvuBFUFt=szBfKAB1a2AM+=ruvob8tjzr-jati4...@mail.gmail.com
Bug#703209: linux: Please Add multiplatform flavour to armhf
Hi, all.
Now, we are trying to determine the MP flavor of ARM in Debian.
Then, the two candidates have come armmp and armv7.
Which do you like?
if there is no other opinions, I would want to decide on armmp.
Best,
Nobuhiro
On Thu, Mar 21, 2013 at 10:55 PM, Lennart Sorensen
lsore...@csclub.uwaterloo.ca wrote:
On Thu, Mar 21, 2013 at 08:42:49AM +, Tixy wrote:
A single multiplatform kernel can support both armv6 and armv7 (or armv4
+ armv5). I don't know if Debian plans to have separate versions for
each architecture version - there may be performance benefits to this -
in which case using armv6 -v7 etc sounds like a good idea. Also, a
multiplatform kernel can't support armv5 and armv6, so there may need to
be more than one 'mp' version anyway.
Well armhf only supports armv7 so far, so armv6 adn armv5 are irrelevant to
armhf.
armel would be a different question. I do wonder how long armel will
continue to be maintained if most of the arm developers get too excited
with armhf. :)
--
Len Sorensen
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CABMQnV+5rw7ZV=k+P8zLYeWSSjB1k_xPegNf=t1caph3zyw...@mail.gmail.com
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Thu, 2013-03-21 at 12:52 +0900, Nobuhiro Iwamatsu wrote: Hi, On Wed, Mar 20, 2013 at 12:17 AM, Paul Wise p...@debian.org wrote: On Tue, 2013-03-19 at 15:05 +, Ian Campbell wrote: I think the question here is what the `uname -r` bit should be. Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR. Woops, I missed that uname -r includes the flavour bit. I think there is an argument for making the multiplatform case be the default no-flavour flavour i.e. $FLAVOUR is armhf/arm64 etc. Or maybe that's what you are suggesting having not realised that `uname -r` currently includes the -$FLAVOUR suffix. Hrm, I think we may actually be talking about the same thing ;-) Right, my suggestion is just to use the architecture for the flavour, as is done on the other architectures. Thank you for your comment. In ARM ((but may be used on other architectures as well) ) all architectures, flavor with the name of the CPU do is that it is multiplatform? For example, armv7 flavor is multiplatform support in armhf. A single multiplatform kernel can support both armv6 and armv7 (or armv4 + armv5). I don't know if Debian plans to have separate versions for each architecture version - there may be performance benefits to this - in which case using armv6 -v7 etc sounds like a good idea. Also, a multiplatform kernel can't support armv5 and armv6, so there may need to be more than one 'mp' version anyway. -- Tixy -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1363855369.3242.5.ca...@computer5.home
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Thu, Mar 21, 2013 at 08:42:49AM +, Tixy wrote: A single multiplatform kernel can support both armv6 and armv7 (or armv4 + armv5). I don't know if Debian plans to have separate versions for each architecture version - there may be performance benefits to this - in which case using armv6 -v7 etc sounds like a good idea. Also, a multiplatform kernel can't support armv5 and armv6, so there may need to be more than one 'mp' version anyway. Well armhf only supports armv7 so far, so armv6 adn armv5 are irrelevant to armhf. armel would be a different question. I do wonder how long armel will continue to be maintained if most of the arm developers get too excited with armhf. :) -- Len Sorensen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130321135535.gk1...@csclub.uwaterloo.ca
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, Mar 19, 2013 at 5:34 PM, Ian Campbell i...@hellion.org.uk wrote:
On Tue, 2013-03-19 at 08:44 +0100, Arnaud Patard wrote:
I already commented some days ago on debian-arm that currently
multiplatform support must wait. It is useless as usb support is
_broken_ on multiplatform. Hopefully, Linaro devs seem back to work
and looks like we may have a patch merged soon. Until then, doing more
is near to a waste of time.
I don't think making a start on a MP flavour is a waste of time at all.
We are talking about packages in trunk (currently == experimental)
rather than Sid/Wheezy. There's no possibility of us releasing anything
with 3.8 but in the meantime adding the multiplatform flavour allows us
to start laying the packaging ground work, finding bugs in the MP stuff
and generally kicking the tyres etc. It's also an obvious step in the
right direction. As you say the known issues, like the USB think, will
be fixed upstream sooner rather than later.
Since we are currently not yet talking about removing existing flavours
I'm not sure there are any downsides to just doing it.
And about the patch in this bug, it fails to be really
multiplatform. During my tests on 3.8, I could already enable platforms
like MVEBU, HIGHBANK, BCM, MXC and you can enable OMAP too with 2-3
backports. Once done, it needs to be tested on real platforms as it
would probably allow to detect some more bugs. 3.9 may be better.
This patch is a start though and doesn't preclude adding those other
platforms either straight away or when 3.9 comes around as we like.
Having the flavour would also enable testing on real platforms so that
isn't a reason to wait IMHO.
Thank you for following this up.
I want to explain to me what you wrote.
On the long term, we'll have also to consider if we should keep
omap/mx5/vexpress or not. If we remove them, we should make sure that
the transition will work nicely.
Ack.
me too.
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CABMQnV+aUqJd5esxD9Tc95k86nd_Udnjn+=odogkcykbl_g...@mail.gmail.com
Bug#703209: linux: Please Add multiplatform flavour to armhf
Hi,
On Wed, Mar 20, 2013 at 12:17 AM, Paul Wise p...@debian.org wrote:
On Tue, 2013-03-19 at 15:05 +, Ian Campbell wrote:
I think the question here is what the `uname -r` bit should be.
Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR.
Woops, I missed that uname -r includes the flavour bit.
I think there is an argument for making the multiplatform case be the
default no-flavour flavour i.e. $FLAVOUR is armhf/arm64 etc. Or
maybe that's what you are suggesting having not realised that `uname
-r` currently includes the -$FLAVOUR suffix. Hrm, I think we may
actually be talking about the same thing ;-)
Right, my suggestion is just to use the architecture for the flavour, as
is done on the other architectures.
Thank you for your comment.
In ARM ((but may be used on other architectures as well) ) all architectures,
flavor with the name of the CPU do is that it is multiplatform?
For example, armv7 flavor is multiplatform support in armhf.
I think this is a very simple rule.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CABMQnVL=uen73eqdld9ts2_5ef5n_6cks2ngmsbfoedptwk...@mail.gmail.com
Bug#703209: linux: Please Add multiplatform flavour to armhf
Ben Hutchings b...@decadent.org.uk writes: Hi, On Mon, 2013-03-18 at 08:41 +0900, Nobuhiro Iwamatsu wrote: Hi, Thank you for your comment. On Sun, Mar 17, 2013 at 10:23 AM, Ben Hutchings b...@decadent.org.uk wrote: On Sun, 2013-03-17 at 08:35 +0900, Nobuhiro Iwamatsu wrote: Package: linux Version: 3.8.2-1~experimental.1 Severity: wishlist Tags: patch Hi, From linux 3.8, support of armada 370/xp was added in arm. This is classified into the armhf architecture of debian. First I began and thought that an armada flavor would be added. When I consulted about this in debian-arm ML, I got advice from several developers what multiplatform flavour was better than armada flavour[0]. Since arm is developed toward multiplatform from now on, I think that multiplatform is desirable. Although there is still little SoC which is supporting multiplatform, I would like to support armada 370/xp (mach-mvebu) first. I created the patch which supports this. Please check and apply. In future all ARM kernels should be multi-platform, but I expect there will still be different flavours, such as for LPAE or the RT featureset. I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. I see. Although it is very simple, how is armmp? armmp is imho confusing. There are some Marvell platforms called MMP. [...] Sounds alright to be, but let's allow the other ARM porters a few more days to comment. I already commented some days ago on debian-arm that currently multiplatform support must wait. It is useless as usb support is _broken_ on multiplatform. Hopefully, Linaro devs seem back to work and looks like we may have a patch merged soon. Until then, doing more is near to a waste of time. And about the patch in this bug, it fails to be really multiplatform. During my tests on 3.8, I could already enable platforms like MVEBU, HIGHBANK, BCM, MXC and you can enable OMAP too with 2-3 backports. Once done, it needs to be tested on real platforms as it would probably allow to detect some more bugs. 3.9 may be better. On the long term, we'll have also to consider if we should keep omap/mx5/vexpress or not. If we remove them, we should make sure that the transition will work nicely. Arnaud -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjxzbzqm@lebrac.rtp-net.org
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Sun, Mar 17, 2013 at 9:23 AM, Ben Hutchings wrote: I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. How about the same scheme as on other arches? linux-image-`uname -r`-armel linux-image-`uname -r`-armhf linux-image-`uname -r`-arm64 Or maybe the CPU is better: linux-image-`uname -r`-armv4 linux-image-`uname -r`-armv7 linux-image-`uname -r`-armv8 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6gbw+qkddwj_sefrmumjue3xm9utybf4oddjzzjiaj...@mail.gmail.com
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, 2013-03-19 at 03:46 +, Ben Hutchings wrote: On Mon, 2013-03-18 at 08:41 +0900, Nobuhiro Iwamatsu wrote: On Sun, Mar 17, 2013 at 10:23 AM, Ben Hutchings b...@decadent.org.uk wrote: [...] In future all ARM kernels should be multi-platform, but I expect there will still be different flavours, such as for LPAE or the RT featureset. I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. I see. Although it is very simple, how is armmp? [...] Sounds alright to be, but let's allow the other ARM porters a few more days to comment. 'MP' has some history as meaning multi-processor, so might be confusing. (But perhaps not confusing to many.) -- Tixy -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1363680223.3247.8.ca...@computer5.home
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, 2013-03-19 at 08:44 +0100, Arnaud Patard wrote: I already commented some days ago on debian-arm that currently multiplatform support must wait. It is useless as usb support is _broken_ on multiplatform. Hopefully, Linaro devs seem back to work and looks like we may have a patch merged soon. Until then, doing more is near to a waste of time. I don't think making a start on a MP flavour is a waste of time at all. We are talking about packages in trunk (currently == experimental) rather than Sid/Wheezy. There's no possibility of us releasing anything with 3.8 but in the meantime adding the multiplatform flavour allows us to start laying the packaging ground work, finding bugs in the MP stuff and generally kicking the tyres etc. It's also an obvious step in the right direction. As you say the known issues, like the USB think, will be fixed upstream sooner rather than later. Since we are currently not yet talking about removing existing flavours I'm not sure there are any downsides to just doing it. And about the patch in this bug, it fails to be really multiplatform. During my tests on 3.8, I could already enable platforms like MVEBU, HIGHBANK, BCM, MXC and you can enable OMAP too with 2-3 backports. Once done, it needs to be tested on real platforms as it would probably allow to detect some more bugs. 3.9 may be better. This patch is a start though and doesn't preclude adding those other platforms either straight away or when 3.9 comes around as we like. Having the flavour would also enable testing on real platforms so that isn't a reason to wait IMHO. On the long term, we'll have also to consider if we should keep omap/mx5/vexpress or not. If we remove them, we should make sure that the transition will work nicely. Ack. Ian. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1363682093.2891.9.ca...@dagon.hellion.org.uk
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, 2013-03-19 at 08:03 +, Tixy wrote: On Tue, 2013-03-19 at 03:46 +, Ben Hutchings wrote: On Mon, 2013-03-18 at 08:41 +0900, Nobuhiro Iwamatsu wrote: On Sun, Mar 17, 2013 at 10:23 AM, Ben Hutchings b...@decadent.org.uk wrote: [...] In future all ARM kernels should be multi-platform, but I expect there will still be different flavours, such as for LPAE or the RT featureset. I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. I see. Although it is very simple, how is armmp? [...] Sounds alright to be, but let's allow the other ARM porters a few more days to comment. 'MP' has some history as meaning multi-processor, so might be confusing. (But perhaps not confusing to many.) All multi-platform configurations will have to be multi-processor as well, so that shouldn't matter too much. Ben. -- Ben Hutchings When you say `I wrote a program that crashed Windows', people just stare ... and say `Hey, I got those with the system, *for free*'. - Linus Torvalds signature.asc Description: This is a digitally signed message part
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, 2013-03-19 at 16:13 +0800, Paul Wise wrote: On Sun, Mar 17, 2013 at 9:23 AM, Ben Hutchings wrote: I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. How about the same scheme as on other arches? linux-image-`uname -r`-armel I think the question here is what the `uname -r` bit should be. Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR. I think there is an argument for making the multiplatform case be the default no-flavour flavour i.e. $FLAVOUR is armhf/arm64 etc. Or maybe that's what you are suggesting having not realised that `uname -r` currently includes the -$FLAVOUR suffix. Hrm, I think we may actually be talking about the same thing ;-) linux-image-`uname -r`-armhf linux-image-`uname -r`-arm64 Or maybe the CPU is better: linux-image-`uname -r`-armv4 linux-image-`uname -r`-armv7 linux-image-`uname -r`-armv8 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1363705537.2891.41.ca...@dagon.hellion.org.uk
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Tue, 2013-03-19 at 15:05 +, Ian Campbell wrote: I think the question here is what the `uname -r` bit should be. Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR. Woops, I missed that uname -r includes the flavour bit. I think there is an argument for making the multiplatform case be the default no-flavour flavour i.e. $FLAVOUR is armhf/arm64 etc. Or maybe that's what you are suggesting having not realised that `uname -r` currently includes the -$FLAVOUR suffix. Hrm, I think we may actually be talking about the same thing ;-) Right, my suggestion is just to use the architecture for the flavour, as is done on the other architectures. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Mon, 2013-03-18 at 08:41 +0900, Nobuhiro Iwamatsu wrote: Hi, Thank you for your comment. On Sun, Mar 17, 2013 at 10:23 AM, Ben Hutchings b...@decadent.org.uk wrote: On Sun, 2013-03-17 at 08:35 +0900, Nobuhiro Iwamatsu wrote: Package: linux Version: 3.8.2-1~experimental.1 Severity: wishlist Tags: patch Hi, From linux 3.8, support of armada 370/xp was added in arm. This is classified into the armhf architecture of debian. First I began and thought that an armada flavor would be added. When I consulted about this in debian-arm ML, I got advice from several developers what multiplatform flavour was better than armada flavour[0]. Since arm is developed toward multiplatform from now on, I think that multiplatform is desirable. Although there is still little SoC which is supporting multiplatform, I would like to support armada 370/xp (mach-mvebu) first. I created the patch which supports this. Please check and apply. In future all ARM kernels should be multi-platform, but I expect there will still be different flavours, such as for LPAE or the RT featureset. I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. I see. Although it is very simple, how is armmp? [...] Sounds alright to be, but let's allow the other ARM porters a few more days to comment. Ben. -- Ben Hutchings When you say `I wrote a program that crashed Windows', people just stare ... and say `Hey, I got those with the system, *for free*'. - Linus Torvalds signature.asc Description: This is a digitally signed message part
Bug#703209: linux: Please Add multiplatform flavour to armhf
Hi,
Thank you for your comment.
On Sun, Mar 17, 2013 at 10:23 AM, Ben Hutchings b...@decadent.org.uk wrote:
On Sun, 2013-03-17 at 08:35 +0900, Nobuhiro Iwamatsu wrote:
Package: linux
Version: 3.8.2-1~experimental.1
Severity: wishlist
Tags: patch
Hi,
From linux 3.8, support of armada 370/xp was added in arm.
This is classified into the armhf architecture of debian.
First I began and thought that an armada flavor would be added.
When I consulted about this in debian-arm ML, I got advice from
several developers what multiplatform flavour was better than
armada flavour[0].
Since arm is developed toward multiplatform from now on,
I think that multiplatform is desirable.
Although there is still little SoC which is supporting
multiplatform, I would like to support armada 370/xp
(mach-mvebu) first.
I created the patch which supports this.
Please check and apply.
In future all ARM kernels should be multi-platform, but I expect there
will still be different flavours, such as for LPAE or the RT featureset.
I would much prefer a name that will provide a more useful distinction
in future (and not be too long!). Perhaps it should refer to the CPU
requirement like the flavours for some other architectures.
I see. Although it is very simple, how is armmp?
NOTE: The vexpress can also be supported by multiplatform.
If it is desirable to include this in multiplatform, I will
create a new patch.
I think that's desirable, but maybe make that a second patch?
The linux-latest package will also need a transitional package to
migrate vexpress installations.
I see. I forgot about this.
I will create new patch.
From: Nobuhiro Iwamatsu iwama...@debian.org
Date: Mon, 4 Mar 2013 13:20:13 +0900
Subject: [PATCH] [armhf] Add multiplatform flavour
Signed-off-by: Nobuhiro Iwamatsu iwama...@debian.org
---
debian/config/armhf/config.multiplatform | 96
++
debian/config/armhf/defines | 11
debian/installer/armhf/kernel-versions |7 ++-
3 files changed, 111 insertions(+), 3 deletions(-)
create mode 100644 debian/config/armhf/config.multiplatform
diff --git a/debian/config/armhf/config.multiplatform
b/debian/config/armhf/config.multiplatform
new file mode 100644
index 000..cb4ad57
--- /dev/null
+++ b/debian/config/armhf/config.multiplatform
[...]
+##
+## file: drivers/net/ethernet/marvell/Kconfig
+##
+CONFIG_NET_VENDOR_MARVELL=y
+CONFIG_MVMDIO=y
+CONFIG_MVNETA=y
+
+##
+## file: drivers/net/ethernet/micrel/Kconfig
+##
+CONFIG_NET_VENDOR_MICREL=y
+
+##
+## file: drivers/net/phy/Kconfig
+##
+CONFIG_PHYLIB=y
+CONFIG_MARVELL_PHY=y
[...]
Do these all need to be built in? For a multi-platform kernel we should
really be building drivers as modules by default.
These can set to module/
I update a patch.
Ben.
--
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
- Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CABMQnV+QaxMxYb8rMoNCcTP_c=ebqj5jkksutguj7junak7...@mail.gmail.com
Bug#703209: linux: Please Add multiplatform flavour to armhf
Package: linux Version: 3.8.2-1~experimental.1 Severity: wishlist Tags: patch Hi, From linux 3.8, support of armada 370/xp was added in arm. This is classified into the armhf architecture of debian. First I began and thought that an armada flavor would be added. When I consulted about this in debian-arm ML, I got advice from several developers what multiplatform flavour was better than armada flavour[0]. Since arm is developed toward multiplatform from now on, I think that multiplatform is desirable. Although there is still little SoC which is supporting multiplatform, I would like to support armada 370/xp (mach-mvebu) first. I created the patch which supports this. Please check and apply. NOTE: The vexpress can also be supported by multiplatform. If it is desirable to include this in multiplatform, I will create a new patch. Best regards, Nobuhiro [0]: https://lists.debian.org/debian-arm/2013/03/msg00044.html -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash 0001-armhf-Add-multiplatform-flavour.patch Description: Binary data
Bug#703209: linux: Please Add multiplatform flavour to armhf
On Sun, 2013-03-17 at 08:35 +0900, Nobuhiro Iwamatsu wrote: Package: linux Version: 3.8.2-1~experimental.1 Severity: wishlist Tags: patch Hi, From linux 3.8, support of armada 370/xp was added in arm. This is classified into the armhf architecture of debian. First I began and thought that an armada flavor would be added. When I consulted about this in debian-arm ML, I got advice from several developers what multiplatform flavour was better than armada flavour[0]. Since arm is developed toward multiplatform from now on, I think that multiplatform is desirable. Although there is still little SoC which is supporting multiplatform, I would like to support armada 370/xp (mach-mvebu) first. I created the patch which supports this. Please check and apply. In future all ARM kernels should be multi-platform, but I expect there will still be different flavours, such as for LPAE or the RT featureset. I would much prefer a name that will provide a more useful distinction in future (and not be too long!). Perhaps it should refer to the CPU requirement like the flavours for some other architectures. NOTE: The vexpress can also be supported by multiplatform. If it is desirable to include this in multiplatform, I will create a new patch. I think that's desirable, but maybe make that a second patch? The linux-latest package will also need a transitional package to migrate vexpress installations. From: Nobuhiro Iwamatsu iwama...@debian.org Date: Mon, 4 Mar 2013 13:20:13 +0900 Subject: [PATCH] [armhf] Add multiplatform flavour Signed-off-by: Nobuhiro Iwamatsu iwama...@debian.org --- debian/config/armhf/config.multiplatform | 96 ++ debian/config/armhf/defines | 11 debian/installer/armhf/kernel-versions |7 ++- 3 files changed, 111 insertions(+), 3 deletions(-) create mode 100644 debian/config/armhf/config.multiplatform diff --git a/debian/config/armhf/config.multiplatform b/debian/config/armhf/config.multiplatform new file mode 100644 index 000..cb4ad57 --- /dev/null +++ b/debian/config/armhf/config.multiplatform [...] +## +## file: drivers/net/ethernet/marvell/Kconfig +## +CONFIG_NET_VENDOR_MARVELL=y +CONFIG_MVMDIO=y +CONFIG_MVNETA=y + +## +## file: drivers/net/ethernet/micrel/Kconfig +## +CONFIG_NET_VENDOR_MICREL=y + +## +## file: drivers/net/phy/Kconfig +## +CONFIG_PHYLIB=y +CONFIG_MARVELL_PHY=y [...] Do these all need to be built in? For a multi-platform kernel we should really be building drivers as modules by default. Ben. -- Ben Hutchings Usenet is essentially a HUGE group of people passing notes in class. - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette' signature.asc Description: This is a digitally signed message part
