* question about linux with Xilinx ML-403
From: Ming Liu @ 2006-05-23 9:41 UTC (permalink / raw)
To: rick.moleres; +Cc: linuxppc-embedded
Hi Rick,
> Yes, we have a driver for the PLB TEMAC (different than the GSRD LL
> TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK
> 8.1.1, and MontaVista is on the verge of publishing a driver for PLB
> TEMAC for Linux 2.6. (I believe it came across this mailing list a few
> weeks ago)
I have generated the BSP by EDK 8.1.1 for my project in ML403(hardcore
Temac and PLB Temac included). I noticed that there is a directory called
Xilinx_gige in the directory of /drivers/net. Is this the driver for
MontaVista Linux2.4.20? I copied the BSP and overwrote the original one in
the linux kernel directory (in the kernel directory, there is only a
directory called Xilinx_enet, no Xilinx_gige. So I just copied
Xilinx_gige.). However, my problem is in the menuconfig item of Network
Device Support->1000Mbit ethernet, there is not any option to choose and
enable the Xilinx on-chip ethernet. Is this a problem of MontaVista Linux
3.1 Preview Kit, or my problem? And What shall I do to enable the tri-mode
Temac in my platform? Thanks for your answer.
BR
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* question about linux with Xilinx ML-403
From: Ming Liu @ 2006-05-23 9:41 UTC (permalink / raw)
To: rick.moleres; +Cc: linuxppc-embedded
Hi Rick,
> Yes, we have a driver for the PLB TEMAC (different than the GSRD LL
> TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK
> 8.1.1, and MontaVista is on the verge of publishing a driver for PLB
> TEMAC for Linux 2.6. (I believe it came across this mailing list a few
> weeks ago)
I have generated the BSP by EDK 8.1.1 for my project in ML403(hardcore
Temac and PLB Temac included). I noticed that there is a directory called
Xilinx_gige in the directory of /drivers/net. Is this the driver for
MontaVista Linux2.4.20? I copied the BSP and overwrote the original one in
the linux kernel directory (in the kernel directory, there is only a
directory called Xilinx_enet, no Xilinx_gige. So I just copied
Xilinx_gige.). However, my problem is in the menuconfig item of Network
Device Support->1000Mbit ethernet, there is not any option to choose and
enable the Xilinx on-chip ethernet. Is this a problem of MontaVista Linux
3.1 Preview Kit, or my problem? And What shall I do to enable the tri-mode
Temac in my platform? Thanks for your answer.
BR
Ming
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
^ permalink raw reply
* [PATCH] Add CMSPAR to termbits.h for powerpc and alpha
From: Paul Mackerras @ 2006-05-23 9:32 UTC (permalink / raw)
To: akpm; +Cc: linux-arch, linuxppc-dev
Some driver wants to use CMSPAR, but it was missing on alpha and
powerpc. This adds it, with the same value as every other
architecture uses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/include/asm-alpha/termbits.h b/include/asm-alpha/termbits.h
index f4837fa..5541101 100644
--- a/include/asm-alpha/termbits.h
+++ b/include/asm-alpha/termbits.h
@@ -148,6 +148,7 @@ #define PARODD 00020000
#define HUPCL 00040000
#define CLOCAL 00100000
+#define CMSPAR 010000000000 /* mark or space (stick) parity */
#define CRTSCTS 020000000000 /* flow control */
/* c_lflag bits */
diff --git a/include/asm-powerpc/termbits.h b/include/asm-powerpc/termbits.h
index ebf6055..6d533b0 100644
--- a/include/asm-powerpc/termbits.h
+++ b/include/asm-powerpc/termbits.h
@@ -153,6 +153,7 @@ #define PARODD 00020000
#define HUPCL 00040000
#define CLOCAL 00100000
+#define CMSPAR 010000000000 /* mark or space (stick) parity */
#define CRTSCTS 020000000000 /* flow control */
/* c_lflag bits */
^ permalink raw reply related
* Tri-mode or gigebit ethernet support problem in ML403
From: Ming Liu @ 2006-05-23 8:22 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-embedded
Hi Grant,
I want to ask you a problem about the 1000M ethernet support. Now I am
trying to integrate a linux (2.4 or 2.6) in my ML403 platform, with
tri-mode ethernet support. And I have downloaded many versions of linux,
including linuxppc_2_4_devel, MontaVista linux 3.1 Preview
Kit(v2.4.20_mvl31-ml300), and linux-xilinx-26. Unfortunately, I didn't find
any option in the menuconfig item Network Device Support->ethernet
(1000Mbit) for me to enable the 1000M ethernet in all three versions. So I
have the following questions to ask.
1. With Xilinx Virtex 4 tri-mode ethernet MAC support, which version of
Linux shall I use? I think I should choose a version with Xilinx On-chip
Ethernet supported in the 1000M ethernet item in menuconfig.
2. Assume that you can provide me a proper version. Shall I use Xilinx EDK
to generate the BSP for my platform and copy the source code to overwrite
the drivers in the original version. Then configure the kernel and enable
1000M ethernet (choose Xilinx on-chip ethernet). Then compile the
kernel...... Are these steps correct?
Thanks for your help. I am really confused about this problem. Also others
who can help me are welcome. :)
Best Regards
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ permalink raw reply
* Re: HOW TO REPLY ON POST?
From: Daniel Ann @ 2006-05-23 8:11 UTC (permalink / raw)
To: Ladislav Klenovič; +Cc: linuxppc-embedded
In-Reply-To: <ea091fb452d44c86be254e3c0238a3a1@pobox.sk>
U2ltcGx5IGNsaWNrIG9uICJyZXBseSB0byBhbGwiIGJ1dHRvbiBpZiB5b3UgYXJlIG9uIEdVSS4g
T3RoZXJ3aXNlLAp5b3UgbWlnaHQgaGF2ZSB0byByZWFkIHVwIG9uIHlvdXIgbWFpbCB2aWV3ZXIg
Y29tbWFuZHMsIHdoaWNoIGRvZXMKc2ltaWxhci4KCk5vcm1hbGx5ICJyZXBseSIgb3IgInJlcGx5
IHRvIGFsbCIgd2lsbCBtYWludGFpbiB0aGUgb3JpZ2luYWwgc3ViamVjdApvZiB0aGUgZW1haWwg
eW91IGFyZSByZXBseWluZyB0by4gKE5vcm1hbGx5IHRoZXkgcHJlcGVuZCAiUkU6IikgQW5kCnRo
ZW4gaXRzIHVwIHRvIHRoZSBtYWlsaW5nIGxpc3QgZGFlbW9uIHRvIHNvcnQgaXQgaW4gb3V0IGJ5
IHRocmVhZC4KTWFnaWMgaGFwcGVucyBhdCB0aGUgbWFpbGluZyBsaXN0IGRhZW1vbiBpZiBhbGwg
Z29lcyB3ZWxsLgoKQ2hlZXJzLAoKT24gNS8yMy8wNiwgTGFkaXNsYXYgS2xlbm92aeggPGxrOTkz
MzZAcG9ib3guc2s+IHdyb3RlOgo+IEhpLAo+IHNvcnJ5IGZvciB0aGUgc3R1cGlkIHF1ZXN0aW9u
LCBidXQgaG93IHRvIHJlcGx5IG9uIHBvc3QgKGNvbnRpbnVlIGluIHRocmVhZCk/Cj4KPgo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gTGludXhwcGMt
ZW1iZWRkZWQgbWFpbGluZyBsaXN0Cj4gTGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZwo+IGh0
dHBzOi8vb3psYWJzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4cHBjLWVtYmVkZGVkCj4KCgot
LSAKRGFuaWVsCg==
^ permalink raw reply
* HOW TO REPLY ON POST?
From: Ladislav Klenovič @ 2006-05-23 7:23 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
sorry for the stupid question, but how to reply on post (continue in th=
read)?
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Hollis Blanchard @ 2006-05-23 3:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1147860564.14395.6.camel@johannes>
On Wed, 17 May 2006 12:09:24 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Currently snd-aoa is known to work on the following machines:
> * PowerBook5,8
> * PowerBook5,7
> * PowerMac8,1
> * PowerMac8,2
> * 17" October 2005 PowerBook (don't know the number)
> * PowerMac11,2
> * PowerBook6,8
> and my
> * PowerBook5,6
>
> People with those machines are encouraged to use and stress-test it,
> it also provides much better hardware support than snd-powermac, for
> example it can actually reprogram the hardware if you have a 48KHz
> file instead of having to digitally downsample it to 44.1KHz like
> required with snd-powermac in most cases.
The "auto-loading" stuff doesn't seem to be working for me on my
PowerMac11,2, with a fresh git clone as of right now. What is the base
module that should load all the others? After a "make install", I still
had to modprobe almost everything by hand (`find ./snd-aoa -name \*.ko`
in the source directory to get a list).
When the driver finally did completely load, I saw this in dmesg:
snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
snd-aoa-codec-tas: created and attached tas instance
snd-aoa-codec-tas: found keywest-i2c-bus, checking if tas chip is on it
snd-aoa-codec-tas: created and attached tas instance
snd: Unknown layout ID 0x44
i2sbus: mapped i2s control registers
i2sbus: control register contents:
i2sbus: fcr0 = 0x8000056
i2sbus: cell_control = 0x5b43831a
i2sbus: fcr2 = 0xe7008000
i2sbus: fcr3 = 0x72009607
i2sbus: clock_control = 0x0
i2sbus: found i2s controller
snd-aoa-fabric-layout: found bus with layout 68 (using)
snd-aoa: fabric didn't like codec tas
snd-aoa: fabric didn't like codec tas
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
snd-aoa-codec-onyx: created and attached onyx instance
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: can use this codec
snd-aoa-codec-onyx: attached to onyx codec via i2c
snd-aoa-codec-onyx: created and attached onyx instance
serial format: 0x41190000
dws: 0x2000200
i2sbus: found i2s controller
snd-aoa-fabric-layout: found bus with layout 69 (using)
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
snd-aoa: fabric didn't like codec tas
snd-aoa: fabric didn't like codec tas
serial format: 0x41100000
dws: 0x0
all codec info:
formats = 0x808
rates = 0x7fe
For the record, there are two "layout-id" properties in my device tree,
as discussed in this patch:
http://patchwork.ozlabs.org/linuxppc/patch?id=4867
Ultimately, snd_aoa_codec_onyx seems to be the happy module. Only the
headphone jack was enabled; I had to use GNOME's "Volume Control" panel
applet to enable speakers or line out (both of which work).
However, volume control doesn't work at all, for both line-out and
headphone jacks. Should it?
Also, it would be helpful if the git tree were better publicized
somewhere (e.g. http://johannes.sipsolutions.net/). I had to dig through a LOT of mails to find the source.
mkdir snd-aoa
cd snd-aoa/
git clone http://johannes.sipsolutions.net/snd-aoa.git/
cd snd-aoa/
make
-Hollis
P.S. Thanks for working on this Johannes!
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Tom Rini @ 2006-05-23 1:13 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060523005846.GA15797@mag.az.mvista.com>
On Mon, May 22, 2006 at 05:58:46PM -0700, Mark A. Greer wrote:
[snip]
> All of the boards would likely have to be of the same "class".
> Where "class" would be:
> 1) OF system
> 2) e300 core + PQIIPro (e.g., 83xx)
> 3) e500 core + PQIII (e.g., 85xx)
> 4) 6xx/7xx/74xx + mpc10x (e.g., sandpoint)
> etc. Something like that, anyway--maybe there are only "OF" and
> "non-OF'?
That's more limiting than we strictly need, I think. So long as we keep
the instructions that can't/aren't run-time nop'd over, or already done
in a way they don't run on the wrong core (ie ARCH=ppc and sandpoint
running fine on both 745x and 750), it should be (guessing a bit on the
64bit cpus):
1) 6xx/7xx/74xx/8xxx
2) 4xx
3) 8xx
4) 970
5) cell
6) etc
Or so. IOW, so long as we can either nop out, or possibly better yet,
have the compiler get things right (use Makefile/Kconfig magic to get
the LCD -mcpu=/-mtune= option so we run right). Things like PPC_BOARD1
and PPC_BOARD2 would then select PQIII core stuff, MPC10X core stuff,
TSI108 core stuff, GT64x60 core stuff, and so on. And maybe 8xxx has to
be split into BookE/non-BookE, at least to start with, for head*.S
reasons.
As a reminder to all, this also lets us say that if we just pick
PPC_8548CDS then only the stuff required for the 8548CDS would be
compiled into the kernel.
--
Tom Rini
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Mark A. Greer @ 2006-05-23 0:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1147930376.17679.72.camel@localhost.localdomain>
Thanks for your time, Ben. Sorry for taking so long to get back to you.
For the record, this patch was only a hack that I've done to get a sandpoint
up ASAP. I should have made it clear to not take Kconfig, etc. stuffs very
seriously. I was more worried about how we should fit flattened dt into the
bootwrapper.
I'm glad you did look at it so closely though and bring up a lot of good
questions. I'm not familiar with 64-bit platforms so all of my babbling
below is based on my 32-bit platform knowledge.
Mark
---
On Thu, May 18, 2006 at 03:32:55PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2006-05-17 at 17:21 -0700, Mark A. Greer wrote:
<snip>
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 6729c98..de09eac 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -323,7 +323,10 @@ config PPC_ISERIES
> >
> > config EMBEDDED6xx
> > bool "Embedded 6xx/7xx/7xxx-based board"
> > - depends on PPC32 && BROKEN
> > + depends on PPC32
> > + select PPC_UDBG_16550
> > + select MPIC
> > + select MPIC_SERIAL
>
> Not totally related to your patch but I'm tempted to turn that into a
> "Generic 6xx/7xx/7xxx" rather than "embedded" if we manage to always
> avoid board specific code most of the time, but instead add necessary
> bits in the device-tree. We still need a per-board Kconfig option I
> think that will just select the necessary bits and pieces (and more than
> one can be selected at one time). Also, I think right now, the embedded
> stuff is +/- exclusive from the MULTIPLATFORM stuff, that must be fixed
> asap. We are all living in the same kernel now :)
OK.
> > +
> > +config MPIC_SERIAL
> > + depends on EMBEDDED6xx
> > + bool
> > + default n
>
> Not sure what the above is, I'll have a look further in the patch but I
> can already tell you that it should be your per-board
> CONFIG_PPC_SANDPOINT for example that "selects" the various bits you
> need, and thus the above should depend on it, not EMBEDDED6xx... In fact
> I'm wondering wether we should kill EMBEDDED6xx :) Unless it's purely a
> reference to arch/powerpc/platforms/embedded6xx/ as a storage place for
> board setup_xxx.c files which is useful for platforms that really don't
> need more than one or 2 files in there.
I have no attachment to "embedded" so I'm happy to see it
go...especially if I correctly understand what you're saying below.
> > +ifeq ($(CONFIG_EMBEDDED6xx),y)
> > +src-boot += prom_embedded.c ns16550.c dts/sandpoint.S \
> > + dt_utils.c sandpoint.c mpc10x.c
> > +else
> > +src-boot += prom.c
> > +endif
>
> Again, I think CONFIG_EMBEDDED6xx is the wrong approach. I'd like to
> avoid the word "embedded" altogether anyway :) Thing is, it would be
> good if ultimately, embedded boards firmware was capable of passing a
> device-tree. Thus, embedded a device-tree in the zImage wrapper is more
> like a "fallback" solution which has the side effect of creating machine
> specific zImage's.
>
> That is why, I think, what we should do is have rules for building
> separate zImage wrappers. The basic OF one (which exists in both real
> and virtual mode versions and that I'd like to make capable of also
> working if a flat device-tree is passed in), the zImage.sandpoint, the
> zImage.prep, and whatever...
>
> Thus enabling CONFIG_PPC_MYBOARD should trigger the build of the
> board-flavored version of the wrapper in addition to all the other ones
> for the other boards built as part of a given config.
>
> I know it's a bit difficult because the current boot Kbuild rules aren't
> really design for multiple targets but I think that's the way to go.
Okay, to make sure I understand, you're saying that you want to support a
.config file having several CONFIG_PPC_BOARD1, CONFIG_PPC_BOARD2,
CONFIG_PPC_BOARD3 defined at the same time. The resulting zImage would
run on all 3 boards, right?
I'd be happy with that. It should meet the requirements of both
the multiplatform and embedded folks. You could combine that with the
tool paulus talked about a couple weeks ago which would tack the
appropriate flattened device tree (fdt) onto the zImage after the fact.
http://ozlabs.org/pipermail/linuxppc-dev/2006-April/022435.html
We just need to come up with the tool and make the bootwrapper code
smart enough to know what dt to use (an OF dt, an fdt from a firmware, a
fdt tacked on by the tool (along with code to take bd stuff & put it
into the fdt?)).
All of the boards would likely have to be of the same "class".
Where "class" would be:
1) OF system
2) e300 core + PQIIPro (e.g., 83xx)
3) e500 core + PQIII (e.g., 85xx)
4) 6xx/7xx/74xx + mpc10x (e.g., sandpoint)
etc. Something like that, anyway--maybe there are only "OF" and
"non-OF'?
Basically, if its not OF, then its classified by its core + bridge.
So, first thing the zImage does is look for an attached ftb (attached by
paulus' tool). If its there, use it. If its not there, use either the
OFDT (for OF class) or expect a dt to be passed in from the firmware (for
all the other classes). That way you can easily override the dt in the field.
> .../...
>
> About the .dts file, we should look into "shipping" a pre-built one so
> that dtc is not required for building a kernel.
Okay, paulus' tool would allow that. We should also make it smart
enough to replace an attached dts (really dtb--'b' for 'binary') with
a new one.
> I think we already have
> a mecanism for providing "shipped" versions of files and having the
> option of rebuilding them from source (though I don't have the details
> in mind at the moment)
I don't know what you're referring to here.
> > diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
>
> .../.. io stuffs ...
>
> Well... io accessors in here can't harm, the question is more how they
> are used ;)
>
> > +#define PCI_DEVFN(slot,func) ((((slot) & 0x1f) << 3) | ((func) & 0x07))
> > +
> > +/* Indirect PCI config space access routines */
> > +static inline void
> > +pci_indirect_read_config_byte(u32 *cfg_addr, u32 *cfg_data, int devfn,
> > + int offset, u8 *val)
> > +{
> > + out_be32(cfg_addr,
> > + ((offset & 0xfc) << 24) | (devfn << 16) | (0 << 8) | 0x80);
> > + *val = in_8((u8 *)(cfg_data + (offset & 3)));
> > + return;
> > +}
> > +
> > +static inline void
> > +pci_indirect_read_config_dword(u32 *cfg_addr, u32 *cfg_data, int devfn,
> > + int offset, u32 *val)
> > +{
> > + out_be32(cfg_addr,
> > + ((offset & 0xfc) << 24) | (devfn << 16) | (0 << 8) | 0x80);
> > + *val = in_le32(cfg_data + (offset & 3));
> > + return;
> > +}
>
> That's more annoying... if we start having PCI config space access in
> the boot wrapper how far will it stop ? I'd rather keep that sort of
> stuff local to myboard.c file unless it's really worth sharing... Unless
> we end up with really common need for them in which case those should be
> in separate files, possibly in a separate dir (thinking about it, prep
> will probably need that too)
Sure. I was just grabbing code I needed and sticking it whereever to
get things to work. If mpc10x.c is the only one that uses those routines
then they should be in that file only.
> The main problem is how do we do printf kind of things from such a
> bootloader. That needs IO, thus uart drivers etc... possibly parsing
> from the device-tree etc... I'm tempted to just have a global
> "boot_puts" function pointer set by the board and/or OF code to use
> through the bootloader, maybe a shared uart.c file with various uart
> bits and keep the gory implementation details of mapping the uart and
> using those uart bits in the myboard.c file...
Okay.
Question: are we still going to allow cmdline editing in the
bootwrapper? If so, we also need to get uart input and munge the dtb
to put the new args back into the /chosen/bootargs field.
> > +#ifdef CONFIG_PPC_OF
> > typedef void (*kernel_entry_t)( unsigned long,
> > unsigned long,
> > void *,
> > void *);
> > +#else
> > +void platform_fixups(void *dt_blob);
> > +extern void *dt_blob_start;
> > +extern void *dt_blob_end;
> > +void edit_cmdline(void *dt_blob_start);
> > +typedef void (*kernel_entry_t)(void *dtb_addr, void *kernel_entry_paddr,
> > + void *must_be_null);
> > +#endif
>
> Why 2 different prototypes for kernel_entry ?
One for "OF", one for "non-OF" but I'll change it to
"typedef void (*kernel_entry_t)(void *addr, ...);"
to support both. Hrm, I may have another idea... Anyway, I'll do
something about the #ifdef.
> I think we need something like CONFIG_PPC_BOOT_HAS_BUILTIN_DT that
> enables various DT related stuff in a clean way and have a builtin_dt.h
> file with related prototypes & definitions.
If we have the tool mentioned above, we shouldn't need a CONFIG option.
Just check for a NULL ptr or something like that which indicates there's
no dtb attached.
> > #undef DEBUG
> > @@ -218,7 +227,7 @@ void start(unsigned long a1, unsigned lo
> > if (getprop(chosen_handle, "stdout", &stdout, sizeof(stdout)) != 4)
> > exit();
> >
> > - printf("\n\rzImage starting: loaded at 0x%p (sp: 0x%p)\n\r", _start, sp);
> > + printf("\n\rzImage starting: loaded at 0x%p (sp: 0x%p)\n\r", _start,sp);
>
> Gratuituous uglyfication :)
Again, I was just hacking stuff...
<snip>
> >
> > /* Eventually gunzip the kernel */
> > @@ -299,6 +311,7 @@ #endif
> > flush_cache((void *)vmlinux.addr, vmlinux.size);
> >
> > kernel_entry = (kernel_entry_t)vmlinux.addr;
> > +#ifdef CONFIG_PPC_OF
> > #ifdef DEBUG
> > printf( "kernel:\n\r"
> > " entry addr = 0x%lx\n\r"
> > @@ -311,9 +324,20 @@ #ifdef DEBUG
> > #endif
>
> > kernel_entry(a1, a2, prom, NULL);
> > +#else /* !CONFIG_PPC_OF ==> flattened device tree */
> > +#ifdef DEBUG
> > + printf("kernel:\n\r"
> > + " entry addr = 0x%lx\n\r"
> > + " flattened dt = 0x%lx\n\r",
> > + (unsigned long)kernel_entry, &dt_blob_start);
> > +#endif
> > + edit_cmdline(&dt_blob_start);
> > + platform_fixups(&dt_blob_start);
> >
> > + kernel_entry(&dt_blob_start, (void *)vmlinux.addr, NULL);
> > +#endif
>
> Let's avoid #ifdef's if we can... provide function pointers where it
> matter setup by the board/OF init code maybe but not ifdef's. Afaik,
> only WD actually _likes_ ifdef's :)
I'll fix it up.
> > +++ b/arch/powerpc/boot/mpc10x.c
>
> We'll need some subdirs here or it will get messy quick...
Yep.
> > diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
>
> Same comment as above
>
> > +/* XXXX Get info from dt instead */
> > +static struct {
> > + int baud_base;
> > + unsigned long com_port;
> > + u16 iomem_reg_shift;
> > +} rs_table[RS_TABLE_SIZE] = {
> > + { BASE_BAUD, SANDPOINT_SERIAL_0, 0 },
> > + { BASE_BAUD, SANDPOINT_SERIAL_1, 0 },
> > +};
>
> Well, your own comment says it all :) I think we might need an
> equivalent of prom_parse.c in the bootloader
Yes, this was just a hack to get the sandpoint going.
> +
> > +/* #ifndef CONFIG_PPC_OF XXXX */
> > +
> > +/* Definitions used by the flattened device tree */
> > +#define OF_DT_HEADER 0xd00dfeed /* marker */
> > +#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
> > +#define OF_DT_END_NODE 0x2 /* End node */
> > +#define OF_DT_PROP 0x3 /* Property: name off, size,
> > + * content */
> > +#define OF_DT_NOP 0x4 /* nop */
> > +#define OF_DT_END 0x9
> > +
> > +#define OF_DT_VERSION 0x10
>
> .../... (flat DT definitions)
>
> Can't we share the kernel definition here ? Maybe split the kenrel one
> in two if necessary ? I don't like that sort of duplication...
I hope so. I'm hoping we can make a special dir somewhere that has the
definitions of stuff shared between the bootwrapper & the kernel.
How about arch/powerpc/shared? I dunno, something sensible.
> > +unsigned long serial_init(int chan, void *ignored);
> > +void serial_putc(unsigned long com_port, unsigned char c);
> > +unsigned char serial_getc(unsigned long com_port);
> > +int serial_tstc(unsigned long com_port);
>
> Forgot to mention that earlier, but those should be uart_* imho (or even
> 16550_*) since we'll surely have different species of serial ports to
> deal with and I don't like name mixup. Unless we consider that only ever
> one of those serial files get built in a given zImage wrapper in which
> case it makes some sense...
Okay.
> > +call_prom(const char *service, int nargs, int nret, ...)
> > +{
> > +
> > + static struct {
> > + char *service;
> > + int ((*rtn)(int nargs, int nret, va_list args));
> > + } services[] = {
> > + { "exit", service_exit },
> > + { "finddevice", service_finddevice },
> > + { "getprop", service_getprop },
> > + /* { "write", service_write }, */
> > + };
> > + va_list args;
> > + int i, rc = 0;
> > +
> > + for (i=0; i<ARRAY_SIZE(services); i++)
> > + if (!strcmp(service, services[i].service)) {
> > + va_start(args, nret);
> > + rc = services[i].rtn(nargs, nret, args);
> > + va_end(args);
> > + }
> > +
> > + return (nret > 0)? rc : 0;
> > +}
>
> I don't think call_prom is the right abstraction :) We have to decide
> here, we have two choices:
>
> - Either a given zImage wrapper can be booted from both a real OF and
> have an embedded flat DT, in which case we need function pointers and I
> think the right abstraction is for individual prom functions to have
> their function pointer rathaer than "multiplex" through call_prom
>
> - Or a given zImage wrapper is a single board thingy. That is it is
> either the OF wrapper _or_ it can contain an embedded DT. Probably
> easier that way and no need for funciton pointers nor mux at all... I
> tend to think that might be the right way to go at this point...
> Especially since as I wrote before, I'm tempted to think we should just
> in that case build multiple zImage wrappers. The only thing there is
> that if we go that route, I'd like the "OF" one to also be able to boot
> with a flat DT passed on entry to it so it will be useable as a generic
> zImage for firmwares that have a flat DT to pass to the kernel. The only
> "issue" with that is it might be difficult to have console output unless
> we do the putc function pointer thing I described earlier and have
> several "uart" impleentations with differnet names and enough
> device-tree parsing to be able to instanciate them (almost a copy of
> kernel's legacy serial stuff). Another option if we want console output
> is to add something to the DT header specifically for use by such early
> boot code that specifies a function that can be called back for
> displaying thing as long as a given memory range isn't overriden (the FW
> itself)
>
> Comments are welcome here, this is I think the most tricky point and
> where we need to make a decision...
I'm very happy to not use the 'call_prom' abstraction. :)
I guess I have the first one in mind. You have a zImage that runs on
1 to n different platforms. The zImage has to determine which DT to use
(OF DT, fdt from firmware, fdt attached by tool) and pick it apart to
find the I/O resources and serial driver to use. The CONFIG_<BOARD>'s
that are defined would determine the drivers that get built in to the zImage.
> > diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> > index 6e67b5b..2feca55 100644
> > --- a/arch/powerpc/kernel/legacy_serial.c
> > +++ b/arch/powerpc/kernel/legacy_serial.c
> > @@ -147,9 +147,11 @@ static int __init add_legacy_isa_port(st
> > if (reg == NULL)
> > return -1;
> >
> > +#if 0 /* XXXX */
> > /* Verify it's an IO port, we don't support anything else */
> > if (!(reg[0] & 0x00000001))
> > return -1;
> > +#endif
>
> Gack ? Care to explain ?
This 'if' always executed and threw me into the weeds. I didn't get
back to really figuring it out. This was a hack to get going.
> > +obj-$(CONFIG_EMBEDDED6xx) += embedded6xx/
>
> Hrmph.... (random noises)
? No, I needed that to get the build to go into platforms/embedded6xx.
Since platforms/embedded6xx was already there, I assumed that was where
I was to put things like the sandpoint. If/when we get rid of
"embedded", I'll move it to whereever it should go then.
> > +/*
> > + * Define all of the IRQ senses and polarities. Taken from the
> > + * Sandpoint X3 User's manual.
> > + */
> > +static u_char sandpoint_openpic_initsenses[] __initdata = {
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 0: SIOINT */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 1: XXXX FILL?? */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 2: PCI Slot 1 */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 3: PCI Slot 2 */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 4: PCI Slot 3 */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 5: PCI Slot 4 */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 6: XXXX FILL?? */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 7: XXXX FILL?? */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 8: IDE (INT C) */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 9: IDE (INT D) */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 10: */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 11: */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 12: */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 13: */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 14: */
> > + (IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* 15: */
> > +};
>
> Of course you already know that this has to go into the device-tree :)
Yeah, I guess it should. I'll have to figure out how to do that.
> > +/*
> > + * Interrupt setup and service. Interrrupts on the Sandpoint come
> > + * from the four PCI slots plus the 8259 in the Winbond Super I/O (SIO).
> > + * The 8259 is cascaded from EPIC IRQ0, IRQ1-4 map to PCI slots 1-4,
> > + * IDE is on EPIC 7 and 8.
> > + */
> > +static void __init
> > +sandpoint_init_IRQ(void)
> > +{
> > + struct mpic *mpic;
> > + phys_addr_t openpic_paddr = 0xfc000000 + /* XXXX */
> > + MPC10X_EUMB_EPIC_OFFSET;
> > +
> > + /* This doesn't handle i2c, dma, i2o, or timer intrs right now XXXX */
> > + mpic = mpic_alloc(openpic_paddr, MPIC_PRIMARY,
> > + 16 /* XXXX otherwise num_sources used */ ,
> > + NUM_8259_INTERRUPTS,
> > + 0, /* was 16 */
> > + NR_IRQS - 4 /* XXXX */,
> > + sandpoint_openpic_initsenses,
> > + sizeof(sandpoint_openpic_initsenses), " EPIC ");
> > +
> > + BUG_ON(mpic == NULL); /* XXXX */
> > + mpic_assign_isu(mpic, 0, openpic_paddr + 0x10200);
> > + mpic_init(mpic);
> > + mpic_setup_cascade(NUM_8259_INTERRUPTS, i8259_irq_cascade, NULL);
> > + i8259_init(0xfef00000, 0); /* pci iack addr */
> > +}
>
> It would be really nice if we could define properties to put in the
> "mpic" node that defines the various attributes to pass to it and that
> sort of thing so that we can have a generic "mpic_init_IRQ" that walks
> all MPICs and instanciate & link them in cascade when necessary... Oh
> well, food for thought, no high priority there.
That would be great to have!
> > +/*
> > + * Freescale Sandpoint interrupt routing.
> > + */
> > +static inline int
> > +x3_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
> > +{
> > + static char pci_irq_table[][4] =
> > + /*
> > + * PCI IDSEL/INTPIN->INTLINE
> > + * A B C D
> > + */
> > + {
> > + { 16, 0, 0, 0 }, /* IDSEL 11 - i8259 on Winbond */
> > + { 0, 0, 0, 0 }, /* IDSEL 12 - unused */
> > + { 18, 21, 20, 19 }, /* IDSEL 13 - PCI slot 1 */
> > + { 19, 18, 21, 20 }, /* IDSEL 14 - PCI slot 2 */
> > + { 20, 19, 18, 21 }, /* IDSEL 15 - PCI slot 3 */
> > + { 21, 20, 19, 18 }, /* IDSEL 16 - PCI slot 4 */
> > + };
> > +
> > + const long min_idsel = 11, max_idsel = 16, irqs_per_slot = 4;
> > + return PCI_IRQ_TABLE_LOOKUP;
> > +}
>
> Of course you also know that the above has to go into the device-tree as
> well :)
Okay... :)
> > +static void __init
> > +sandpoint_setup_winbond_83553(struct pci_controller *hose)
> > +{
> > + int devfn;
> > +
> > + /*
> > + * Route IDE interrupts directly to the 8259's IRQ 14 & 15.
> > + * We can't route the IDE interrupt to PCI INTC# or INTD# because those
> > + * woule interfere with the PMC's INTC# and INTD# lines.
> > + */
> > + /*
> > + * Winbond Fcn 0
> > + */
> > + devfn = PCI_DEVFN(11,0);
> > +
> > + early_write_config_byte(hose,
> > + 0,
> > + devfn,
> > + 0x43, /* IDE Interrupt Routing Control */
> > + 0xef);
> > + early_write_config_word(hose,
> > + 0,
> > + devfn,
> > + 0x44, /* PCI Interrupt Routing Control */
> > + 0x0000);
> > +
> > + /* Want ISA memory cycles to be forwarded to PCI bus */
> > + early_write_config_byte(hose,
> > + 0,
> > + devfn,
> > + 0x48, /* ISA-to-PCI Addr Decoder Control */
> > + 0xf0);
> > +
> > + /* Enable Port 92. */
> > + early_write_config_byte(hose,
> > + 0,
> > + devfn,
> > + 0x4e, /* AT System Control Register */
> > + 0x06);
> > + /*
> > + * Winbond Fcn 1
> > + */
> > + devfn = PCI_DEVFN(11,1);
> > +
> > + /* Put IDE controller into native mode. */
> > + early_write_config_byte(hose,
> > + 0,
> > + devfn,
> > + 0x09, /* Programming interface Register */
> > + 0x8f);
> > +
> > + /* Init IRQ routing, enable both ports, disable fast 16 */
> > + early_write_config_dword(hose,
> > + 0,
> > + devfn,
> > + 0x40, /* IDE Control/Status Register */
> > + 0x00ff0011);
> > + return;
> > +}
>
> How much of the above could/should be done by the wrapper since it does
> config space access hacks ? My idea is that we might be able to remove
> pretty much _everything_ from this sandpoint.c file ... My dream would
> be to have a generic board support that matches a list of known boards
> for which no special code is needed, only the device-tree (and possibly
> the zImage wrapper).
That's a good dream. :)
> The main things preventing us from doing that at the moment is that we
> need to define enough standard nodes/properties to have the ability to
> the setup interrupt controller tree entirely from it, and the PCI host
> bridges as well. For the later, that means encoding enough of the bridge
> type and config access method to allow having a generic device-tree
> based piece of code that does what add_bridges() does in a generic way.
Yep.
> > +static int
> > +x3_exclude_device(u_char bus, u_char devfn)
> > +{
> > + if ((bus == 0) && (PCI_SLOT(devfn) == 0))
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > + else
> > + return PCIBIOS_SUCCESSFUL;
> > +}
>
> If we need to exclude devices in a generic way, we could define a
> specific exclude list property... or use what I think has already been
> defined by OF for indicating which slots should be probed :)
I'll try to do it through pci quirks, if I can. If not, then I agree.
> > +static int __init
> > +add_bridge(struct device_node *dev)
> > +{
> > + int len;
> > + struct pci_controller *hose;
> > + int *bus_range;
> > +
> > + printk("Adding PCI host bridge %s\n", dev->full_name);
> > +
> > + bus_range = (int *) get_property(dev, "bus-range", &len);
> > + if (bus_range == NULL || len < 2 * sizeof(int))
> > + printk(KERN_WARNING "Can't get bus-range for %s, assume"
> > + " bus 0\n", dev->full_name);
> > +
> > + hose = pcibios_alloc_controller();
> > + if (hose == NULL)
> > + return -ENOMEM;
> > + hose->first_busno = bus_range ? bus_range[0] : 0;
> > + hose->last_busno = bus_range ? bus_range[1] : 0xff;
> > + setup_indirect_pci(hose, 0xfec00000, 0xfee00000);
> > +
> > + /* Interpret the "ranges" property */
> > + /* This also maps the I/O region and sets isa_io/mem_base */
> > + pci_process_bridge_OF_ranges(hose, dev, 1);
> > +
> > + return 0;
> > +}
>
> See above comments.... Looks ok but how many boards will end up having
> very small variations of that same code and thus can we find a way to
> make that totally generic...
Many...
> > +u32 mag_dbg = 0;
> > +
> > +static void __init
> > +sandpoint_setup_arch(void)
> > +{
> > + loops_per_jiffy = 100000000 / HZ;
> > + isa_io_base = 0xfe000000;
> > + isa_mem_base = 0x80000000;
> > + pci_dram_offset = 0;
>
> The isa stuff should probably be deduced from the device-tree, the
> default LPJ too, probably not even useful anymore since we are using the
> timebase nowadays.
Okay.
> > +#ifdef CONFIG_BLK_DEV_INITRD
> > + if (initrd_start)
> > + ROOT_DEV = Root_RAM0;
> > + else
> > +#endif
> > +#ifdef CONFIG_ROOT_NFS
> > + ROOT_DEV = Root_NFS;
> > +#else
> > + ROOT_DEV = Root_HDA1;
> > +#endif
>
> Same comment as above, this is fairly generic and we could even imagine
> something like a linux,default-boot-device thing in the DT...
OK.
> > +#if 1 /* XXXX NEW */
> > + {
> > + struct device_node *np;
> > +
> > + mag_dbg = 1;
> > + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> > + add_bridge(np);
> > + mag_dbg = 0;
> > +
> > + ppc_md.pci_swizzle = common_swizzle;
> > + ppc_md.pci_map_irq = x3_map_irq;
> > + ppc_md.pci_exclude_device = x3_exclude_device; /* XXXX */
> > + }
> > +#endif
>
> The problem of IRQ mapping & swizzling will be solved real soon
> (hopefully early 2.6.18) so that we can completely rely on the
> device-tree without needing device_node's for every PCI device. Only P2P
> bridges that don't do standard swizzling (typically bridges soldered on
> the motherboard) will require device nodes. I'm working on it :)
>
> The idea is that the host bridge will need the standard interrupt-map &
> interrupt-map-mask which will indicate the interrupt mapping for every
> line of every slot/device in the standard way handled by OF (that
> already works). And I'll add code that will be able to handle PCI
> devices without a node by artificially building their "interrupts"
> property based on the interrupt pin config space entry and walking up
> the PCI tree, doing standard swizzling when encountering a P2P bridge
> until we hit something with a device-node in which case we hook our
> result to the interrupt-map of that device-node.
Cool. I'll keep an eye out for that.
> > + if (cpu_has_feature(CPU_FTR_SPEC7450))
> > + /* 745x is different. We only want to pass along enable. */
> > + _set_L2CR(L2CR_L2E);
> > + else if (cpu_has_feature(CPU_FTR_L2CR))
> > + /* All modules have 1MB of L2. We also assume that an
> > + * L2 divisor of 3 will work.
> > + */
> > + _set_L2CR(L2CR_L2E | L2CR_L2SIZ_1MB | L2CR_L2CLK_DIV3
> > + | L2CR_L2RAM_PIPE | L2CR_L2OH_1_0 | L2CR_L2DF);
>
> Keeping in mind my idea of having as much generic code as possible,
> whould we do the above in the boot wrapper or if not, should we provide
> some DT entries indicating that L2CR should be reset and to which
> values ?
I vote for a DT entry.
> > +#if 0
> > + /* Untested right now. */
> > + if (cpu_has_feature(CPU_FTR_L3CR)) {
> > + /* Magic value. */
> > + _set_L3CR(0x8f032000);
> > + }
> > +#endif
> > +}
>
> Same comment as above but for L3CR
DT entry. :)
> .../...
>
> > +/*
> > + * Fix IDE interrupts.
> > + */
> > +static int __init
> > +sandpoint_fix_winbond_83553(void)
> > +{
> > + /* Make some 8259 interrupt level sensitive */
> > + outb(0xe0, 0x4d0);
> > + outb(0xde, 0x4d1);
> > +
> > + return 0;
> > +}
> > +
> > +arch_initcall(sandpoint_fix_winbond_83553);
> > +
> > +/*
> > + * Initialize the ISA devices on the Nat'l PC87308VUL SuperIO chip.
> > + */
> > +static int __init
> > +sandpoint_setup_natl_87308(void)
> > +{
> > + u_char reg;
> > +
> > + /*
> > + * Enable all the devices on the Super I/O chip.
> > + */
> > + SANDPOINT_87308_SELECT_DEV(0x00); /* Select kbd logical device */
> > + SANDPOINT_87308_CFG_OUTB(0xf0, 0x00); /* Set KBC clock to 8 Mhz */
> > + SANDPOINT_87308_DEV_ENABLE(0x00); /* Enable keyboard */
> > + SANDPOINT_87308_DEV_ENABLE(0x01); /* Enable mouse */
> > + SANDPOINT_87308_DEV_ENABLE(0x02); /* Enable rtc */
> > + SANDPOINT_87308_DEV_ENABLE(0x03); /* Enable fdc (floppy) */
> > + SANDPOINT_87308_DEV_ENABLE(0x04); /* Enable parallel */
> > + SANDPOINT_87308_DEV_ENABLE(0x05); /* Enable UART 2 */
> > + SANDPOINT_87308_CFG_OUTB(0xf0, 0x82); /* Enable bank select regs */
> > + SANDPOINT_87308_DEV_ENABLE(0x06); /* Enable UART 1 */
> > + SANDPOINT_87308_CFG_OUTB(0xf0, 0x82); /* Enable bank select regs */
> > +
> > + /* Set up floppy in PS/2 mode */
> > + outb(0x09, SIO_CONFIG_RA);
> > + reg = inb(SIO_CONFIG_RD);
> > + reg = (reg & 0x3F) | 0x40;
> > + outb(reg, SIO_CONFIG_RD);
> > + outb(reg, SIO_CONFIG_RD); /* Have to write twice to change! */
> > +
> > + return 0;
> > +}
>
> Looks like zImage wrapper work to me... Unless we ever get booted by a
> firmware that both provides a flat DT and doesn't do the above....
>
> Ok, I'm not _ABSOLUTELY_ trying to remove the need for a myboar.c file
> here ... but it might be worth doing something generic enough so that
> it's either reduced to the strict minimum in many cases _or_ made
> completely unnecessary if we can...
OK
> > +arch_initcall(sandpoint_setup_natl_87308);
> > +
> > +static int __init
> > +sandpoint_request_io(void)
> > +{
> > + request_region(0x00,0x20,"dma1");
> > + request_region(0x20,0x20,"pic1");
> > + request_region(0x40,0x20,"timer");
> > + request_region(0x80,0x10,"dma page reg");
> > + request_region(0xa0,0x20,"pic2");
> > + request_region(0xc0,0x20,"dma2");
> > +
> > + return 0;
> > +}
>
> The above has to go... not sure yet what is the best way but it's just a
> pain... Could be made dependent on the OFDT too
OK
> > +arch_initcall(sandpoint_request_io);
> > +#endif
> > +
> > +static void __init
> > +sandpoint_map_io(void)
> > +{
> > + io_block_mapping(0xfe000000, 0xfe000000, 0x02000000, _PAGE_IO);
> > +}
>
> To kill absolutely. What is it there for ? At the very least, make
> io_block_mapping allocate virtual space as discussed earlier. I'd like
> to keep BATs for RAM anyway
It'll go away eventually.
> > +static void
> > +sandpoint_restart(char *cmd)
> > +{
> > + local_irq_disable();
> > +
> > + /* Set exception prefix high - to the firmware */
> > + _nmask_and_or_msr(0, MSR_IP);
> > +
> > + /* Reset system via Port 92 */
> > + outb(0x00, 0x92);
> > + outb(0x01, 0x92);
> > +
> > + for(;;); /* Spin until reset happens */
> > +}
>
> The above is fairly common. (Or variations of it). In the context of a
> "generic" board, we could imagine having a list of known "reboot
> methods" and have a DT node indicating which one to use...
Yep.
> > +static void
> > +sandpoint_power_off(void)
> > +{
> > + local_irq_disable();
> > + for(;;); /* No way to shut power off with software */
> > + /* NOTREACHED */
> > +}
>
> The above is _VERY_ commmon :) probably worth just not having a callback
> in ppc_md. at all...
>
> > +static void
> > +sandpoint_halt(void)
> > +{
> > + sandpoint_power_off();
> > + /* NOTREACHED */
> > +}
>
> Same comment as before.
I do see a couple in arch/ppc/platforms that do something different so
how about keeping ppc_md.power_off/_halt but making the above the default
(with only 1 implementation) which can be changed by board code?
> > +static void
> > +sandpoint_show_cpuinfo(struct seq_file *m)
> > +{
> > + seq_printf(m, "vendor\t\t: Freescale\n");
> > + seq_printf(m, "machine\t\t: Sandpoint\n");
> > +}
>
> Do we need that ? We could define standard DT properties that get
> printed in cpuinfo and have that in setup-common.c ...
That would be better.
> .../... (commented out IDE code)
>
> This is a windbond ? Can't it just be probed/detected using normal PCI
> probing ?
I have to revisit all of the IDE stuff in that file and figure out
what's really needed (if any). That's why I have it all '#if 0' right
now. I will get to it eventually.
> > +
> > +/*
> > + * Set BAT 3 to map 0xf8000000 to end of physical memory space 1-to-1.
> > + */
> > +static __inline__ void
> > +sandpoint_set_bat(void)
> > +{
> > + unsigned long bat3u, bat3l;
> > +
> > + __asm__ __volatile__(
> > + " lis %0,0xf800\n \
> > + ori %1,%0,0x002a\n \
> > + ori %0,%0,0x0ffe\n \
> > + mtspr 0x21e,%0\n \
> > + mtspr 0x21f,%1\n \
> > + isync\n \
> > + sync "
> > + : "=r" (bat3u), "=r" (bat3l));
> > +}
>
> WTF ?
It'll disappear. The sandpoint.c is copied from arch/ppc and hacked.
Its pretty old so there's lots of code that can probably be weeded out.
> > +TODC_ALLOC();
> > +
> > +static int __init
> > +sandpoint_probe(void)
> > +{
> > + return 1;
> > +}
>
> WTF (bis) ? :)
bis?
Its just a hack to get it going.
> > +define_machine(sandpoint) {
> > + .name = "Sandpoint",
> > + .probe = sandpoint_probe,
> > + .setup_arch = sandpoint_setup_arch,
> > + .setup_io_mappings = sandpoint_map_io,
> > + .init_IRQ = sandpoint_init_IRQ,
> > + .show_cpuinfo = sandpoint_show_cpuinfo,
> > + .get_irq = mpic_get_irq,
> > + .restart = sandpoint_restart,
> > + .power_off = sandpoint_power_off,
> > + .halt = sandpoint_halt,
> > + .calibrate_decr = generic_calibrate_decr,
> > + /*
> > + .progress = udbg_progress,
> > + */
> > +};
>
> So on the TODO list, replace as much as we can of the above with
> generic_* equivalents until nothing remains :)
Yep, that's the goal.
> > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > index 7dcdfcb..1badbec 100644
> > --- a/arch/powerpc/sysdev/mpic.c
> > +++ b/arch/powerpc/sysdev/mpic.c
> > @@ -629,6 +629,13 @@ #endif /* CONFIG_SMP */
> > mb();
> > }
> >
> > +#ifdef CONFIG_MPIC_SERIAL
> > + /* For serial interrupts & set clock ratio */
> > + mpic_write(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1,
> > + mpic_read(mpic->gregs, MPIC_GREG_GLOBAL_CONF_1)
> > + | (1<<27) | (0x7<<28));
> > +#endif
>
> This should not be an #ifdef.... this should be an MPIC init flag passed
> when initializing it. (and if we do generic device-tree instanciation of
> PIC's, we could define standard properties to put in the MPIC node to
> enable those flags).
Okay, I'll move it into the dt.
> Keep up the good work ! :)
Heh.
> Cheers,
> Ben.
Thanks for the comments.
Mark
^ permalink raw reply
* Re: [PATCH] powerpc: Auto reserve of device tree blob
From: Jon Loeliger @ 2006-05-22 16:25 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <20060518220408.49C6567A44@ozlabs.org>
On Thu, 2006-05-18 at 17:03, Michael Neuling wrote:
> From: Jimi Xenidis <jimix@watson.ibm.com>
>
> A devtree compiler (dtc) generated devtree blob is "relocatable" and so
> does not contain a reserved_map entry for the blob itself. This means
> that if passed to Linux, Linux will not get lmb_reserve() the blob and
> it could be over. The following patch will explicitly reserve the
> "blob" as it was given to us and stops prom_init.c from creating a
> reserved mapping for the blob.
>
> NOTE: that the dtc/kexec should not generate the blob reservation entry.
> Although if they do, LMB reserver handles overlaps.
The current DTC does not issue the memory reservation request.
As discussed earlier, it is now relying on the kernel
to do a reservation for the itself. While I've not seen
it applied yet, I am assuming that Jimi's patch from 14 April
is what is needed here and will be applied. (Maybe it
just needs a "Signed-off" to make it happen. Dunno.)
Thanks,
jdl
^ permalink raw reply
* Re: Preferred way to configure MTD physical mapping and partitioning
From: David Woodhouse @ 2006-05-22 22:35 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200605221232.14880.laurent.pinchart@tbox.biz>
On Mon, 2006-05-22 at 12:32 +0200, Laurent Pinchart wrote:
> - adding a board specific "driver" in drivers/mtd/maps and handle all mapping
> manually
> - adding board specific MTD configuration in arch/ppc/platforms with calls to
> physmap_set_partitions() and physmap_configure()
> - adding board specific MTD configuration in arch/ppc/platforms with a call to
> physmap_set_partitions(), and using the CONFIG_MTD_PHYSMAP option with
> physical mapping values provided in the kernel configuration.
>
> Could anyone comment on the preferred approach ?
None of the above. The physmap driver in the MTD git tree already works
with a platform_device, instead of needing a call to physmap_configure()
or manual configuration at build time. Either register a
platform_device, or preferably extend it to use an of_device too.
--
dwmw2
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Tom Rini @ 2006-05-22 22:22 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1147999765.8515.6.camel@localhost.localdomain>
On Fri, May 19, 2006 at 10:49:25AM +1000, Michael Ellerman wrote:
> On Thu, 2006-05-18 at 17:37 -0700, Mark A. Greer wrote:
> > On Thu, May 18, 2006 at 08:47:01AM -0500, Matthew McClintock wrote:
> > > On Wed, 2006-05-17 at 17:21 -0700, Mark A. Greer wrote:
> > > > +void *
> > > > +dt_find_prop_by_name(void *dt_blob, char *full_name, u32 *val_sizep)
> > >
> > > Is there a reason you are not using of_get_flat_dt_prop() instead of
> > > implementing your own version?
> >
> > Yes. One is in the kernel, one isn't. Or, are you asking why I didn't
> > just copy the kernel code? If so, I probably should have.
> >
> > Hrm, we almost need a library of code shared between the kernel &
> > the bootwrapper. Sort of illegal but it would save duplicating code
> > like the flat dt code.
> >
> > Comments?
>
> Yeah we do. And it's not illegal IMHO as two of our boot wrappers
> (prom_init and the iSeries one) are linked with the kernel anyway.
And on all architectures (practically) the zlib inflate code is shared
between kernel and bootstuff. So it's not unprecidented to do the ugly
define abstractions to let you easily share code as needed.
--
Tom Rini
^ permalink raw reply
* Re: Viable PPC platform?
From: David Woodhouse @ 2006-05-22 22:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060522221556.E60273526CA@atlas.denx.de>
On Tue, 2006-05-23 at 00:15 +0200, Wolfgang Denk wrote:
> But then, a 400 MHz Geode is a bit faster than a 50 MHz 8xx, probably
> not only in terms of CPU performance but also in terms of memory
> bandwidth.
It's actually NAND flash, and the bandwidth sucks (the flash controller
on the Geode companion chip is quite slow). We're getting about 3 MiB/s
from it, although we _ought_ to be able to get 3½. I'm playing with
JFFS2 some more before I go back to tweaking the NAND drivers though.
--
dwmw2
^ permalink raw reply
* Re: Viable PPC platform?
From: Wolfgang Denk @ 2006-05-22 22:15 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-embedded
In-Reply-To: <1148334674.10288.30.camel@shinybook.infradead.org>
In message <1148334674.10288.30.camel@shinybook.infradead.org> you wrote:
>
> Out of interest, how old is that JFFS2 test? If it's with the ancient
> code in the 2.4 kernel, you'll get a _lot_ of improvement by using the
> 2.6 kernel.
This was on a MPC860 system running a 2.4.25 kernel tree with a MTD
snapshot of Spring 2005.
> It looks like it took about 13 seconds to mount the onboard 8MiB flash.
> I can mount 512MiB of flash in 7.9 seconds with the current kernel, with
> a 400MHz AMD Geode.
The file system size was actually only 4 MiB.
But then, a 400 MHz Geode is a bit faster than a 50 MHz 8xx, probably
not only in terms of CPU performance but also in terms of memory
bandwidth.
> There's more work going on right now to reduce the memory usage too.
Fine, thanks!
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Make it right before you make it faster.
^ permalink raw reply
* Re: Viable PPC platform?
From: David Woodhouse @ 2006-05-22 21:51 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060509223113.5715D353DB1@atlas.denx.de>
On Wed, 2006-05-10 at 00:31 +0200, Wolfgang Denk wrote:
> And if somebody wants to see facts and numbers, please see
> http://www.denx.de/wiki/view/DULG/RootFileSystemSelection
Out of interest, how old is that JFFS2 test? If it's with the ancient
code in the 2.4 kernel, you'll get a _lot_ of improvement by using the
2.6 kernel.
It looks like it took about 13 seconds to mount the onboard 8MiB flash.
I can mount 512MiB of flash in 7.9 seconds with the current kernel, with
a 400MHz AMD Geode.
There's more work going on right now to reduce the memory usage too.
--
dwmw2
^ permalink raw reply
* Re: SCC1 as serial console
From: a b @ 2006-05-22 21:07 UTC (permalink / raw)
To: linuxppc-embedded
experiment
__________
http://auto.sme.sk - Všetko o autách (novinky, testy, autosalón, autoškola, porovnaj si auto)
^ permalink raw reply
* Re: SCC1 as serial console
From: Ladislav Klenovi? @ 2006-05-22 21:21 UTC (permalink / raw)
To: Ladislav Klenovi?; +Cc: linuxppc-embedded@ozlabs.org
HOW TO REPLY ON POSTS ?????????????????????? !!!!!!!!!!!!!!!!!!!
>-----P?vodn? spr?va-----
>Od: Ladislav Klenovi? [mailto:lk99336@pobox=2Esk]
>Odoslan?: 22=2E m?ja 2006 13:33
>Komu: linuxppc-embedded@ozlabs=2Eorg
>Predmet: SCC1 as serial console
>
>
>Hi,
>can anybody help me to setup the SCC1 port as serial console on MPC860=
with kernel 2=2E6=2E15=2E4? I would like to use it as system console d=
uring the booting proccess=2E I can not get any output on serial consol=
e during booting proccess, I use uboot=2E
>
>thnx,
>regards ladislav
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs=2Eorg
>https://ozlabs=2Eorg/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: SCC1 as serial console
From: Ladislav Klenovič @ 2006-05-22 21:14 UTC (permalink / raw)
To: lk99336; +Cc: linuxppc-embedded
exp
^ permalink raw reply
* RE : SCC1 as serial console
From: Ladislav Klenovič @ 2006-05-22 21:07 UTC (permalink / raw)
To: linuxppc-embedded
experiment
^ permalink raw reply
* Re: BDI 2000 and MPC 8250 Problem
From: Mark Chambers @ 2006-05-22 20:58 UTC (permalink / raw)
To: Evan Cofsky, linuxppc-embedded
In-Reply-To: <20060522200248.GG341278@valinor.arda.theunixman.com>
> I'm experiencing the following error with a BDI 2000 connected to the
> JTAG port on a A&M Rattler 8250 board. I was wondering if this is a
> hardware problem, or if I have the wrong configuration set up. The
> following are a telnet session transcript, the BDI configuration file,
> and the register configuration file.
>
> Thanks
>
> BDI Telnet Session Transcript (repeats endlessly):
>
> - TARGET: processing user reset request
> *** TARGET: resetting target failed
> # PPC: unexpected response from target
> - TARGET: target will be restarted in 10 sec
>
> rattler8250pci.cfg:
>
> ;bdiGDB configuration file for rattler
> ; ------------------------------------------------------
> ;
> [INIT]
> ;WREG MSR 0x00001002 ; set up MSR
> ;WSPR 1008 0 ; turn off caches
=== > > WM32 0x000101A8 0x00f00000 ; IMMR == 0xFF000000
Type, or are you setting IMMR to 0xf0000000 ?
^ permalink raw reply
* Re: CRAMFS: Error -3 while decompressing!
From: Wolfgang Denk @ 2006-05-22 20:58 UTC (permalink / raw)
To: Igor Luri; +Cc: linuxppc-embedded
In-Reply-To: <44718702.1070809@fagorautomation.es>
In message <44718702.1070809@fagorautomation.es> you wrote:
>
> We have a mpc5200liteB evaluation board with u-boot 1.1.4 and linux
> 2.4.25 from Denx. We have grabed a cramfs root fs on a mtd partition
> and we are able to boot linux without problems:
...
> However, we are not able to boot linux with the same rootfs image (with
> the u-boot header) loaded from RAM.
>
> setenv bootargs root=/dev/rw rw console=ttyS0 console=ttyS0
> init=/sbin/init ip=on
What's /dev/rw ???
> and CRAMFS image is built with correct endianess:
Ummm.. Why would you want to use a cramfs file system in a ramdisk
image? This iseems to be a truely pessimal combination of features to
me. Please see
http://www.denx.de/wiki/view/DULG/RootFileSystemDesignAndBuilding for
some hints...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Life sucks, but it's better than the alternative."
- Peter da Silva
^ permalink raw reply
* BDI 2000 and MPC 8250 Problem
From: Evan Cofsky @ 2006-05-22 20:02 UTC (permalink / raw)
To: linuxppc-embedded
I'm experiencing the following error with a BDI 2000 connected to the
JTAG port on a A&M Rattler 8250 board. I was wondering if this is a
hardware problem, or if I have the wrong configuration set up. The
following are a telnet session transcript, the BDI configuration file,
and the register configuration file.
Thanks
BDI Telnet Session Transcript (repeats endlessly):
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x00000001 => 0x00000001
- JTAG exists check passed
- COP status is 0x05
- Check running state failed
- TARGET: Target PVR is 0x80811014
*** TARGET: resetting target failed
# PPC: unexpected response from target
- TARGET: target will be restarted in 10 sec
rattler8250pci.cfg:
;bdiGDB configuration file for rattler
; ------------------------------------------------------
;
[INIT]
;WREG MSR 0x00001002 ; set up MSR
;WSPR 1008 0 ; turn off caches
WM32 0x000101A8 0x00f00000 ; IMMR == 0xFF000000
WM32 0xff010004 0xFFFFFFC3 ; SYPCR == no watchdog
;WM32 0xFF010C80 0x00000001 ; SCCR == normal operations
;WM32 0xFF010000 0x0E240000 ; SIUMCR non PCI
;WM32 0xFF010000 0x0E640000 ; SIUMCR
;
;
; Memory controller
;
; These writes configure /CS0 to be the 2MB FLASH at 0xFFE0000
; and /CS6 to be the 2MB FLASH at 0xFFC0000
; These writes configure:
; CHIP SELECT BASE ADDRESS SIZE COMMENTS
; ----------- ------------ ---- --------
; /CS0 0WM16 0xFF010184 0x2000 ; MPTPR - PTP==0x20
;WM32 0xff010100 0x80001001 ; BR0
;WM32 0xFF010104 0xFF800E44 ; OR0
;WM32 0xff010104 0xFFC00E76 ; OR0
WM32 0xff010100 0xFE001001 ; BR0
WM32 0xff010104 0xFF800ED2 ; OR0
;
;
; Initialize the SDRAM on the 60x bus. /CS1
;FF
;
; operation
;
;
[TARGET]
CPUTYPE 8260 ;the CPU type (603EV,750,8240,8260)
JTAGCLOCK 0 ;use 16 MHz JTAG clock
WORKSPACE 0xff000000 ;workspace in target RAM for fast download
BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT | GATEWAY)
BREAKMODE SOFT ;SOFT or HARD, HARD uses PPC hardware breakpoints
;VECTOR CATCH 0 ;catch unhandled exceptions
DCACHE NOFLUSH ;data cache flushing (FLUSH | NOFLUSH)
BOOTADDR 0x00000100 ;boot address
REGLIST ALL
STEPMODE TRACE ; use hardware breakpoints to single step
MEMDELAY 4000 ;
;quit
;
[FLASH]
CHIPTYPE AM29BX16 ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16)
CHIPSIZE 0x800000 ;641 8 Meg The size of one flash chip in bytes (e.g. AM29F010 = 0x20000)
BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32 | 64)
;
;
[HOST]
prompt 8250pci>
FORMAT SREC
LOAD MANUAL ;load code MANUAL or AUTO after reset
;
;
[REGS]
DMM1 0xff000000
FILE reg8260.def
reg8260.def:
;Register definition for MPC8260
;===============================
;
; name: user defined name of the register
; type: the type of the register
; GPR general purpose register
; SPR special purpose register
; MM memory mapped register
; DMMx direct memory mapped register with offset
; x = 1..4
; the base is defined in the configuration file
; e.g. DMM1 0x02200000
; addr: the number, adddress or offset of the register
; size the size of the register (8,16 or 32)
;
;name type addr size
;-------------------------------------------
;
sp GPR 1
;
xer SPR 1
lr SPR 8
ctr SPR 9
dsisr SPR 18
dar SPR 19
dec SPR 22
sdr1 SPR 25
srr0 SPR 26
srr1 SPR 27
;
tbl SPR 268
tbu SPR 269
sprg0 SPR 272
sprg1 SPR 273
sprg2 SPR 274
sprg3 SPR 275
ear SPR 282
pvr SPR 287
;
ibat0u SPR 528
ibat0l SPR 529
ibat1u SPR 530
ibat1l SPR 531
ibat2u SPR 532
ibat2l SPR 533
ibat3u SPR 534
ibat3l SPR 535
;
dbat0u SPR 536
dbat0l SPR 537
dbat1u SPR 538
dbat1l SPR 539
dbat2u SPR 540
dbat2l SPR 541
dbat3u SPR 542
dbat3l SPR 543
;
dmiss SPR 976
dcmp SPR 977
imiss SPR 980
icmp SPR 981
rpa SPR 982
;
hid0 SPR 1008
hid1 SPR 1009
hid2 SPR 1011
;
;
; DMM1 must be set to the internal memory base address
;
; General SIU
siumcr DMM1 0x10000 32
sypcr DMM1 0x10004 32
swsr DMM1 0x1000e 16
bcr DMM1 0x10024 32
ppc_acr DMM1 0x10028 8
ppc_alrh DMM1 0x1002c 32
ppc_alrl DMM1 0x10030 32
lcl_acr DMM1 0x10034 8
lcl_alrh DMM1 0x10038 32
lcl_alrl DMM1 0x1003c 32
tescr1 DMM1 0x10040 32
l_tescr1 DMM1 0x10048 32
l_tescr2 DMM1 0x1004c 32
pdtea DMM1 0x10050 32
pdtem DMM1 0x10054 8
ldtea DMM1 0x10058 32
ldtem DMM1 0x1005c 8
;
; Memory Controller
br0 DMM1 0x10100 32
or0 DMM1 0x10104 32
br1 DMM1 0x10108 32
or1 DMM1 0x1010c 32
br2 DMM1 0x10110 32
or2 DMM1 0x10114 32
br3 DMM1 0x10118 32
or3 DMM1 0x1011c 32
br4 DMM1 0x10120 32
or4 DMM1 0x10124 32
br5 DMM1 0x10128 32
or5 DMM1 0x1012c 32
br6 DMM1 0x10130 32
or6 DMM1 0x10134 32
br7 DMM1 0x10138 32
or7 DMM1 0x1013c 32
br8 DMM1 0x10140 32
or8 DMM1 0x10144 32
br9 DMM1 0x10148 32
or9 DMM1 0x1014c 32
br10 DMM1 0x10150 32
or10 DMM1 0x10154 32
br11 DMM1 0x10158 32
or11 DMM1 0x1015c 32
mar DMM1 0x10168 32
mamr DMM1 0x10170 32
mbmr DMM1 0x10174 32
mcmr DMM1 0x10178 32
mptpr DMM1 0x10184 16
mdr DMM1 0x10188 32
psdmr DMM1 0x10190 32
lsdmr DMM1 0x10194 32
purt DMM1 0x10198 8
psrt DMM1 0x1019c 8
lurt DMM1 0x101a0 8
lsrt DMM1 0x101a4 8
immr DMM1 0x101a8 32
;
; System Integration Timers
tmcntsc DMM1 0x10220 16
tmcnt DMM1 0x10224 32
tmcntal DMM1 0x1022c 32
piscr DMM1 0x10240 16
pitc DMM1 0x10244 32
pitr DMM1 0x10248 32
;
; Interrupt Controller
sicr DMM1 0x10c00 16
sivec DMM1 0x10c04 32
sipnr_h DMM1 0x10c08 32
sipnr_l DMM1 0x10c0c 32
siprr DMM1 0x10c10 32
scprr_h DMM1 0x10c14 32
scprr_l DMM1 0x10c18 32
simr_h DMM1 0x10c1c 32
simr_l DMM1 0x10c20 32
siexr DMM1 0x10c24 32
;
; Clocks and Reset
sccr DMM1 0x10c80 32
scmr DMM1 0x10c88 32
rsr DMM1 0x10c90 32
rmr DMM1 0x10c94 32
;
; Input/Output Port
pdira DMM1 0x10d00 32
ppara DMM1 0x10d04 32
psora DMM1 0x10d08 32
podra DMM1 0x10d0c 32
pdata DMM1 0x10d10 32
pdirb DMM1 0x10d20 32
pparb DMM1 0x10d24 32
psorb DMM1 0x10d28 32
podrb DMM1 0x10d2c 32
pdatb DMM1 0x10d30 32
pdirc DMM1 0x10d40 32
pparc DMM1 0x10d44 32
psorc DMM1 0x10d48 32
podrc DMM1 0x10d4c 32
pdatc DMM1 0x10d50 32
pdird DMM1 0x10d60 32
ppard DMM1 0x10d64 32
psord DMM1 0x10d68 32
podrd DMM1 0x10d6c 32
pdatd DMM1 0x10d70 32
;
; CPM Timers
tgcr1 DMM1 0x10d80 8
tgcr2 DMM1 0x10d84 8
tmr1 DMM1 0x10d90 16
tmr2 DMM1 0x10d92 16
trr1 DMM1 0x10d94 16
trr2 DMM1 0x10d96 16
tcr1 DMM1 0x10d98 16
tcr2 DMM1 0x10d9a 16
tcn1 DMM1 0x10d9c 16
tcn2 DMM1 0x10d9e 16
tmr3 DMM1 0x10da0 16
tmr4 DMM1 0x10da2 16
trr3 DMM1 0x10da4 16
trr4 DMM1 0x10da6 16
tcr3 DMM1 0x10da8 16
tcr4 DMM1 0x10daa 16
tcn3 DMM1 0x10dac 16
tcn4 DMM1 0x10dae 16
ter1 DMM1 0x10db0 16
ter2 DMM1 0x10db2 16
ter3 DMM1 0x10db4 16
ter4 DMM1 0x10db6 16
;
; SDMA-General
sdsr DMM1 0x11018 8
sdmr DMM1 0x1101c 8
;
; IDMA
idsr1 DMM1 0x11020 8
idmr1 DMM1 0x11024 8
idsr2 DMM1 0x11028 8
idmr2 DMM1 0x1102c 8
idsr3 DMM1 0x11030 8
idmr3 DMM1 0x11034 8
idsr4 DMM1 0x11038 8
idmr4 DMM1 0x1103c 8
;
; FCC1
gfmr1 DMM1 0x11300 32
fpsmr1 DMM1 0x11304 32
ftodr1 DMM1 0x11308 16
fdsr1 DMM1 0x1130c 16
fcce1 DMM1 0x11310 32
fccm1 DMM1 0x11314 32
fccs1 DMM1 0x11318 8
ftirr1_phy0 DMM1 0x1131c 8
ftirr1_phy1 DMM1 0x1131d 8
ftirr1_phy2 DMM1 0x1131e 8
ftirr1_phy3 DMM1 0x1131f 8
;
; FCC2
gfmr2 DMM1 0x11320 32
fpsmr2 DMM1 0x11324 32
ftodr2 DMM1 0x11328 16
fdsr2 DMM1 0x1132c 16
fcce2 DMM1 0x11330 32
fccm2 DMM1 0x11334 32
fccs2 DMM1 0x11338 8
ftirr2_phy0 DMM1 0x1133c 8
ftirr2_phy1 DMM1 0x1133d 8
ftirr2_phy2 DMM1 0x1133e 8
ftirr2_phy3 DMM1 0x1133f 8
;
; FCC3
gfmr3 DMM1 0x11340 32
fpsmr3 DMM1 0x11344 32
ftodr3 DMM1 0x11348 16
fdsr3 DMM1 0x1134c 16
fcce3 DMM1 0x11350 32
fccm3 DMM1 0x11354 32
fccs3 DMM1 0x11358 8
;
; BRGs 5-8
brgc5 DMM1 0x115f0 32
brgc6 DMM1 0x115f4 32
brgc7 DMM1 0x115f8 32
brgc8 DMM1 0x115fc 32
;
; I2C
i2mod DMM1 0x11860 8
i2add DMM1 0x11864 8
i2brg DMM1 0x11868 8
i2com DMM1 0x1186c 8
i2cer DMM1 0x11870 8
i2cmr DMM1 0x11874 8
;
; Communication Processor
cpcr DMM1 0x119c0 32
rccr DMM1 0x119c4 32
rter DMM1 0x119d6 16
rtmr DMM1 0x119da 16
rtscr DMM1 0x119dc 16
rtsr DMM1 0x119e0 32
;
; BRGs 1-4
brgc1 DMM1 0x119f0 32
brgc2 DMM1 0x119f4 32
brgc3 DMM1 0x119f8 32
brgc4 DMM1 0x119fc 32
;
; SCC1
gsmr_l1 DMM1 0x11a00 32
gsmr_h1 DMM1 0x11a04 32
psmr1 DMM1 0x11a08 16
todr1 DMM1 0x11a0c 16
dsr1 DMM1 0x11a0e 16
scce1 DMM1 0x11a10 16
sccm1 DMM1 0x11a14 16
sccs1 DMM1 0x11a17 8
;
; SCC2
gsmr_l2 DMM1 0x11a20 32
gsmr_h2 DMM1 0x11a24 32
psmr2 DMM1 0x11a28 16
todr2 DMM1 0x11a2c 16
dsr2 DMM1 0x11a2e 16
scce2 DMM1 0x11a30 16
sccm2 DMM1 0x11a34 16
sccs2 DMM1 0x11a37 8
;
; SCC3
gsmr_l3 DMM1 0x11a40 32
gsmr_h3 DMM1 0x11a44 32
psmr3 DMM1 0x11a48 16
todr3 DMM1 0x11a4c 16
dsr3 DMM1 0x11a4e 16
scce3 DMM1 0x11a50 16
sccm3 DMM1 0x11a54 16
sccs3 DMM1 0x11a57 8
;
; SCC4
gsmr_l4 DMM1 0x11a60 32
gsmr_h4 DMM1 0x11a64 32
psmr4 DMM1 0x11a68 16
todr4 DMM1 0x11a6c 16
dsr4 DMM1 0x11a6e 16
scce4 DMM1 0x11a70 16
sccm4 DMM1 0x11a74 16
sccs4 DMM1 0x11a77 8
;
; SMC1
smcmr1 DMM1 0x11a82 16
smce1 DMM1 0x11a86 8
smcm1 DMM1 0x11a8a 8
;
; SMC2
smcmr2 DMM1 0x11a92 16
smce2 DMM1 0x11a96 8
smcm2 DMM1 0x11a9a 8
;
; SPI
spmode DMM1 0x11aa0 16
spie DMM1 0x11aa6 8
spim DMM1 0x11aaa 8
spcom DMM1 0x11aad 8
;
; CPM Mux
cmxsi1cr DMM1 0x11b00 8
cmxsi2cr DMM1 0x11b02 8
cmxfcr DMM1 0x11b04 32
cmxscr DMM1 0x11b08 32
cmxsmr DMM1 0x11b0c 8
cmxuar DMM1 0x11b0e 16
;
; SI1 Registers
si1amr DMM1 0x11b20 16
si1bmr DMM1 0x11b22 16
si1cmr DMM1 0x11b24 16
si1dmr DMM1 0x11b26 16
si1gmr DMM1 0x11b28 8
si1cmdr DMM1 0x11b2a 8
si1str DMM1 0x11b2c 8
si1rsr DMM1 0x11b2e 16
;
; MCC1 Registers
mcce1 DMM1 0x11b30 16
mccm1 DMM1 0x11b34 16
mccf1 DMM1 0x11b38 8
;
; SI2 Registers
si2amr DMM1 0x11b40 16
si2bmr DMM1 0x11b42 16
si2cmr DMM1 0x11b44 16
si2dmr DMM1 0x11b46 16
si2gmr DMM1 0x11b48 8
si2cmdr DMM1 0x11b4a 8
si2str DMM1 0x11b4c 8
si2rsr DMM1 0x11b4e 16
;
; MCC2 Registers
mcce2 DMM1 0x11b50 16
mccm2 DMM1 0x11b54 16
mccf2 DMM1 0x11b58 8
;
--
Evan Cofsky "The UNIX Man" <evan@theunixman.com>
See you space cowboy
^ permalink raw reply
* Re: [Cbe-oss-dev] Cell and new CPU feature bits
From: Alex Rosenberg @ 2006-05-22 19:46 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: cbe-oss-dev, Arnd Bergmann, linuxppc-dev list
In-Reply-To: <20060519081654.GB22952@iram.es>
On May 19, 2006, at 1:16 AM, Gabriel Paubert wrote:
> On Fri, May 19, 2006 at 02:07:01PM +1000, Benjamin Herrenschmidt
> wrote:
>> The Cell has a couple of "features" that should be exposed to
>> userland
>> in a way or another. That raises some questions however about how
>> those
>> should be done. Among others that come to mind:
>>
>> - The timebase errata (should we use a separate aux vector for
>> "bugs"
>> than for "features" ?
>
> Is this bug really going to be exposed in the wild or is it
> an early silicon bug that will only bite early-testers?
Is this or any other errata published somewhere? I didn't think they
were.
>> - Additional Altivec instructions (load/store right/left). A new
>> feature bit for these ?
>
> Yes. So IBM was not happy with Altivec instructions to generate
> vsel control words and got their inspiration from MIPS?
I think you can blame Waternoose for this, not Cell.
>> - Not strictly Cell specific but we currently don't expose the
>> support
>> for optional instructions
>> fres and frsqte (which are supported by Cell)
>
> Should be exposed IMHO. But these instructions have been present
> in a lot of PPC processors AFAIR, they are in my original 603 and
> 604 manuals from 1994 (fsel is also marked as optional and is not
> implemented on the 601, but I'm not sure it's really supported
> anymore). I don't know about Power processors.
Our solution back at Apple was to put OF properties on the CPU node
for each optional feature. e.g. for fres and frsqrte we put
"graphics" since that's the official term for that group of optional
instructions. We also put in "data-streams" instead of presuming that
dss, etc. were always part of "altivec". These properties nicely fit
into our Gestalt() API where "ppcf" had 32 bits to describe these to
userland software.
-----------------------------------------
Alex Rosenberg
Runtime Lead, Tools & Technology team
Sony Computer Entertainment America, Inc.
^ permalink raw reply
* Re: pseries softreset on cpus in 32bit mode
From: Olaf Hering @ 2006-05-22 18:46 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060522164111.GA14462@suse.de>
On Mon, May 22, Olaf Hering wrote:
>
> Consider a simple app like this, which is placed as '/init' in an initrd
> cpio archive:
>
> hello32.c
>
> #include <stdio.h>
> int main(void) {
> printf("foobar\n");
> asm("li 31,0; b .\n");
> return 0;
> }
Modified the userland app to init some registers with a fixed value, and
ran a kernel with the debug patch below. It gets into bad_stack from
decrementer_common = c000000000003400. 3200 is coming from
c000000000003200 <system_reset_common>:
So what does that mean? Should a softreset disable interrupts?
Linux version 2.6.17-rc4-g353b28ba-dirty (olaf@pomegranate) (gcc version 4.1.0 (SUSE Linux)) #13 SMP Mon May 22 20:38:56 CEST 2006
[boot]0012 Setup Arch
Top of RAM: 0x1e000000, Total RAM: 0x1e000000
Memory hole size: 0MB
PPC64 nvram contains 16384 bytes
Using default idle loop
[boot]0015 Setup Done
Built 1 zonelists
Kernel command line: root=/dev/hda2 xmon=on quiet
foobar
Bad kernel stack pointer ffad3ad0 at 3200
cpu 0x1: Vector: c000000007a5ef10 at [c000000007a5ed40]
pc: 0000000000003200
lr: 0000000010000338
sp: ffad3ad0
msr: 40001032
current = 0xc00000000ffc67e0
paca = 0xc00000000053a100
pid = 1, comm = init
enter ? for help
1:mon> r
R00 = 0000000010000338 R16 = c0000000004470e8
R01 = 00000000ffad3ad0 R17 = 0000000000000000
R02 = 000000001009c470 R18 = 00000000000413cd
R03 = 0000000007aceff8 R19 = 0000000000507ab8
R04 = 000000001002489c R20 = 0000000000000042
R05 = 0000000040000042 R21 = 0000000000000042
R06 = 0000000000004000 R22 = 0000000000000042
R07 = 000000001000b100 R23 = 0000000000000042
R08 = 000000000000f932 R24 = 0000000000000042
R09 = 0000000000000000 R25 = 0000000000000042
R10 = 0000000000000000 R26 = 0000000000000042
R11 = 0000000000000000 R27 = 0000000000000042
R12 = 00000000200fffff R28 = 0000000000000042
R13 = c00000000053a100 R29 = 0000000000003420
R14 = c000000000448a38 R30 = 0000000000003200
R15 = 4000000002010000 R31 = 0000000010000368
pc = 0000000000003200
lr = 0000000010000338
msr = 0000000040001032 cr = 20000042
ctr = 0000000000032ddc xer = 00000000200fffff trap = c000000007a5ef10
1:mon>
Index: linux-2.6/arch/powerpc/kernel/head_64.S
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/head_64.S
+++ linux-2.6/arch/powerpc/kernel/head_64.S
@@ -269,7 +269,12 @@ exception_marker:
subi r1,r1,INT_FRAME_SIZE; /* alloc frame on kernel stack */ \
beq- 1f; \
ld r1,PACAKSAVE(r13); /* kernel stack to use */ \
-1: cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
+1: \
+ cmpdi cr1,r29,0x42; \
+ bne cr1,2f; \
+ li r29,2f@l; \
+2: \
+ cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
bge- cr1,bad_stack; /* abort if it is */ \
std r9,_CCR(r1); /* save CR in stackframe */ \
std r11,_NIP(r1); /* save SRR0 in stackframe */ \
@@ -600,6 +605,7 @@ slb_miss_user_pseries:
system_reset_fwnmi:
HMT_MEDIUM
mtspr SPRN_SPRG1,r13 /* save r13 */
+ mfspr r31,SPRN_SRR0
EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, system_reset_common)
.globl machine_check_fwnmi
@@ -842,6 +848,7 @@ bad_stack:
std r9,_CCR(r1)
std r10,GPR1(r1)
std r11,_NIP(r1)
+ mr r30,r11
std r12,_MSR(r1)
mfspr r11,SPRN_DAR
mfspr r12,SPRN_DSISR
^ permalink raw reply
* net/ieee80211/softmac/ieee80211softmac_io.c:464: warning: 'ieee80211softmac_send_ctl_frame' defined but not used
From: Toralf Förster @ 2006-05-22 17:48 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 185 bytes --]
While playing with various kernel config I observed the warning above
compiling 2.6.17-rc4-git10.
The .config file is attached onto this mail.
--
MfG/Sincerely
Toralf Förster
[-- Attachment #1.2: config.rnd.23 --]
[-- Type: text/plain, Size: 29145 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.17-rc4-git10
# Mon May 22 19:08:43 2006
#
CONFIG_X86_32=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
CONFIG_IKCONFIG=y
CONFIG_RELAY=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_UID16=y
CONFIG_VM86=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
# CONFIG_MODULES is not set
#
# Block layer
#
# CONFIG_LBD is not set
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
CONFIG_DEFAULT_NOOP=y
CONFIG_DEFAULT_IOSCHED="noop"
#
# Processor type and features
#
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
# CONFIG_X86_UP_APIC is not set
# CONFIG_X86_MCE is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=y
# CONFIG_X86_MSR is not set
CONFIG_X86_CPUID=y
#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
CONFIG_DCDBAS=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_EFI is not set
# CONFIG_REGPARM is not set
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
# CONFIG_KEXEC is not set
CONFIG_PHYSICAL_START=0x100000
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SOFTWARE_SUSPEND is not set
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
CONFIG_SCx200=y
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NETDEBUG is not set
# CONFIG_PACKET is not set
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_ASK_IP_FIB_HASH is not set
CONFIG_IP_FIB_TRIE=y
# CONFIG_IP_FIB_HASH is not set
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_MULTIPATH_CACHED=y
# CONFIG_IP_ROUTE_MULTIPATH_RR is not set
CONFIG_IP_ROUTE_MULTIPATH_RANDOM=y
CONFIG_IP_ROUTE_MULTIPATH_WRANDOM=y
CONFIG_IP_ROUTE_MULTIPATH_DRR=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_MROUTE=y
# CONFIG_IP_PIMSM_V1 is not set
# CONFIG_IP_PIMSM_V2 is not set
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
#
# TCP congestion control
#
CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TCP_CONG_WESTWOOD is not set
CONFIG_TCP_CONG_HTCP=y
CONFIG_TCP_CONG_HSTCP=y
# CONFIG_TCP_CONG_HYBLA is not set
CONFIG_TCP_CONG_VEGAS=y
# CONFIG_TCP_CONG_SCALABLE is not set
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_INET6_AH is not set
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_INET6_XFRM_TUNNEL=y
CONFIG_INET6_TUNNEL=y
CONFIG_IPV6_TUNNEL=y
# CONFIG_NETFILTER is not set
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
CONFIG_VLAN_8021Q=y
# CONFIG_DECNET is not set
CONFIG_LLC=y
CONFIG_LLC2=y
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
CONFIG_NET_DIVERT=y
CONFIG_ECONET=y
# CONFIG_ECONET_AUNUDP is not set
# CONFIG_ECONET_NATIVE is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Network testing
#
CONFIG_HAMRADIO=y
#
# Packet Radio protocols
#
CONFIG_AX25=y
# CONFIG_AX25_DAMA_SLAVE is not set
# CONFIG_NETROM is not set
# CONFIG_ROSE is not set
#
# AX.25 network device drivers
#
# CONFIG_MKISS is not set
# CONFIG_6PACK is not set
CONFIG_BPQETHER=y
CONFIG_BAYCOM_SER_FDX=y
CONFIG_BAYCOM_SER_HDX=y
CONFIG_BAYCOM_PAR=y
# CONFIG_BAYCOM_EPP is not set
# CONFIG_YAM is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_IEEE80211=y
# CONFIG_IEEE80211_DEBUG is not set
# CONFIG_IEEE80211_CRYPT_WEP is not set
CONFIG_IEEE80211_CRYPT_CCMP=y
CONFIG_IEEE80211_SOFTMAC=y
# CONFIG_IEEE80211_SOFTMAC_DEBUG is not set
CONFIG_WIRELESS_EXT=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=y
# CONFIG_PROC_EVENTS is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
CONFIG_PARPORT=y
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_1284=y
#
# Plug and Play support
#
# CONFIG_PNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_CPQ_DA=y
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_UMEM=y
# CONFIG_BLK_DEV_COW_COMMON is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_SX8=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
CONFIG_BLK_DEV_IDE_SATA=y
CONFIG_BLK_DEV_HD_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_IDE_TASK_IOCTL=y
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_IDEPCI is not set
# CONFIG_IDE_ARM is not set
# CONFIG_BLK_DEV_IDEDMA is not set
# CONFIG_IDEDMA_AUTO is not set
CONFIG_BLK_DEV_HD=y
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
# CONFIG_SCSI is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=y
#
# Subsystem Options
#
CONFIG_IEEE1394_VERBOSEDEBUG=y
# CONFIG_IEEE1394_OUI_DB is not set
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y
CONFIG_IEEE1394_EXPORT_FULL_API=y
#
# Device Drivers
#
CONFIG_IEEE1394_PCILYNX=y
# CONFIG_IEEE1394_OHCI1394 is not set
#
# Protocol Drivers
#
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_RAWIO=y
#
# I2O device support
#
CONFIG_I2O=y
CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y
CONFIG_I2O_EXT_ADAPTEC=y
# CONFIG_I2O_CONFIG is not set
# CONFIG_I2O_BUS is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_PROC is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_BONDING=y
CONFIG_EQUALIZER=y
CONFIG_TUN=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
CONFIG_CASSINI=y
# CONFIG_NET_VENDOR_3COM is not set
#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
CONFIG_TULIP=y
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
# CONFIG_TULIP_NAPI is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_HP100 is not set
# CONFIG_NET_PCI is not set
CONFIG_NET_POCKET=y
# CONFIG_ATP is not set
CONFIG_DE600=y
CONFIG_DE620=y
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=y
# CONFIG_E1000_NAPI is not set
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
CONFIG_TIGON3=y
CONFIG_BNX2=y
#
# Ethernet (10000 Mbit)
#
CONFIG_CHELSIO_T1=y
# CONFIG_IXGB is not set
CONFIG_S2IO=y
# CONFIG_S2IO_NAPI is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
CONFIG_WAN=y
CONFIG_LANMEDIA=y
CONFIG_SYNCLINK_SYNCPPP=y
# CONFIG_HDLC is not set
CONFIG_DLCI=y
CONFIG_DLCI_COUNT=24
CONFIG_DLCI_MAX=8
# CONFIG_SBNI is not set
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
CONFIG_SKFP=y
# CONFIG_HIPPI is not set
CONFIG_PLIP=y
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_RX=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_EVBUG=y
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
CONFIG_KEYBOARD_LKKBD=y
CONFIG_KEYBOARD_XTKBD=y
CONFIG_KEYBOARD_NEWTON=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=y
CONFIG_MOUSE_VSXXXAA=y
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
CONFIG_JOYSTICK_GRIP_MP=y
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
CONFIG_JOYSTICK_SIDEWINDER=y
# CONFIG_JOYSTICK_TMDC is not set
CONFIG_JOYSTICK_IFORCE=y
# CONFIG_JOYSTICK_IFORCE_232 is not set
CONFIG_JOYSTICK_WARRIOR=y
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
CONFIG_JOYSTICK_STINGER=y
# CONFIG_JOYSTICK_TWIDJOY is not set
CONFIG_JOYSTICK_DB9=y
# CONFIG_JOYSTICK_GAMECON is not set
CONFIG_JOYSTICK_TURBOGRAFX=y
CONFIG_JOYSTICK_JOYDUMP=y
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_UINPUT is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=y
CONFIG_GAMEPORT=y
CONFIG_GAMEPORT_NS558=y
# CONFIG_GAMEPORT_L4 is not set
CONFIG_GAMEPORT_EMU10K1=y
CONFIG_GAMEPORT_FM801=y
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
CONFIG_CYCLADES=y
# CONFIG_CYZ_INTR is not set
CONFIG_DIGIEPCA=y
CONFIG_MOXA_INTELLIO=y
# CONFIG_MOXA_SMARTIO is not set
CONFIG_ISI=y
# CONFIG_SYNCLINK is not set
CONFIG_SYNCLINKMP=y
CONFIG_SYNCLINK_GT=y
# CONFIG_N_HDLC is not set
# CONFIG_RISCOM8 is not set
CONFIG_SPECIALIX=y
# CONFIG_SPECIALIX_RTSCTS is not set
# CONFIG_SX is not set
CONFIG_RIO=y
# CONFIG_RIO_OLDPCI is not set
CONFIG_STALDRV=y
# CONFIG_STALLION is not set
# CONFIG_ISTALLION is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=y
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_PRINTER is not set
CONFIG_PPDEV=y
# CONFIG_TIPAR is not set
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
CONFIG_DTLK=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
CONFIG_AGP_SWORKS=y
# CONFIG_AGP_VIA is not set
CONFIG_AGP_EFFICEON=y
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
CONFIG_DRM_R128=y
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_MGA=y
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
CONFIG_MWAVE=y
# CONFIG_SCx200_GPIO is not set
# CONFIG_CS5535_GPIO is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=256
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=y
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
CONFIG_TELCLOCK=y
#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
CONFIG_I2C_ALGOPCA=y
#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=y
# CONFIG_I2C_ALI1563 is not set
CONFIG_I2C_ALI15X3=y
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
CONFIG_I2C_PIIX4=y
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
CONFIG_I2C_PROSAVAGE=y
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
CONFIG_I2C_PCA_ISA=y
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
CONFIG_SENSORS_DS1374=y
CONFIG_SENSORS_EEPROM=y
CONFIG_SENSORS_PCF8574=y
CONFIG_SENSORS_PCA9539=y
CONFIG_SENSORS_PCF8591=y
CONFIG_SENSORS_MAX6875=y
# CONFIG_I2C_DEBUG_CORE is not set
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_DEBUG_CHIP=y
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
#
# Dallas's 1-wire bus
#
CONFIG_W1=y
#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_MATROX is not set
# CONFIG_W1_MASTER_DS2482 is not set
#
# 1-wire Slaves
#
CONFIG_W1_SLAVE_THERM=y
CONFIG_W1_SLAVE_SMEM=y
# CONFIG_W1_SLAVE_DS2433 is not set
#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set
#
# Misc devices
#
CONFIG_IBM_ASM=y
#
# Multimedia devices
#
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y
#
# Video Capture Adapters
#
#
# Video Capture Adapters
#
CONFIG_VIDEO_ADV_DEBUG=y
# CONFIG_VIDEO_VIVI is not set
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_BWQCAM is not set
CONFIG_VIDEO_CQCAM=y
# CONFIG_VIDEO_W9966 is not set
CONFIG_VIDEO_CPIA=y
CONFIG_VIDEO_CPIA_PP=y
CONFIG_VIDEO_SAA5246A=y
CONFIG_VIDEO_SAA5249=y
CONFIG_TUNER_3036=y
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
CONFIG_VIDEO_HEXIUM_ORION=y
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
CONFIG_VIDEO_CX88=y
CONFIG_VIDEO_CX88_ALSA=y
CONFIG_VIDEO_CX88_DVB=y
# CONFIG_VIDEO_CX88_DVB_ALL_FRONTENDS is not set
CONFIG_VIDEO_CX88_DVB_MT352=y
# CONFIG_VIDEO_CX88_DVB_VP3054 is not set
# CONFIG_VIDEO_CX88_DVB_ZL10353 is not set
# CONFIG_VIDEO_CX88_DVB_OR51132 is not set
# CONFIG_VIDEO_CX88_DVB_CX22702 is not set
# CONFIG_VIDEO_CX88_DVB_LGDT330X is not set
# CONFIG_VIDEO_CX88_DVB_NXT200X is not set
# CONFIG_VIDEO_CX88_DVB_CX24123 is not set
CONFIG_VIDEO_OVCAMCHIP=y
#
# Encoders and Decoders
#
# CONFIG_VIDEO_MSP3400 is not set
# CONFIG_VIDEO_CS53L32A is not set
CONFIG_VIDEO_WM8775=y
CONFIG_VIDEO_WM8739=y
# CONFIG_VIDEO_CX25840 is not set
# CONFIG_VIDEO_SAA711X is not set
CONFIG_VIDEO_SAA7127=y
# CONFIG_VIDEO_UPD64031A is not set
CONFIG_VIDEO_UPD64083=y
#
# Radio Adapters
#
CONFIG_RADIO_GEMTEK_PCI=y
# CONFIG_RADIO_MAXIRADIO is not set
CONFIG_RADIO_MAESTRO=y
#
# Digital Video Broadcasting Devices
#
CONFIG_DVB=y
CONFIG_DVB_CORE=y
#
# Supported SAA7146 based PCI Adapters
#
CONFIG_DVB_AV7110=y
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET=y
CONFIG_DVB_BUDGET_CI=y
CONFIG_DVB_BUDGET_AV=y
# CONFIG_DVB_BUDGET_PATCH is not set
#
# Supported FlexCopII (B2C2) Adapters
#
# CONFIG_DVB_B2C2_FLEXCOP is not set
#
# Supported BT878 Adapters
#
#
# Supported Pluto2 Adapters
#
# CONFIG_DVB_PLUTO2 is not set
#
# Supported DVB Frontends
#
#
# Customise DVB Frontends
#
#
# DVB-S (satellite) frontends
#
CONFIG_DVB_STV0299=y
# CONFIG_DVB_CX24110 is not set
# CONFIG_DVB_CX24123 is not set
CONFIG_DVB_TDA8083=y
CONFIG_DVB_MT312=y
CONFIG_DVB_VES1X93=y
CONFIG_DVB_S5H1420=y
#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=y
# CONFIG_DVB_SP887X is not set
CONFIG_DVB_CX22700=y
CONFIG_DVB_CX22702=y
CONFIG_DVB_L64781=y
CONFIG_DVB_TDA1004X=y
CONFIG_DVB_NXT6000=y
CONFIG_DVB_MT352=y
# CONFIG_DVB_ZL10353 is not set
CONFIG_DVB_DIB3000MB=y
CONFIG_DVB_DIB3000MC=y
#
# DVB-C (cable) frontends
#
CONFIG_DVB_VES1820=y
CONFIG_DVB_TDA10021=y
CONFIG_DVB_STV0297=y
#
# ATSC (North American/Korean Terresterial DTV) frontends
#
# CONFIG_DVB_NXT200X is not set
# CONFIG_DVB_OR51211 is not set
# CONFIG_DVB_OR51132 is not set
CONFIG_DVB_BCM3510=y
CONFIG_DVB_LGDT330X=y
CONFIG_VIDEO_SAA7146=y
CONFIG_VIDEO_SAA7146_VV=y
CONFIG_VIDEO_VIDEOBUF=y
CONFIG_VIDEO_TUNER=y
CONFIG_VIDEO_BUF=y
CONFIG_VIDEO_BUF_DVB=y
CONFIG_VIDEO_BTCX=y
CONFIG_VIDEO_IR=y
CONFIG_VIDEO_TVEEPROM=y
#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
#
# Sound
#
CONFIG_SOUND=y
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=y
CONFIG_SND_RAWMIDI=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
# CONFIG_SND_PCM_OSS_PLUGINS is not set
CONFIG_SND_RTCTIMER=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
CONFIG_SND_DEBUG_DETECT=y
#
# Generic devices
#
CONFIG_SND_MPU401_UART=y
CONFIG_SND_OPL3_LIB=y
CONFIG_SND_VX_LIB=y
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_AC97_BUS=y
CONFIG_SND_DUMMY=y
CONFIG_SND_MTPAV=y
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
CONFIG_SND_ALS300=y
CONFIG_SND_ALS4000=y
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
CONFIG_SND_ATIIXP_MODEM=y
# CONFIG_SND_AU8810 is not set
CONFIG_SND_AU8820=y
# CONFIG_SND_AU8830 is not set
CONFIG_SND_AZT3328=y
CONFIG_SND_BT87X=y
CONFIG_SND_BT87X_OVERCLOCK=y
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
CONFIG_SND_CS4281=y
# CONFIG_SND_CS46XX is not set
CONFIG_SND_CS5535AUDIO=y
CONFIG_SND_EMU10K1=y
CONFIG_SND_EMU10K1X=y
# CONFIG_SND_ENS1370 is not set
CONFIG_SND_ENS1371=y
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
CONFIG_SND_FM801=y
CONFIG_SND_FM801_TEA575X=y
# CONFIG_SND_HDA_INTEL is not set
CONFIG_SND_HDSP=y
# CONFIG_SND_HDSPM is not set
CONFIG_SND_ICE1712=y
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
CONFIG_SND_INTEL8X0M=y
CONFIG_SND_KORG1212=y
CONFIG_SND_MAESTRO3=y
# CONFIG_SND_MIXART is not set
CONFIG_SND_NM256=y
CONFIG_SND_PCXHR=y
CONFIG_SND_RIPTIDE=y
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
CONFIG_SND_RME9652=y
CONFIG_SND_SONICVIBES=y
CONFIG_SND_TRIDENT=y
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
CONFIG_SND_VX222=y
# CONFIG_SND_YMFPCI is not set
#
# Open Sound System
#
CONFIG_SOUND_PRIME=y
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_EMU10K1 is not set
CONFIG_SOUND_FUSION=y
CONFIG_SOUND_ES1371=y
# CONFIG_SOUND_ICH is not set
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_VIA82CXXX is not set
# CONFIG_SOUND_OSS is not set
# CONFIG_SOUND_TVMIXER is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
# CONFIG_USB is not set
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
CONFIG_MMC=y
CONFIG_MMC_DEBUG=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_SDHCI=y
# CONFIG_MMC_WBSD is not set
#
# LED devices
#
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
#
# LED drivers
#
#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not set
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
# CONFIG_EDAC is not set
#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set
#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_FS_POSIX_ACL is not set
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=y
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=y
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
# CONFIG_PROC_FS is not set
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=y
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
CONFIG_BEFS_FS=y
CONFIG_BEFS_DEBUG=y
# CONFIG_BFS_FS is not set
CONFIG_EFS_FS=y
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
CONFIG_SYSV_FS=y
CONFIG_UFS_FS=y
#
# Network File Systems
#
# CONFIG_NFS_FS is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
CONFIG_RPCSEC_GSS_SPKM3=y
CONFIG_SMB_FS=y
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_CIFS=y
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_XATTR is not set
CONFIG_CIFS_EXPERIMENTAL=y
# CONFIG_CIFS_UPCALL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
CONFIG_AFS_FS=y
CONFIG_RXRPC=y
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
CONFIG_NLS_CODEPAGE_737=y
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
CONFIG_NLS_CODEPAGE_855=y
# CONFIG_NLS_CODEPAGE_857 is not set
CONFIG_NLS_CODEPAGE_860=y
CONFIG_NLS_CODEPAGE_861=y
CONFIG_NLS_CODEPAGE_862=y
CONFIG_NLS_CODEPAGE_863=y
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
CONFIG_NLS_CODEPAGE_869=y
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
CONFIG_NLS_CODEPAGE_932=y
# CONFIG_NLS_CODEPAGE_949 is not set
CONFIG_NLS_CODEPAGE_874=y
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
CONFIG_NLS_ISO8859_2=y
# CONFIG_NLS_ISO8859_3 is not set
CONFIG_NLS_ISO8859_4=y
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
CONFIG_NLS_ISO8859_7=y
# CONFIG_NLS_ISO8859_9 is not set
CONFIG_NLS_ISO8859_13=y
CONFIG_NLS_ISO8859_14=y
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
CONFIG_NLS_KOI8_U=y
CONFIG_NLS_UTF8=y
#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_DEBUG_KERNEL is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_FS=y
# CONFIG_UNWIND_INFO is not set
CONFIG_EARLY_PRINTK=y
CONFIG_STACK_BACKTRACE_COLS=2
CONFIG_DOUBLEFAULT=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
# CONFIG_CRYPTO_WP512 is not set
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_586 is not set
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_TEST=y
#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set
#
# Library routines
#
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox