Re: new binutils needed for arm in 3.12-rc1
On 09/25/2013 10:52:44 AM, Måns Rullgård wrote: Rob Landley r...@landley.net writes: On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. Meaning I play whack-a-mole as this becomes permission to depend on endless new gnuisms just because they're there and nobody else is regression testing against them, not because they actually add anything. Since when is assembling the instructions correctly, as specified in the arch ref, and not in some other random way a gnuism? If you require current gnome and drop support for older versions (and implicitly all other desktops), people start writing stuff that depends on systemd. It doesn't matter if the feature you abandoned support for the past 10 years of everthing else for wasn't itself provided by systemd. Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
On 09/25/2013 11:13:17 AM, Nicolas Pitre wrote: On Wed, 25 Sep 2013, Rob Landley wrote: On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. Meaning I play whack-a-mole as this becomes permission to depend on endless new gnuisms just because they're there and nobody else is regression testing against them, not because they actually add anything. Gnuism? Let me quote the ARM ARchitecture Reference Manual, version 7 revision C, section A8.8.44 (sorry for the whitespace dammage): Globally changing the binutils requirement for all architectures, as the doc patch at the start of this thread proposed doing, would mean gnuisms in common code (ext2 and such) wouldn't get caught, giving llvm and pcc and such a moving target when trying to build the kernel with non-gnu toolchains. That's what I meant by gnuisms breeding. So what's the link with the above and your issue with GPLv3, besides the fact that the last binutils version to have been released under the GPLv2 is defficient? I apparently wasn't clear. The new instructions aren't gnuisms. The lack of widespread regression testing for armv5l and such would allow introduction of nonportable constructs in a larger context. (The fact that armv7 could apparently build fine for ~7 years with binutils 2.18 through 2.21, and now it's suddenly can't Because Reasons is kinda silly, but not really a big deal. That, I can patch my toolchain.) It could be as simple as making gas accept an extra argument for instructions like dsb and just ignoring it. So you prefer I come up with the reversion patches locally and _not_ send them upstream? Sort of. And I'm suggesting you patch your binutils rather than the kernel. I had this misidentified as a global arm problem and not specific to arm7l. If armv5l still still builds with the old toolchains, it's not a big deal. Given you're not upgrading your binutils anymore that means you'll have to apply that patch only once instead of having to apply it to every kernel upgrade. Indeed. Patching my own toolchain isn't really a problem. My objection was to the Documentation patch telling the world at large that for all targets, older binutils aren't supported even on x86. That was worth pushing back against. I don't indend to use old gcc/binutils versions forever, I just want to be able to use them until I can replace them with llvm or similar. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
On 09/25/2013 03:49:07 PM, Måns Rullgård wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: On Wed, Sep 25, 2013 at 10:23:06AM -0500, Rob Landley wrote: On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: It could be as simple as making gas accept an extra argument for instructions like dsb and just ignoring it. So you prefer I come up with the reversion patches locally and _not_ send them upstream? This is a silly attitude. What you're effectively saying is that we are never allowed to use any future ARM instructions in any Linux kernel because that might break your precious assembler. I've got news for you. We're *not* going to listen to that argument. END OF DISCUSSION (everything else is just a waste of time.) Who am I to argue with capital letters? I fully agree. Actually, I thought this was an armv5l regression. (My objection was to requiring a newer toolchain for architectures that built fine under the old one. My attention was attracted by the proposed patch to Documentation/changes with a global updated for required binutils version.) I've since had a chance to confirm the armv5 build break I saw was just normal mid-rc1 noise (since fixed) and this set of patches just applies to armv7, which already required a newer binutils, so objection withdrawn. Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote: On Tue, 24 Sep 2013, Rob Landley wrote: On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote: Now, if you feel strongly about this, we _could_ introduce a CONFIG_OLD_BINUTILS and give everyone their cake - but it will be fragile. Not everyone will remember to get that right, because they'll be using the later binutils. Also, we already have an excessive number of potential breakage-inducing options and we certainly don't need another. I'm doing the regression testing either way, on several different architectures. (Although I tend to to only really do a thorough job quarterly when a new kernel comes out and it's time to make it work.) So I'm going to be doing something locally like this anyway, and if a CONFIG_OLD_BINUTILS is acceptable I might as well push it upstream. If you are convinced you have no choice but to stick to old binutils, Oh no, long-term other choices include lld.llvm.org and http://landley.net/code/qcc but they're not ready yet and I don't have time to work on them right now. (I had high hopes for gold, until the guy signed it over to the FSF and it vanished into the tiergruben. Oh well.) I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. Meaning I play whack-a-mole as this becomes permission to depend on endless new gnuisms just because they're there and nobody else is regression testing against them, not because they actually add anything. Whereas if I add an old binutils config option, other people might help regression test it (if not actually fix it), and the other toolchain projects have less of a moving target to catch up to. This is more in line with being future proof rather than stuck into the past. No, it's exactly the opposite of that. Future proof is getting off a toolchain whose license is a moving target. GPLv2: shut up and show me the code GPLv3: I am altering the bargain, pray I don't alter it any further. GPLv4: ??? It could be as simple as making gas accept an extra argument for instructions like dsb and just ignoring it. So you prefer I come up with the reversion patches locally and _not_ send them upstream? *shrug* That's what I've been doing for sh4 for around 4 years now. (And their breakage still reverts cleanly even.) It's also what I did when the arm versatile interrupts changed randomly 3 times in ways that weren't backwards compatible with existing qemu versions. And I maintained perl removal patches for 5 years before they finally went upstream. But I do at least post said patches publicly, and other people use 'em when I do... Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
On 09/24/2013 07:11:38 AM, Måns Rullgård wrote: Rob Landley r...@landley.net writes: On 09/23/2013 06:59:17 PM, Pavel Machek wrote: During 3.12-rc, Will Deacon introduced code into arch/arm that requires binutils 2.22. Um, my toolchain is using the last gplv2 snapshot of binutils out of git, which is just past 2.17 and can build armv7 (but not armv8). Binutils 2.12-2.22 is quite the jump. (11 years.) I'd except some thought to have gone into that? Possibly a mention of it? I seriously doubt that 2.12 still works at all (I doubt it can even be built on a modern system). In my experience, binutils older than 2.19 or so rarely works properly for ARM. I've been building every kernel release with 2.17 for several years, on a bunch of different architectures. Toolchain releases after that are GPLv3* and I can't distribute those binaries, so I can't ship prebuilt binary toolchains. (Lots of other people produce cross compilers, but nobody else seems to produce prebuilt statically linked _native_ compilers. It would be nice if they did.) What value is there in maintaining compatibility with a truly ancient binutils version anyway? What value is there in requiring the new toolchain? From what I could see of the commits it was micro-optimizations around memory barriers. *shrug* I can revert the patch locally, or patch the extra instruction into my toolchain. But I do object to changing the documentation globally for every architecture because one architecture did something they apparently never thought through (or they'd have commented in the commit that it requires a big toolchain version jump; pretty sure they didn't actually notice). Rob * The Free Software Foundation got so pissed that MacOS X and BSD and such were sticking with the last GPLv2 release of binutils that they deleted the binutils tarball off their website and replaced it with one including GPLv3 source code. Check the FTP site if you don't believe me. Some of us have it snapshotted though. In my case, I actually fished the last GPLv2 version out of source control, right before the license change was committed, because I wanted armv7 support.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote: On Tue, Sep 24, 2013 at 04:23:48PM -0500, Rob Landley wrote: What value is there in requiring the new toolchain? From what I could see of the commits it was micro-optimizations around memory barriers. *shrug* I can revert the patch locally, or patch the extra instruction into my toolchain. But I do object to changing the documentation globally for every architecture because one architecture did something they apparently never thought through (or they'd have commented in the commit that it requires a big toolchain version jump; pretty sure they didn't actually notice). Some of us are notoriously slow at updating our toolchains. ... Some of us can't ship GPLv3 binaries and are looking forward to the day LLVM or some such provides a complete solution. Now, if you feel strongly about this, we _could_ introduce a CONFIG_OLD_BINUTILS and give everyone their cake - but it will be fragile. Not everyone will remember to get that right, because they'll be using the later binutils. Also, we already have an excessive number of potential breakage-inducing options and we certainly don't need another. I'm doing the regression testing either way, on several different architectures. (Although I tend to to only really do a thorough job quarterly when a new kernel comes out and it's time to make it work.) So I'm going to be doing something locally like this anyway, and if a CONFIG_OLD_BINUTILS is acceptable I might as well push it upstream. My use case is running all these targets under qemu, so it's not exactly performance-critical. :) Use IS_ENABLED() I hear you say. That won't get the one dsb instruction in some SoC code which was missed which will break the build on older toolchains. My regression test is my http://landley.net/aboriginal/about.html project, where I: 1) build cross compilers for ~15 different architecture variants (maybe half unique, the rest variants of the others). 2) Use them to build the smallest native development environment capable of reproducing itself from soruce code. 3) Boot it under qemu. 4) Build linux from scratch under the result. I've sometimes had it the whole mess automated from a cron job, but the server I had it on blew out its hard drive controller and I haven't bothered to set it up again... Next couple days are crazy but I'll try to get you a patch this weekend. Thanks, Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
On 09/23/2013 06:59:17 PM, Pavel Machek wrote: During 3.12-rc, Will Deacon introduced code into arch/arm that requires binutils 2.22. Um, my toolchain is using the last gplv2 snapshot of binutils out of git, which is just past 2.17 and can build armv7 (but not armv8). Binutils 2.12-2.22 is quite the jump. (11 years.) I'd except some thought to have gone into that? Possibly a mention of it? diff --git a/Documentation/Changes b/Documentation/Changes index b175808..0f8deaf 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -23,7 +23,7 @@ you probably needn't concern yourself with isdn4k-utils. o Gnu C 3.2 # gcc --version o Gnu make 3.80# make --version -o binutils 2.12# ld -v +o binutils 2.22# ld -v When the sh4 platform did this, I just reverted the patch. (It still reverts cleanly ~4 years later, and builds with my old tool versions...) Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
On 09/23/2013 06:59:17 PM, Pavel Machek wrote: During 3.12-rc, Will Deacon introduced code into arch/arm that requires binutils 2.22. I'm sorry, it occurs to me I should have been more explicit: HH! KILL IT WITH FIRE!!! Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
On 02/19/2013 09:05:00 AM, Felipe Balbi wrote: Greg, can you pitch your suggestion here ? It would be great to hear your rationale behind dropping class infrastructure, couldn't find anything through Google and since feature-removal-schedule.txt has been removed (without adding it to feature-removal-schedule.txt, I must add :-) I don't know what's the idea behind removing classes. I actually went through and poked a couple of people about old entries in feature-removal-shedule.txt last year, but I haven't been very active since the kernel.org breakin because my account got disabled, and I needed to meet kernel developers in person to get keys signed to get it switched back on (or set up a separate git tree with signed commits -next could pull from). I don't get out much; as a consultant I have to take time off from work and pay for my own travel and lodging. So I've been to exactly two conferences in the past 3 years: last year's Texas Linux Fest (my house got broken into and a netbook with the key on it stolen the following wednesday), and CELF (which I'm on the plane back from now, Greg KH signed my key! Woo!). If I can use that to get my account back, set up a tree feeding into linux-next, and maybe even recover the ability to update http://kernel.org/doc, I'd happily field some sort of feature-removal-schedule list and make sure it stays current. (Linus didn't ask me about removing the old one, I found out about it from the git log. But I can't blame him, I haven't exactly been tearing through the bureaucracy to get my access back. Volunteer work and painful tend not to combine well on my todo list in terms of scheduling priority...) Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] drivers: phy: add generic PHY framework
On 02/18/2013 11:53:14 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. Given that this has a separately selectable config option, I'm guessing that it's useful all by itself even in the absence of a driver using this phy? (Or it gives user visibility to the phy buried in an E1000 or SATA drive or some such?) +1. Introduction + +*PHY* is the abbreviation for physical layer. It is used to connect a device +to the physical medium e.g., the USB controller has a PHY to provide functions +such as serialization, de-serialization, encoding, decoding and is responsible +for obtaining the required data transmission rate. Note that some USB +controller has PHY functionality embedded into it and others use an external +PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet, +SATA etc. I've usually heard the word transciever used to describe these. +The intention of creating this framework is to bring the phy drivers spread +all over the Linux kernel to drivers/phy to increase code re-use and to +increase code maintainability. + +This framework will be of use only to devices that uses external PHY (PHY +functionality is not embedded within the controller). + +2. Creating the PHY + +The PHY driver should create the PHY in order for other peripheral controllers +to make use of it. The PHY framework provides 2 APIs to create the PHY. Given that a PHY is a chip (random example http://ark.intel.com/products/47620/Intel-82579LM-Gigabit-Ethernet-PHY), you seem to be saying that software should manifest a piece of hardware out of thin air through sheer willpower. I'm pretty sure I've misunderstood this phrasing. +struct phy *phy_create(struct device *dev, struct phy_descriptor *desc); +struct phy *devm_phy_create(struct device *dev, struct phy_descriptor *desc); + +The PHY drivers can use one of the above 2 APIs to create the PHY by passing Um, the driver should _bind_ to the phy, maybe? Allocate? Initialize? +6. Destroying the PHY I've run drivers like that. I try not to, though. +7. Current Status + +Currently only USB in OMAP is made to use this framework. However using the +USB PHY library cannot be completely removed because it is intertwined with +OTG. Once we move OTG out of PHY completely, using the old PHY library can be +completely removed. SATA in OMAP will also more likely use this new framework +and we should have a patch for it soon. Does this paragraph belong in the documentation? (Git commit, sure, but I've seen a lot of stale paragraphs like these hang around a surprisingly long time.) Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] OF: Introduce DT overlay support.
On 01/04/2013 01:31:10 PM, Pantelis Antoniou wrote:
Introduce DT overlay support.
Using this functionality it is possible to dynamically overlay a part
of
the kernel's tree with another tree that's been dynamically loaded.
It is also possible to remove node and properties.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Just commenting on the documentation a bit...
---
Documentation/devicetree/overlay-notes.txt | 179 +++
drivers/of/Kconfig | 10 +
drivers/of/Makefile| 1 +
drivers/of/overlay.c | 831
+
include/linux/of.h | 107
5 files changed, 1128 insertions(+)
create mode 100644 Documentation/devicetree/overlay-notes.txt
create mode 100644 drivers/of/overlay.c
diff --git a/Documentation/devicetree/overlay-notes.txt
b/Documentation/devicetree/overlay-notes.txt
new file mode 100644
index 000..5289cbb
--- /dev/null
+++ b/Documentation/devicetree/overlay-notes.txt
@@ -0,0 +1,179 @@
+Device Tree Overlay Notes
+-
+
+This document describes the implementation of the in-kernel
+device tree overlay functionality residing in drivers/of/overlay.c
and is a
+companion document to
Documentation/devicetree/dt-object-internal.txt[1]
+Documentation/devicetree/dynamic-resolution-notes.txt[2]
+
+How overlays work
+-
+
+A Device Tree's overlay purpose is to modify the kernel's live tree,
and
+have the modification affecting the state of the the kernel in a way
that
+is reflecting the changes.
My wild guess here is this has something to do with hotplug support,
but I don't know if modules are expected to do this or if userspace
does it and modules respond... Could you give a couple sentences about
the purpose and potential users of this mechanism in the summary?
+Since the kernel mainly deals with devices, any new device node that
result
results
+in an active device should have it created while if the device node
is either
+disabled or removed all together, the affected device should be
deregistered.
I'm not following this bit. It looks like some test is missing between
while if?
+Lets take an example where we have a foo board with the following
base tree
+which is taken from [1].
+
+ foo.dts
-
+ /* FOO platform */
+ / {
+ compatible = corp,foo;
+
+ /* shared resources */
+ res: res {
+ };
+
+ /* On chip peripherals */
+ ocp: ocp {
+ /* peripherals that are always instantiated */
+ peripheral1 { ... };
+ }
+ };
+ foo.dts
-
+
+The overlay bar.dts, when loaded (and resolved as described in [2])
should
+
+ bar.dts
-
+/plugin/; /* allow undefined label references and record them */
+/ {
+ /* various properties for loader use; i.e. part id etc.
*/
+ fragment@0 {
+ target = ocp;
+ __overlay__ {
+ /* bar peripheral */
+ bar {
+ compatible = corp,bar;
+... /* various properties and child
nodes */
+ }
+ };
+ };
+};
+ bar.dts
-
+
+result in foo+bar.dts
+
+ foo+bar.dts
-
+ /* FOO platform + bar peripheral */
+ / {
+ compatible = corp,foo;
+
+ /* shared resources */
+ res: res {
+ };
+
+ /* On chip peripherals */
+ ocp: ocp {
+ /* peripherals that are always instantiated */
+ peripheral1 { ... };
+
+ /* bar peripheral */
+ bar {
+ compatible = corp,bar;
+... /* various properties and child
nodes */
+ }
+ }
+ };
+ foo+bar.dts
-
+
+As a result of the the overlay, a new device node (bar) has been
created
+so a bar platform device will be registered and if a matching device
driver
+is loaded the device will be created as expected.
Is this done by a module, or does doing this then trigger a hotplug
event that requests a module? (Or is this a syntax allowing a
bootloader to collate multiple device tree segments and then Linux
links them when parsing the device tree...?)
+Overlay in-kernel API
+-
+
+The steps typically required to get an overlay to work are as
Re: [PATCH 0/6] Introducing Device Tree Overlays
On 01/05/2013 03:35:58 AM, Richard Cochran wrote: On Sat, Jan 05, 2013 at 12:16:51AM -0600, Joel A Fernandes wrote: The problem being addressed is discussed in this thread: http://permalink.gmane.org/gmane.linux.kernel/1389017 Thanks for the link. Since the motivation is already documented in that post, why not add it into Documentation/devicetree/overlay-notes.txt as well? Seconded. Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 11/09/2012 10:28:59 AM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/05/2012 01:40 PM, Grant Likely wrote: I'm not actually opposed to it, but it needs to be done in an elegant way. The DT data model already imposes more of a conceptual learning curve than I wish it did and I don't want to make that worse with a versioning model that is difficult to get ones head around. Speaking of which... I want to poke at board emulation in qemu, from scratch. Specifically, I want to start with an unpopulated board (just the processor), add a block of physical memory and a serial device, and boot an initramfs in there with stdin/stdout. Then I want to incrementally add an RTC, network card, and three block devices. I'd like to define this board by giving qemu and the kernel the same device tree they can parse, and I'd like to _build_ this device tree so I understand what's in it. I'd like to repeat this exercize for arm, mips, ppc, x86, x86-64, sparc, sh4, and maybe other boards. And I'd like to write up an article on doing it as a learning exercise. Last time I checked, doing this wasn't possible. (qemu couldn't define a board by parsing a device tree, the kernel used the device tree as a guideline but it only really read data the drivers you linked in were expecting, the only documentation about what any of the nodes were was was read the other device trees as examples or read the source code of the drivers looking for data in the tree...) Is it a more realistic project now? If so, where would I start? (Once upon a time I read the booting-without-of document, back when it lived in the ppc directory. It didn't really say what should go in any of the nodes.) Rob-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [CFT 11/11] Add feature removal of old OMAP private DMA implementation
On 06/07/2012 06:09 AM, Russell King wrote: Acked-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- Documentation/feature-removal-schedule.txt | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 56000b3..1f7ba35 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -612,3 +612,14 @@ When:June 2013 Why: Unsupported/unmaintained/unused since 2.6 + +What:OMAP private DMA implementation +When:2013 +Why: We have a DMA engine implementation; all users should be updated + to use this rather than persisting with the old APIs. The old APIs + block merging the old DMA engine implementation into the DMA + engine driver. +Who: Russell King li...@arm.linux.org.uk, + Santosh Shilimkar santosh.shilim...@ti.com + + Whose tree do feature-removal-schedule patches go in through? (They're not really documentation, they're design coordination/logistics.) Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's mere aggregation, or a license violation. Pick one. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Monday 12 July 2010 18:18:01 Linus Torvalds wrote: 2010/7/12 David Brown dav...@codeaurora.org: Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Uwe posted it earlier in this thread as an attachement, and I put the python script into the merge commit message too. And we should probably put it somewhere in scripts too, and/or make a 'make' target to create the small config files. I pushed it all out, and tagged it as -rc5. FYI, I repeatedly submitted a bash script to do this back in 2005, with documentation and makefile changes to call it and so on. http://lwn.net/Articles/161086/ The current version of that script is is in my mercurial archive here: http://impactlinux.com/hg/hgwebdir.cgi/aboriginal/file/tip/sources/toys/miniconfig.sh I'm still using it in my Aboriginal Linux project. (Not just for the kernel, but for busybox and uClibc too.) Attached are miniconfigs I use for a dozen or so QEMU targets. (The project is trying to build kernels aimed at every qemu system emulation. I've got maybe 2/3 of them so far. Arm, mips, sh4, x86, x86_64, sparc...) They're used to create the system-image tarballs here: http://impactlinux.com/aboriginal/downloads/binaries/ You can download that for that target that interests you, extract it, and use run-emulator.sh to launch it under qemu. I have a cron job that does cross- platform regression testing, spitting /dev/console to a log file on the host. By the way, my build is generating those miniconfigs via a common baseconfig file to which I append the target-specific stuff. For example, my current baseconfig is: CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y Then for mips I append: CONFIG_MIPS_MALTA=y CONFIG_CPU_MIPS32_R2=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y #CONFIG_PM=y CONFIG_PCNET32=y CONFIG_BLK_DEV_PIIX=y Or for x86_64 it's: CONFIG_ACPI=y CONFIG_BLK_DEV_PIIX=y CONFIG_NETDEV_1000=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y And for armv4tl it's this big long saga (yes, with comments): # Processor config # QEMU patch: http://www.mail-archive.com/qemu-de...@nongnu.org/msg19370.html # and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the # processor that actually _needs_ this code. But until then, qemu can only # emulate an armv5 CPU... CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_VFP=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y Rob -- GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem Forever, and as welcome as New Coke. CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_MAGIC_SYSRQ=y CONFIG_CPU_ARM926T=y CONFIG_MMU=y CONFIG_ARCH_VERSATILE_PB=y CONFIG_MACH_VERSATILE_AB=y CONFIG_CPU_ARM926T=y CONFIG_ARM_THUMB=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y
