Re: [PATCH 1/2] qemu platform, v2
On Thursday 18 October 2007 12:29:08 pm Grant Likely wrote: On 10/18/07, Milton Miller [EMAIL PROTECTED] wrote: If we say only some boards or ports are special and need to build then I would vote for shipping asm files. If we think we need to build any random embedded platform without installing dtc then we should merge dtc. I don't think we do. It's looking like there are going to be out of tree users of dtc also (The are some patches floating around for u-boot to use the device tree for it's own initialization). I don't think it's unreasonable to install dtc for embedded development. There are out of tree users of yacc and lex, but the kernel has *.c_shipped files so as not to require that external tool of people who simply want to build the sucker without modifying it. make oldconfig was modified not to require curses. How about *.S_shipped files? I like the idea of shipping asm files to support the qemu target; at least until qemu gets better firmware. I've now gotten qemu to boot a kernel I built, using Milton's 1/2 patch and a a self-contained build of a 4k ppc_boot.rom (which includes the dtc source because I don't expect anybody else to have it installed, either). Description and links to source, binaries, and build scripts in this message: http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00415.html There's a problem with qemu-cvs (detailed in the message), but qemu-system-ppc 0.9.0 boots fine, up to a shell prompt. Cheers, g. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
Grant Likely wrote: On 9/30/07, David Gibson [EMAIL PROTECTED] wrote: On Fri, Sep 28, 2007 at 06:53:28PM +0200, Segher Boessenkool wrote: I'm working on merging dtc into the kernel tree instead. I'm kind of late to this party; but I have to say I disagree. Most of us are doing just fine installing the dtc tool (and mkimage tool for that matter). Cloning it in the kernel tree is just asking for divergence. Which begs the question; why cloning? Why can't development be MOVED to in-kernel? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
On Oct 18, 2007, at 4:59 AM, Matt Sealey wrote: Grant Likely wrote: On 9/30/07, David Gibson [EMAIL PROTECTED] wrote: On Fri, Sep 28, 2007 at 06:53:28PM +0200, Segher Boessenkool wrote: I'm working on merging dtc into the kernel tree instead. I'm kind of late to this party; but I have to say I disagree. Most of us are doing just fine installing the dtc tool (and mkimage tool for that matter). Cloning it in the kernel tree is just asking for divergence. Which begs the question; why cloning? Why can't development be MOVED to in-kernel? Because we don't put userspace testsuites there for one. And its a stand alone tool and should have its own packaging for a second (ie the kernel provides the kernel and modules, but not random user space utilities, in its tarbal). If we say only some boards or ports are special and need to build then I would vote for shipping asm files. If we think we need to build any random embedded platform without installing dtc then we should merge dtc. PS the proposed kbuild integration is wrong; it should build it in the subdirectory. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
On 10/18/07, Milton Miller [EMAIL PROTECTED] wrote: On Oct 18, 2007, at 4:59 AM, Matt Sealey wrote: Which begs the question; why cloning? Why can't development be MOVED to in-kernel? Because we don't put userspace testsuites there for one. And its a stand alone tool and should have its own packaging for a second (ie the kernel provides the kernel and modules, but not random user space utilities, in its tarbal). If we say only some boards or ports are special and need to build then I would vote for shipping asm files. If we think we need to build any random embedded platform without installing dtc then we should merge dtc. I don't think we do. It's looking like there are going to be out of tree users of dtc also (The are some patches floating around for u-boot to use the device tree for it's own initialization). I don't think it's unreasonable to install dtc for embedded development. I like the idea of shipping asm files to support the qemu target; at least until qemu gets better firmware. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
On 9/30/07, David Gibson [EMAIL PROTECTED] wrote: On Fri, Sep 28, 2007 at 06:53:28PM +0200, Segher Boessenkool wrote: I'd be following this more closely if compiling a device tree didn't currently require an external utility (dtc or some such) that doesn't come with the Linux kernel. No other target platform I've built kernels for requires such an environmental dependency. No? You haven't built kernels for other platforms that have external dependencies such as perl, gcc, make, binutils, etc.? :) Two of the supported Linux archs cannot be built with a mainline compiler, even! And I have to install GNU sed/awk to get builds to work, too. OTOH, it would be nice if we didn't need DTC -- it itself doesn't build out-of-the-box on all systems, either ;-) (This is a problem both for hardwiring the device tree into the kernel and for building a new boot rom from the linux kernel's ppc boot wrapper that would contain such a device tree to feed to the kernel.) It's only really been a problem for ps3 so far, since the embedded guys don't seem to have any difficulty with installing dtc. We are looking at what to do for ps3 and prep, and the answer may well involve bundling dtc in the kernel source (it's not too big, around 3400 lines). If only a few platforms have this problem, we could instead include their .dtb files in the kernel source tree. Including .dtbs in the kernel tree has a big practical problem: they're binary, so can't be patch(1)ed, which makes updating them a complete PITA. I'm working on merging dtc into the kernel tree instead. I'm kind of late to this party; but I have to say I disagree. Most of us are doing just fine installing the dtc tool (and mkimage tool for that matter). Cloning it in the kernel tree is just asking for divergence. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
On Wednesday 17 October 2007 3:28:41 pm Grant Likely wrote: Including .dtbs in the kernel tree has a big practical problem: they're binary, so can't be patch(1)ed, which makes updating them a complete PITA. I note that kconfig includes the lex/yacc output files (blah.c_shipped) so you don't have to have lex and yacc installed to run menuconfig. It _also_ includes the lex/yacc source which is what you patch and rebuild the _shipped files from when they need to be changed. I'm working on merging dtc into the kernel tree instead. I'm kind of late to this party; but I have to say I disagree. Most of us are doing just fine installing the dtc tool (and mkimage tool for that matter). Cloning it in the kernel tree is just asking for divergence. Milton Miller has some patches that make a PPC qemu target kernel image which doesn't include a device tree, and generates a rom image to boot qemu with which contains a device tree and hands it off to the Linux kernel. If qemu can merge that rom image in its BIOS collection, this approach would meet my immediate needs. Cheers, g. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
I'd be following this more closely if compiling a device tree didn't currently require an external utility (dtc or some such) that doesn't come with the Linux kernel. No other target platform I've built kernels for requires such an environmental dependency. No? You haven't built kernels for other platforms that have external dependencies such as perl, gcc, make, binutils, etc.? :) Two of the supported Linux archs cannot be built with a mainline compiler, even! And I have to install GNU sed/awk to get builds to work, too. OTOH, it would be nice if we didn't need DTC -- it itself doesn't build out-of-the-box on all systems, either ;-) (This is a problem both for hardwiring the device tree into the kernel and for building a new boot rom from the linux kernel's ppc boot wrapper that would contain such a device tree to feed to the kernel.) It's only really been a problem for ps3 so far, since the embedded guys don't seem to have any difficulty with installing dtc. We are looking at what to do for ps3 and prep, and the answer may well involve bundling dtc in the kernel source (it's not too big, around 3400 lines). If only a few platforms have this problem, we could instead include their .dtb files in the kernel source tree. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
On Friday 28 September 2007 11:53:28 am Segher Boessenkool wrote: I'd be following this more closely if compiling a device tree didn't currently require an external utility (dtc or some such) that doesn't come with the Linux kernel. No other target platform I've built kernels for requires such an environmental dependency. No? You haven't built kernels for other platforms that have external dependencies such as perl, gcc, make, binutils, etc.? :) Two of the supported Linux archs cannot be built with a mainline compiler, even! Strange definition of supported... And I have to install GNU sed/awk to get builds to work, too. I extended busybox sed until it built everything I threw at it. (I even added a lie to autoconf step that replies to --version to say This is not gnu sed 4.0 so a regex in autoconf doesn't do something stupid.) That's how I got into busybox development in the first place... OTOH, it would be nice if we didn't need DTC -- it itself doesn't build out-of-the-box on all systems, either ;-) I've built x86, x86-64, mips, arm, and sparc. None of them needed anything but the seven packages I mentioned. I'm poking at adding m68k, alpha, bfin, and powerpc, but my free time's been spoken for recently. (I'll become interested in sh or parisc when qemu grows support for it. I'm only interested in bfin because I was given some free blackfin hardware at OLS.) I've even poked at running s390 under Hercules but the setup was insane enough to throw it way the heck down on my todo list. (Step 1: download and configure an IBM operating system image from the 1970's... Oh yeah, fills me with enthusiasm...) (This is a problem both for hardwiring the device tree into the kernel and for building a new boot rom from the linux kernel's ppc boot wrapper that would contain such a device tree to feed to the kernel.) It's only really been a problem for ps3 so far, since the embedded guys don't seem to have any difficulty with installing dtc. We are looking at what to do for ps3 and prep, and the answer may well involve bundling dtc in the kernel source (it's not too big, around 3400 lines). If only a few platforms have this problem, we could instead include their .dtb files in the kernel source tree. I've had it clarified that the recent qemu-ppc patches from Milton only require dtc to build the ROM image to boot qemu with. The Linux kernel image you build hasn't got a device tree in it (although that means it needs one passed in from the rom image)... Using some other patches that floated by, I did build a prep kernel a couple of weeks ago, which qemu happily handed control off to... which then failed to boot because it couldn't parse the incomplete residual data left over from open hackware. The solution the ppc list recommended? Hardwire a device tree into said linux kernel using dtc... Segher Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
On Sep 24, 2007, at 2:46 AM, Christoph Hellwig wrote: On Mon, Sep 24, 2007 at 02:00:47PM +1000, David Gibson wrote: Basically because PReP support doesn't work under arch/powerpc. Getting it working properly is something that should happen, but will take a while. In the meantime, getting something that's sufficient to get working under just qemu's version of prep, without using the abominable openhackware is a quicker path to a usable arch/powerpc kernel under qemu. Sounds fair. Care to add something like this to the Kconfig help text? I suppose I could, but actually I wasn't asking for the two qemu patches to be merged. Instead I was posting here's something that provides minimal function for me, hope you can use it too. For instance, someone should track down pci memory so that ohci and/or video works. Then test the isa ne2ks, or better yet get qemu to change them to pci (except then it only works on the latest qemu). I didn't put it under prep because it could be changed for the other qemu platforms and doesn't use any thing that makes the machine prep other than some memory map information. I kept prep because I didn't want to deal with io to the scc on bw G3, the other long-term platform (or with hackware to see if that would just boot as pmac). milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
On Sat, Sep 22, 2007 at 11:55:46AM +0200, Christoph Hellwig wrote: On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote: Here is the second rev of patches to boot a arch powerpc kernel on qemu with the prep architecture. So if this is supposed to be prep why do you need additional kernel support? And if you really needed why isn't it under platforms/prep? Basically because PReP support doesn't work under arch/powerpc. Getting it working properly is something that should happen, but will take a while. In the meantime, getting something that's sufficient to get working under just qemu's version of prep, without using the abominable openhackware is a quicker path to a usable arch/powerpc kernel under qemu. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote: Here is the second rev of patches to boot a arch powerpc kernel on qemu with the prep architecture. So if this is supposed to be prep why do you need additional kernel support? And if you really needed why isn't it under platforms/prep? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
On Saturday 22 September 2007 4:55:46 am Christoph Hellwig wrote: On Fri, Sep 21, 2007 at 06:08:31PM -0500, Milton Miller wrote: Here is the second rev of patches to boot a arch powerpc kernel on qemu with the prep architecture. So if this is supposed to be prep why do you need additional kernel support? And if you really needed why isn't it under platforms/prep? The device tree provided by qemu's open hackware violates some of the assumptions the Linux kernel is making? (Although things like the cpu cache size is zero are, technically speaking, probably correct. :) There are three different problems here: 1) porting prep from arch=ppc to arch=powerpc so you can build it on an arch that also supports make headers_install. 2) PowerPC uses a device tree supplied by the hardware to identify the available hardware, even for stuff living on PCI busses which it could theoretically probe for but doesn't. 3) The PPC firmware qemu comes with (Open Hackware) sucks rocks, is hard to modify, isn't quite being maintained. As mentioned above, the device tree it passes in (including prep residual data from which more nodes in the device tree can be constructed, and here my understanding goes all fuzzy) does not make for a happy Linux kernel. Proposed solutions to all this involve various combinations of creating a target platform aimed directly at qemu and not pretending to be prep at all (so it doesn't have to parse residual data), creating our own boot rom image out of some of the wrapper code the linux kernel's already got and feeding that to qemu instead of using open hackware at all, hard wiring a device tree into the kernel and not looking at the one open hackware passes in...) I'd be following this more closely if compiling a device tree didn't currently require an external utility (dtc or some such) that doesn't come with the Linux kernel. No other target platform I've built kernels for requires such an environmental dependency. (This is a problem both for hardwiring the device tree into the kernel and for building a new boot rom from the linux kernel's ppc boot wrapper that would contain such a device tree to feed to the kernel.) Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] qemu platform, v2
Rob Landley writes: Just to correct a few misconceptions: 2) PowerPC uses a device tree supplied by the hardware to identify the available hardware, even for stuff living on PCI busses which it could theoretically probe for but doesn't. The device tree doesn't have to include anything that can be probed for. On some platforms (e.g. pSeries) we choose to use the device tree rather than probing, but on most other platforms we probe. I'd be following this more closely if compiling a device tree didn't currently require an external utility (dtc or some such) that doesn't come with the Linux kernel. No other target platform I've built kernels for requires such an environmental dependency. No? You haven't built kernels for other platforms that have external dependencies such as perl, gcc, make, binutils, etc.? :) (This is a problem both for hardwiring the device tree into the kernel and for building a new boot rom from the linux kernel's ppc boot wrapper that would contain such a device tree to feed to the kernel.) It's only really been a problem for ps3 so far, since the embedded guys don't seem to have any difficulty with installing dtc. We are looking at what to do for ps3 and prep, and the answer may well involve bundling dtc in the kernel source (it's not too big, around 3400 lines). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] qemu platform, v2
Here is the second rev of patches to boot a arch powerpc kernel on
qemu with the prep architecture.
The goal is to provide an environment for use with the existing qemu
hardware suppplied hardware, as oposed to changing the qemu
machine description.
This patch contains only the kernel portion. While the diff was
generated against for-2.6.24, this first patch applies cleanly
to 2.6.23-rc7. With the rom image created in the next patch,
a kernel built by this patch should boot when using qemu -kernel.
I debated putting this in the embedded6xx tree, especially when I
discovered that the bridge is suposedly a '105, but saw no advantage
in the end.
pci config space is now working, however cirrusfb causes crashes
and ohci times out, so at least pci memory is likely still broken.
ide and serial work, floppy and parallel are untested.
I added a defconfig based on chrp32; hardware options still need
tweaking (eg isa ne2k).
Index: kernel/arch/powerpc/platforms/Kconfig
===
--- kernel.orig/arch/powerpc/platforms/Kconfig 2007-09-19 02:32:54.0
-0500
+++ kernel/arch/powerpc/platforms/Kconfig 2007-09-19 02:41:00.0
-0500
@@ -47,6 +47,7 @@ source arch/powerpc/platforms/chrp/Kcon
source arch/powerpc/platforms/52xx/Kconfig
source arch/powerpc/platforms/powermac/Kconfig
source arch/powerpc/platforms/prep/Kconfig
+source arch/powerpc/platforms/qemu/Kconfig
source arch/powerpc/platforms/maple/Kconfig
source arch/powerpc/platforms/pasemi/Kconfig
source arch/powerpc/platforms/celleb/Kconfig
Index: kernel/arch/powerpc/platforms/qemu/Kconfig
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ kernel/arch/powerpc/platforms/qemu/Kconfig 2007-09-20 14:12:57.0
-0500
@@ -0,0 +1,10 @@
+config PPC_QEMU
+ bool QEMU emulated PowerPC Reference Platform (PReP) system
+ depends on PPC_MULTIPLATFORM PPC32
+ select PPC_I8259
+ select PPC_INDIRECT_PCI
+ select PPC_UDBG_16550
+ select PPC_NATIVE
+ select WANT_DEVICE_TREE
+ default n
+
Index: kernel/arch/powerpc/platforms/qemu/Makefile
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ kernel/arch/powerpc/platforms/qemu/Makefile 2007-09-19 02:41:00.0
-0500
@@ -0,0 +1,2 @@
+obj-y += setup.o
+obj-$(CONFIG_PCI) += pci.o
Index: kernel/arch/powerpc/platforms/qemu/pci.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ kernel/arch/powerpc/platforms/qemu/pci.c2007-09-19 02:56:36.0
-0500
@@ -0,0 +1,133 @@
+/*
+ * prep Port to arch/powerpc:
+ * Copyright 2007 David Gibson, IBM Corporation.
+ *
+ * prep Port to qemu:
+ * Copyright 2007 Milton Miller, IBM Corporation.
+ *
+ * Based on OpenHackware 0.4
+ * Copyright (c) 2004-2005 Jocelyn Mayer
+ *
+ * pci config based on arch/powerpc/platforms/chrp/pci.c GoldenGate code
+ *
+ */
+
+#include linux/init.h
+
+#include asm/io.h
+#include asm/prom.h
+#include asm/pci-bridge.h
+#include asm/udbg.h
+
+static volatile void __iomem *qemu_config_addr(struct pci_bus *bus,
+ unsigned int devfn, int off)
+{
+ int dev, fn;
+ struct pci_controller *hose = bus-sysdata;
+
+ if (!hose-cfg_data)
+ return NULL;
+
+ if (bus-number != 0)
+ return NULL;
+
+ dev = devfn 3;
+ fn = devfn 7;
+
+ if (dev 11 || dev 21)
+ return NULL;
+
+ return hose-cfg_data + ((1 dev) | (fn 8) | off);
+}
+
+int qemu_read_config(struct pci_bus *bus, unsigned int devfn, int off,
+ int len, u32 *val)
+{
+ volatile void __iomem *cfg_data = qemu_config_addr(bus, devfn, off);
+
+ if (cfg_data == NULL)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ /*
+* Note: the caller has already checked that off is
+* suitably aligned and that len is 1, 2 or 4.
+*/
+ switch (len) {
+ case 1:
+ *val = in_8(cfg_data);
+ break;
+ case 2:
+ *val = in_le16(cfg_data);
+ break;
+ default:
+ *val = in_le32(cfg_data);
+ break;
+ }
+ return PCIBIOS_SUCCESSFUL;
+}
+
+int qemu_write_config(struct pci_bus *bus, unsigned int devfn, int off,
+ int len, u32 val)
+{
+ volatile void __iomem *cfg_data = qemu_config_addr(bus, devfn, off);
+
+ if (cfg_data == NULL)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+
+ /*
+* Note: the caller has already checked that off is
+* suitably aligned and that len is 1, 2 or 4.
+*/
+ switch (len) {
+ case 1:
+ out_8(cfg_data, val);
+ break;
+ case 2:
+ out_le16(cfg_data,
