* Re: [PATCH] powermac: Fix some 64b resource damage
From: Greg KH @ 2006-07-02 4:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, linuxppc-dev list, Linus Torvalds, Paul Mackerras
In-Reply-To: <1151805303.19419.15.camel@localhost.localdomain>
On Sun, Jul 02, 2006 at 11:55:03AM +1000, Benjamin Herrenschmidt wrote:
> The 64 bits resource patches did a bit of damage on PowerMac causing a
> buffer overflow in macio_asic and a warning in a sound driver. The
> former is fixed by reverting the sprintf of the bus_id to %08x as it was
> before. The bus_id used for macio devices is always a 32 bits value
> (macio always sits in 32 bits space) and since it's exposed to userland,
> the format of the string shouldn't be changed like that anyway. The
> second by using the proper type for printk.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> Linus, please apply asap since right now, PowerMac overflows kobject
> buffers on boot, pretty bad.
Acked by me, sorry about this.
greg k-h
^ permalink raw reply
* Re: [PATCH] powerpc:Fix rheap alignment problem
From: Pantelis Antoniou @ 2006-07-02 5:18 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev list, Paul Mackerras, linux-kernel
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B07B36F@ismail.innsys.innovsys.com>
On Sunday 02 July 2006 06:54, Rune Torgersen wrote:
> From: Pantelis Antoniou
> Sent: Sat 7/1/2006 9:50 AM
> >Since genalloc is the blessed linux thing it might be best to use that & remove
> >rheap completely. Oh well...
>
> Two problems with genalloc that I can see (for CPM programming):
> 1) (minor) Does not have a way to specify alignment (genalloc does it for you)
> 2) (major problerm, at least for me) Does not have a way to allocate a specified address in the pool.
>
> 2 is needed esp when programming MCC drivers, since a lot of the datastructures must be in DP RAM _and_ be in a specific spot. And if you cannot tell the allocator that I am using a specific address, then the allocator might very well give somebody else that portion of RAM. The only solution without a fixed allocator is to allocate ALL memory in the DP RAM and use your own allocator.
>
Yeah, that too.
Too bad there are no main tree drivers like that, but they do exist.
One could conceivably hack genalloc to do that, but will end up with
something complex too.
BTW, there are other uEngine based architectures with similar alignment
requirements.
So in conclusion, for the in-tree drivers genalloc is sufficient as an cpm memory allocator.
For some out of tree drivers, it is not.
Pantelis
^ permalink raw reply
* Re: [PATCH] powerpc: Fix warning in cell setup.c
From: Andrew Morton @ 2006-07-02 6:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <1151814604.19419.20.camel@localhost.localdomain>
On Sun, 02 Jul 2006 14:30:04 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Fixes a warning due to a missing #include on cell
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Index: linux-irq-work/arch/powerpc/platforms/cell/setup.c
> ===================================================================
> --- linux-irq-work.orig/arch/powerpc/platforms/cell/setup.c 2006-07-01 15:25:33.000000000 +1000
> +++ linux-irq-work/arch/powerpc/platforms/cell/setup.c 2006-07-01 15:25:36.000000000 +1000
> @@ -49,6 +49,7 @@
> #include <asm/irq.h>
> #include <asm/spu.h>
> #include <asm/spu_priv1.h>
> +#include <asm/udbg.h>
>
> #include "interrupt.h"
> #include "iommu.h"
I already had that.
I don't know what to do with powerpc patches any more. Help.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix warning in cell setup.c
From: Benjamin Herrenschmidt @ 2006-07-02 6:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20060701230845.e2f8507d.akpm@osdl.org>
On Sat, 2006-07-01 at 23:08 -0700, Andrew Morton wrote:
> On Sun, 02 Jul 2006 14:30:04 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > Fixes a warning due to a missing #include on cell
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >
> > Index: linux-irq-work/arch/powerpc/platforms/cell/setup.c
> > ===================================================================
> > --- linux-irq-work.orig/arch/powerpc/platforms/cell/setup.c 2006-07-01 15:25:33.000000000 +1000
> > +++ linux-irq-work/arch/powerpc/platforms/cell/setup.c 2006-07-01 15:25:36.000000000 +1000
> > @@ -49,6 +49,7 @@
> > #include <asm/irq.h>
> > #include <asm/spu.h>
> > #include <asm/spu_priv1.h>
> > +#include <asm/udbg.h>
> >
> > #include "interrupt.h"
> > #include "iommu.h"
>
> I already had that.
>
> I don't know what to do with powerpc patches any more. Help.
If you already have it, drop it :) I didnt notice it was already there.
For trivialities like that, it doesn't matter. Important stuff goes
through paulus.
Ben.
^ permalink raw reply
* Re: sound connector detection
From: Richard Purdie @ 2006-07-02 9:28 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Liam Girdwood, Linux Kernel list, linuxppc-dev list, linux-input,
Johannes Berg, alsa-devel
In-Reply-To: <200607011609.59426.dtor@insightbb.com>
Hi,
On Sat, 2006-07-01 at 16:09 -0400, Dmitry Torokhov wrote:
> I am not too happy with putting this kind of switches into input layer,
> it should be reserved for "real" buttons, ones that user can explicitely
> push or toggle
Playing devil's advocate, by inserting a headphone cable, you push the
switch - the user can explicitly control that switch but inserting or
removing the cable...
> (lid switch is on the edge here but it and sleep button
> are used for similar purposes so it makes sense to have it in input layer
> too). But "cable X connected" kind of events is too much [for input layer,
> there could well be a separate layer for it]. If we go this way we'd have
> to move cable detection code from network to input layer as well ;)
I have mixed feelings about this and can see it from both sides. In a
lot of cases, we need to report these "switch" events to userspace as
only userspace can determine the correct action. Taking some examples,
just from the Zaurus:
Upon lid closure should:
- the screen/backlight be turned off?
- the device suspended?
Upon insertion of a headphone jack should:
- the external speaker be turned on/off?
- does the jack connect to headphones, a headset, mic or line in
source? (no autodetection so the user has to select and only then can
the mixer be appropriately configured)
Only userspace can make these decisions so we need to pass them there so
it can decide how to handle things. In the case of the Zaurus, we have a
program called zaurusd which listens for the events and knows how to
handle them (http://svn.o-hand.com/view/misc/trunk/zaurusd/). It turns
these events into something the user can influence with scripts.
There is also a question of which USB client to load when USB client is
detected - again, this insertion event really needs to be passed to
userspace for a decision. I've not touched this issue yet and adding
switch events for client cable detection would probably get frowned
upon?
One thing the input system does well is pass simple switch events to
userspace though its event devices. Not using the input system for
switch like events like these is going to result in code duplication.
I can understand the concern with not wanting to fill the input
subsystem with events that have a tenuous relationship to input devices.
Perhaps the solution is to separate the events layer from the input
layer and start to allow it to handle more generic events?
One of the issues is the ownership of the events data. Currently, you
can't tag a given source of events to a given soundcard. Perhaps each
soundcard would create a separate events device but we need to think
about things like this. Some switch events have no real parent (like the
lid switch on the Zaurus which if anything does belong to the keyboard
driver). Others like the headphone switch on the zaurus arguably belong
to the ASoC sound device (not in mainline yet but coming soon).
In the audio case, there is perhaps an argument for some kind of
scenarios handling where the mixer has some predefined states which get
activated given certain circumstances. The Zaurus ASoC implementations
already sort of implement this having controls which set the headphone
jack mode (headphones, headset, mic, line, off). There is still a need
to ask userspace what was inserted though which requires some kind of
event system.
Even if the audio situation improves, it doesn't solve the general event
case either. Can anyone see a way forward? Would some kind of generic
event code that any device could add to its sysfs directory work? Could
such a thing be abstracted from the input system code?
Richard
^ permalink raw reply
* RE: rs232 endianness on PPC
From: Antonio Di Bacco @ 2006-07-02 10:10 UTC (permalink / raw)
To: linuxppc-embedded
PowerPC is neither byte swapped nor bit swapped.
When transmitting on a network card the most significant byte is transmitted
first, and, inside the byte, the most significant bit is sent first.
RS232 is an exception: LSB is sent first.
^ permalink raw reply
* [PATCH 2.6.17] Add -fno-stack-protector to BOOTCFLAGS in arch/powerpc/boot/Makefile.
From: Niels Kristian Bech Jensen @ 2006-07-02 11:02 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 389 bytes --]
I got some undefined references to __stack_chk_fail in
arch/powerpc/boot/stdio.o and arch/powerpc/boot/prom.o when I was trying
to build a kernel on Ubuntu Edgy Eft - which includes Stack Smashing
Protection.
This patch adds -fno-stack-protector to BOOTCFLAGS in
arch/powerpc/boot/Makefile (why does BOOTCFLAGS depend on HOSTCFLAGS and
not CFLAGS?).
Regards,
Niels Kristian Bech Jensen
[-- Attachment #2: powerpc-2.6.17.diff --]
[-- Type: text/x-patch, Size: 492 bytes --]
--- linux-source-2.6.17/arch/powerpc/boot/Makefile~ 2006-06-29 03:23:03.000000000 +0200
+++ linux-source-2.6.17/arch/powerpc/boot/Makefile 2006-07-02 12:44:34.000000000 +0200
@@ -41,6 +41,10 @@ src-boot += $(zlib)
src-boot := $(addprefix $(obj)/, $(src-boot))
obj-boot := $(addsuffix .o, $(basename $(src-boot)))
+ifeq ($(call cc-option-yn, -fstack-protector),y)
+BOOTCFLAGS += -fno-stack-protector
+endif
+
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
quiet_cmd_copy_zlib = COPY $@
^ permalink raw reply
* Problem booting Linux on MPC8XXFADS
From: Hamid Marshall @ 2006-07-02 21:41 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: boehringer
[-- Attachment #1: Type: text/plain, Size: 167 bytes --]
Hi Sven,
Were you able to resolve your Linux boot problem on this board. Let me know
what steps you took to resolve this.
Thanks,
Hamid Marshall
[-- Attachment #2: Type: text/html, Size: 2915 bytes --]
^ permalink raw reply
* Re: sound connector detection
From: Dmitry Torokhov @ 2006-07-03 2:48 UTC (permalink / raw)
To: Richard Purdie
Cc: Liam Girdwood, Linux Kernel list, linuxppc-dev list, linux-input,
Johannes Berg, alsa-devel
In-Reply-To: <1151832510.5536.32.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 897 bytes --]
On Sunday 02 July 2006 05:28, Richard Purdie wrote:
> One thing the input system does well is pass simple switch events to
> userspace though its event devices. Not using the input system for
> switch like events like these is going to result in code duplication.
>
I think that hotplug/uevent like mechanism would be better suited here.
You want to monitor changes in system state and you do not really want
to monitor myriad of devices but just latch onto one data feed and get
all the data from it (unlike input devices where you might want to
separate data coming from different devices). The following "event"
might be a good starting point:
struct system_change_event {
struct timeval time; /* look for 32/64 bit issues */
__u16 type;
__u16 code;
__s32 value;
char object_path[224];
};
Maybe we should start looking into connector or a pure netlink implementation.
--
Dmitry
[-- Attachment #2: Type: text/html, Size: 1217 bytes --]
^ permalink raw reply
* RE: [PATCH] Add QE device tree definition
From: Li Yang-r58472 @ 2006-07-03 6:17 UTC (permalink / raw)
To: Fleming Andy-afleming; +Cc: linuxppc-dev
> -----Original Message-----
> From: Fleming Andy-afleming
> Sent: Saturday, July 01, 2006 1:55 AM
> To: Li Yang-r58472
> Cc: 'Kumar Gala'; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Add QE device tree definition
>
>
> On Jun 29, 2006, at 22:36, Li Yang-r58472 wrote:
>
> >>> +
> >>> +
> >>> + 2) SPI (Serial Peripheral Interface)
> >>> +
> >>> + Required properties:
> >>> + - device_type : should be "spi".
> >>> + - compatible : should be "fsl_spi".
> >>> + - mode : the spi operation mode, it can be "cpu" or "qe".
> >>
> >> What does it mean for the spi to be in "qe" mode?
> > That means:
> > The SPI can operate in QE mode or in CPU mode. In QE mode SPI is
> > compatible to the MPC826x SPI, and is controlled by QE RISC. In CPU
> > mode, the SPI is controlled wholly by the CPU without any QE RISC
> > intervention.
>
>
> Doesn't that mean the "cpu" SPI isn't part of the QE device? I kind
> of feel like it shouldn't be part of the QE node, then. Or is it
> actually one device that can act in two different modes?
Yes, it is actually one device with two modes, sharing the same set of registers within QE memory map region. So it best lives in QE node.
>
>
> >
> >>
> >>> + - reg : offset to the register set and its length.
> >>> + - interrupts : <a b> where a is the interrupt number and b is a
> >>> + field that represents an encoding of the sense and level
> >>> + information for the interrupt. This should be encoded
> >>> based on
> >>> + the information in section 2) depending on the type of
> >>> interrupt
> >>> + controller you have.
> >>> + - interrupt-parent : the phandle for the interrupt controller
> >>> that
> >>> + services interrupts for this device.
> >>> +
> >>> + Example:
> >>> + spi@4c0 {
> >>> + device_type = "spi";
> >>> + compatible = "fsl_spi";
> >>> + reg = <4c0 40>;
> >>> + interrupts = <82 0>;
> >>> + interrupt-parent = <700>;
> >>> + mode = "cpu";
> >>> + };
> >>> +
> >>
> >> How do we tell the difference between the various spi controllers. I
> >> think we have four of them, three of which are probably pretty
> >> similar. We have the 834x spi, and QE, CPM1, CPM2 SPI.
> >>
> >>> +
> >>> + 3) USB (Universal Serial Bus Controller)
> >>> +
> >>> + Required properties:
> >>> + - device_type : should be "usb".
> >>> + - compatible : could be "qe_udc" or "fhci-hcd".
> >>> + - model : the could be "host" or "slave".
> >>
> >> got a 'l' on mode, if we are slave should we provide more info about
> >> what kinda slave we are (ie, what gadget driver should apply).
> >>
> >>> + - reg : there will be two tuples of "address size". The first
> >>> tuple is
> >>> + offset and length of the device registers respectively; the
> >>> second is
> >>> + offset and length of the device parameter RAM respectively.
> >>> + - interrupts : <a b> where a is the interrupt number and b is a
> >>> + field that represents an encoding of the sense and level
> >>> + information for the interrupt. This should be encoded
> >>> based on
> >>> + the information in section 2) depending on the type of
> >>> interrupt
> >>> + controller you have.
> >>> + - interrupt-parent : the phandle for the interrupt controller
> >>> that
> >>> + services interrupts for this device.
> >>> +
> >>> + Example(slave):
> >>> + usb@6c0 {
> >>> + device_type = "usb";
> >>> + compatible = "qe_udc";
> >>> + reg = <6c0 40 8B00 100>;
> >>> + interrupts = <8b 0>;
> >>> + interrupt-parent = <700>;
> >>> + mode = "slave";
> >>> + };
> >>> +
> >>> +
> >>> + 4) UCC (Unified Communications Controllers)
> >>
> >> Why dont you create a sub section for network, and in the future
> >> additional subsections can be added for the different device_types.
> >>
> >>> +
> >>> + Required properties:
> >>> + - device_type : should be "network", "hldc", "uart",
> >>> "transparent"
> >>> + "bisync" or "atm".
> >>> + - compatible : could be "ucc_geth" or "fsl_atm" and so on.
> >>> + - model : should be "UCC".
> >>> + - device-id : the ucc number(1-8), corresponding to UCCx in UM.
> >>> + - reg : there will be two tuples of "address size". The first
> >>> tuple is
> >>> + offset and length of the device registers respectively; the
> >>> second is
> >>> + offset and length of the device parameter RAM respectively.
> >>> + - interrupts : <a b> where a is the interrupt number and b is a
> >>> + field that represents an encoding of the sense and level
> >>> + information for the interrupt. This should be encoded
> >>> based on
> >>> + the information in section 2) depending on the type of
> >>> interrupt
> >>> + controller you have.
> >>> + - interrupt-parent : the phandle for the interrupt controller
> >>> that
> >>> + services interrupts for this device.
> >>> + - pio-handle : The phandle for the Parallel I/O port
> >>> configuration.
> >>> +
> >>> + Required properties for network device_type:
> >>> + - mac-address : list of bytes representing the ethernet address.
> >>> + - rx-clock : a string represents the UCC receive clock source.
> >>> + "brgx" : clock source is BRG1~BRG16 respectively;
> >>> + "clkx" : clock source is QE_CLK1~QE_CLK24 respectively.
> >>> + others : clock source is disabled;
> >>> + - tx-clock: a string represents the UCC transmit clock source;
> >>> + "brgx" : clock source is BRG1~BRG16 respectively;
> >>> + "clkx" : clock source is QE_CLK1~QE_CLK24 respectively.
> >>> + others : clock source is disabled;
> >>> + - phy-handle : The phandle for the PHY connected to this
> >>> controller.
> >>> +
> >>> + Example:
> >>> + ucc@2000 {
> >>> + device_type = "network";
> >>> + compatible = "ucc_geth";
> >>> + model = "UCC";
> >>> + device-id = <1>;
> >>> + reg = <2000 200 8400 100>;
> >>> + interrupts = <a0 0>;
> >>> + interrupt-parent = <700>;
> >>> + mac-address = [ 00 04 9f 00 23 23 ];
> >>> + rx-clock = "none";
> >>> + tx-clock = "clk9";
> >>> + phy-handle = <212000>;
> >>> + pio-handle = <140001>;
> >>> + };
> >>> +
> >>> +
> >>> + 5) Parallel I/O Ports
> >>> +
> >>> + This node configures Parallel I/O ports for CPUs with QE
> >>> support.
> >>> + The node should reside in the "soc" node of the tree. For each
> >>> + device that using parallel I/O ports, a child node should be
> >>> created.
> >>> + See the definition of the Pin configuration nodes below for more
> >>> + information.
> >>> +
> >>> + Required properties:
> >>> + - device_type : should be "par_io".
> >>> + - reg : offset to the register set and its length.
> >>> +
> >>> + Example:
> >>> + par_io@1400 {
> >>> + reg = <1400 100>;
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> + device_type = "par_io";
> >>> + ucc_pin@01 {
> >>> + ......
> >>> + };
> >>> +
> >>
> >> Can you explain this further, I'm not getting the relationship
> >> between a par_io & ucc_pin. An example maybe helpful.
> >
> > Each QE device needs to configure Parallel I/O Ports pin
> > configuration in order to work, for example the configuration for
> > ucc1 is ucc_pin@01. par_io is a container for all these
> > configurations and gives the base for parallel io port register. I
> > will paste dts file for 8360 to give an example.
> >>
> >>> +
> >>> + 6) Pin configuration nodes
> >>> +
> >>> + Required properties:
> >>> + - linux,phandle : phandle of this node; likely referenced by
> >>> a QE
> >>> + device.
> >>> + - pio-map : array of pin configurations. Each pin is defined
> >>> by 6
> >>> + integers. The six numbers are respectively: port, pin, dir,
> >>> + open_drain, assignment, has_irq.
> >>> + - port : port number of the pin; 0-6 represent port A-G in UM.
> >>> + - pin : pin number in the port.
> >>> + - dir : direction of the pin, should encode as follows:
> >>> +
> >>> + 0 = The pin is disabled
> >>> + 1 = The pin is an output
> >>> + 2 = The pin is an input
> >>> + 3 = The pin is I/O
> >>> +
> >>> + - open_drain : indicates the pin is normal or wired-OR:
> >>> +
> >>> + 0 = The pin is actively driven as an output
> >>> + 1 = The pin is an open-drain driver. As an output, the pin is
> >>> + driven active-low, otherwise it is three-stated.
> >>> +
> >>> + - assignment : function number of the pin according to the
> >>> Pin Assignment
> >>> + tables in User Manual. Each pin can have up to 4 possible
> >>> functions in
> >>> + QE and two options for CPM.
> >>> + - has_irq : indicates if the pin is used as source of exteral
> >>> + interrupts.
> >>> +
> >>> + Example:
> >>> + ucc_pin@01 {
> >>> + linux,phandle = <140001>;
> >>> + pio-map = <
> >>> + /* port pin dir open_drain assignment has_irq */
> >>> + 0 3 1 0 1 0 /* TxD0 */
> >>> + 0 4 1 0 1 0 /* TxD1 */
> >>> + 0 5 1 0 1 0 /* TxD2 */
> >>> + 0 6 1 0 1 0 /* TxD3 */
> >>> + 1 6 1 0 3 0 /* TxD4 */
> >>> + 1 7 1 0 1 0 /* TxD5 */
> >>> + 1 9 1 0 2 0 /* TxD6 */
> >>> + 1 a 1 0 2 0 /* TxD7 */
> >>> + 0 9 2 0 1 0 /* RxD0 */
> >>> + 0 a 2 0 1 0 /* RxD1 */
> >>> + 0 b 2 0 1 0 /* RxD2 */
> >>> + 0 c 2 0 1 0 /* RxD3 */
> >>> + 0 d 2 0 1 0 /* RxD4 */
> >>> + 1 1 2 0 2 0 /* RxD5 */
> >>> + 1 0 2 0 2 0 /* RxD6 */
> >>> + 1 4 2 0 2 0 /* RxD7 */
> >>> + 0 7 1 0 1 0 /* TX_EN */
> >>> + 0 8 1 0 1 0 /* TX_ER */
> >>> + 0 f 2 0 1 0 /* RX_DV */
> >>> + 0 10 2 0 1 0 /* RX_ER */
> >>> + 0 0 2 0 1 0 /* RX_CLK */
> >>> + 2 9 1 0 3 0 /* GTX_CLK - CLK10 */
> >>> + 2 8 2 0 1 0>; /* GTX125 - CLK9 */
> >>> + };
> >>> +
> >>> +
> >>> More devices will be defined as this spec matures.
> >>>
> >>>
> >>> _______________________________________________
> >>> Linuxppc-dev mailing list
> >>> Linuxppc-dev@ozlabs.org
> >>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Florian Boelstler @ 2006-07-03 6:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306DD12EC@zch01exm40.ap.freescale.net>
Hi,
Zhang Wei-r63237 schrieb:
> Yes, I think so. You can plug a PCIe ethernet card to test it.
A single device always works.
> :-), Maybe it's need more study. Could you enable the DEBUG and post the kernel verbose message?
We added lots of debug output and made some modifications (mostly delays
between calls to early_read_config_dword() and
early_write_config_dword() in pci_auto.c) and came to the conclusion
that generic bridge devices (PCIe-to-PCI), even in a cascaded setup of
three bridges, work fine.
However a PCIe switch (PLX8516/8532) doesn't work. The MPC8548 only
detects a single device (i.e. primary side of the switch).
We are going to analyze the problem more deeply soon. It seems that the
configuration space of that devices isn't properly set up.
The provided patch doesn't make any difference, besides that it is moved
to a location where the PPC itself is not detected.
Please keep us informed if there is any progress besides Freescale, as I
will do.
Cheers,
Florian
^ permalink raw reply
* How do you set up a PPC440GX with a PHY on emac2 only?
From: Howard, Marc @ 2006-07-03 5:41 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
Hi,
Does anyone have any pointers/tips on how to set up a ocotea-like PPC440GX design with only a single gigabit (Cicada) PHY on emac2? Editing ocotea_set_emacdata() to just define a single PHY doesn't work correctly. It looks like this has something to do with the MII communtications being on the ZMII bridge on emac0 but defining emac0 doesn't help either.
Thanks,
Marc W. Howard
[-- Attachment #2: Type: text/html, Size: 829 bytes --]
^ permalink raw reply
* How do you set up a PPC440GX with a PHY on emac2 only?
From: Howard, Marc @ 2006-07-03 5:41 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
Hi,
Does anyone have any pointers/tips on how to set up a ocotea-like PPC440GX design with only a single gigabit (Cicada) PHY on emac2? Editing ocotea_set_emacdata() to just define a single PHY doesn't work correctly. It looks like this has something to do with the MII communtications being on the ZMII bridge on emac0 but defining emac0 doesn't help either.
Thanks,
Marc W. Howard
[-- Attachment #2: Type: text/html, Size: 829 bytes --]
^ permalink raw reply
* RE: [PATCH] powerpc:Fix rheap alignment problem
From: Li Yang-r58472 @ 2006-07-03 6:49 UTC (permalink / raw)
To: 'Pantelis Antoniou', Rune Torgersen
Cc: linuxppc-dev list, Paul Mackerras, linux-kernel
Buddy allocation is good in general, but doesn't mean it fits best in any condition. In this case for managing DPRAM/MURAM in Freescale soc, in most case we only put buffer descriptor in DPRAM. That means the alloc/free only occurs on initialization and unloading of the driver. So there are not supposed to be a lot of free operations. Buddy allocation will cause more internal fragment, in my humble opinion. And a free-list allocation is best fit in this case.
Best Regards,
Leo
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org] On Behalf Of
> Pantelis Antoniou
> Sent: Sunday, July 02, 2006 1:18 PM
> To: Rune Torgersen
> Cc: linuxppc-dev list; Paul Mackerras; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] powerpc:Fix rheap alignment problem
>
> On Sunday 02 July 2006 06:54, Rune Torgersen wrote:
> > From: Pantelis Antoniou
> > Sent: Sat 7/1/2006 9:50 AM
> > >Since genalloc is the blessed linux thing it might be best to use that &
> remove
> > >rheap completely. Oh well...
> >
> > Two problems with genalloc that I can see (for CPM programming):
> > 1) (minor) Does not have a way to specify alignment (genalloc does it for
> you)
> > 2) (major problerm, at least for me) Does not have a way to allocate a specified
> address in the pool.
> >
> > 2 is needed esp when programming MCC drivers, since a lot of the datastructures
> must be in DP RAM _and_ be in a specific spot. And if you cannot tell the
> allocator that I am using a specific address, then the allocator might very
> well give somebody else that portion of RAM. The only solution without a fixed
> allocator is to allocate ALL memory in the DP RAM and use your own allocator.
> >
>
> Yeah, that too.
>
> Too bad there are no main tree drivers like that, but they do exist.
>
> One could conceivably hack genalloc to do that, but will end up with
> something complex too.
>
> BTW, there are other uEngine based architectures with similar alignment
> requirements.
>
> So in conclusion, for the in-tree drivers genalloc is sufficient as an cpm
> memory allocator.
> For some out of tree drivers, it is not.
>
> Pantelis
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Zhang Wei-r63237 @ 2006-07-03 7:54 UTC (permalink / raw)
To: Florian Boelstler, linuxppc-embedded
Hi,
> -----Original Message-----
> From:
> linuxppc-embedded-bounces+wei.zhang=freescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+wei.zhang=freescale.com@ozla
> bs.org] On Behalf Of Florian Boelstler
> Sent: Monday, July 03, 2006 2:38 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
>
> Hi,
>
> Zhang Wei-r63237 schrieb:
> > Yes, I think so. You can plug a PCIe ethernet card to test it.
>
> A single device always works.
>
> > :-), Maybe it's need more study. Could you enable the DEBUG
> and post the kernel verbose message?
>
> We added lots of debug output and made some modifications
> (mostly delays between calls to early_read_config_dword() and
> early_write_config_dword() in pci_auto.c) and came to the
> conclusion that generic bridge devices (PCIe-to-PCI), even in
> a cascaded setup of three bridges, work fine.
Yea, that's a good news.
>
> However a PCIe switch (PLX8516/8532) doesn't work. The
> MPC8548 only detects a single device (i.e. primary side of
> the switch).
> We are going to analyze the problem more deeply soon. It
> seems that the configuration space of that devices isn't
> properly set up.
Just a suggestion.
Do you see below codes in mpc85xx_pex_errata.c(in read and write functions)?
if (devfn != 0x0)
return PCIBIOS_DEVICE_NOT_FOUND;
Change them to:
if (devfn != 0x0 && bus->number ==0)
return PCIBIOS_DEVICE_NOT_FOUND;
And try again. :-)
(If you apply my patch, please use "if (devfn != 0x0 && bus->number ==0xff)" )
>
> The provided patch doesn't make any difference, besides that
> it is moved to a location where the PPC itself is not detected.
>
This patch fix an issue of MPC8641 PCI-Ex controller. It seems MPC8548 has no that issue. Well then fotget it.
Thanks!
Zhang Wei
> Please keep us informed if there is any progress besides
> Freescale, as I will do.
>
> Cheers,
>
> Florian
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Xilinx SystemACE driver for 2.6
From: Ameet Patil @ 2006-07-03 9:05 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0606301302u5922945dycda569e6954fa353@mail.gmail.com>
Hi Grant,
I totally agree with you. What you say is correct. It will
definitely kill the CF card. I use a XUPV2PRO board which doesn't come
with a microdrive and for my research SWAP is a must. :-)
However, I shall add a NOTE in the article mentioning the same.
Thanks a lot,
-Ameet
Grant Likely wrote:
> On 6/30/06, Ameet Patil <ammubhai@gmail.com> wrote:
>> Here is PART I of the article:
>> http://www.linux.get2knowmore.com/2006/06/30/quick-guide-linux-26-on-xilinx-virtex-ii-pro-boards-part-i/
>>
>>
>> Let me know if you get messages at boot time after following the above...
>
> Quick comment on your article; unless you're using a microdrive;
> *PLEASE* don't recommend using compact flash as swap space. Flash
> technology has limited write cycles (on the order of 100k to 1M cycles
> per block). Using it as swap is a great way to kill the lifecycle of
> your device.
>
> (the ML300 ships with a microdrive; the ML40x ships with a regular CF card)
>
> I know the previous article also recommends a swap partition, but
> Linux will happily run without swap.
>
> Cheers,
> g.
>
^ permalink raw reply
* Re: JFFS2 FS is read-only (not what I want)
From: Mathieu Deschamps @ 2006-07-03 10:42 UTC (permalink / raw)
To: Ben Warren, linuxppc-embedded
In-Reply-To: <44A6E57A.3080302@qstreams.com>
Hello Ben,
On Saturday 01 July 2006 23:13, Ben Warren wrote:
> Hello,
>
> When I boot from a JFFS2 file system on my eval board, the file system
> is effectively read-only, and I can't figure out why. I'm pretty sure
> the kernel's configured for R/W MTD block access. Any help is greatly
> appreciated.
>
Do you mean that you can't even created a void file on / as root ? Else
can you then put for instance text in it ? My point is can or can't you
first create a new fs node and then can you write to file your
changes, that's two possible causes.
>
> The hardware in use is:
>
> Freescale MPC8349EMDS eval board.
> 8MB Q-flash with 64 uniform 128k sectors
>
[...]
> # mount
> /dev/mtdblock4 on / type jffs2 (rw)
> /proc on /proc type proc (rw)
>
[...]
>
> I created the MTD partitions in a u-boot image that was pulled from the
Yes indeed what about drivers/mtd/maps/physmap.c ? your parts are
mask_flags: MTD_WRITEB_WRITEABLE and not MTD_CAP_ROM,
aren't they ?
> GIT tree about a week ago, and my kernel is 2.6.17-based. I wrote some
> board init code that sets the MTD physical mappings.
>
> Here are the MTD and JFFS2 parts of my .config file:
>
> ***
> # Memory Technology Devices (MTD)
> #
> CONFIG_MTD=y
> # CONFIG_MTD_DEBUG is not set
> # CONFIG_MTD_CONCAT is not set
> CONFIG_MTD_PARTITIONS=y
> # CONFIG_MTD_REDBOOT_PARTS is not set
> # CONFIG_MTD_CMDLINE_PARTS is not set
>
[...]
> # CONFIG_JFFS_FS is not set
> CONFIG_JFFS2_FS=y
Better avoid redundacy but this is not a clue, I guess
make won't be fooled by this.
> CONFIG_JFFS2_FS_DEBUG=0
> # CONFIG_JFFS2_FS_WRITEBUFFER is not set
> # CONFIG_JFFS2_SUMMARY is not set
> # CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
> CONFIG_JFFS2_ZLIB=y
> CONFIG_JFFS2_RTIME=y
> # CONFIG_JFFS2_RUBIN is not set
> ***
>
> The file system is the SELF that is included with DENX's ELDK, and built
> as at:
> http://www.denx.de/wiki/view/DULG/RootFileSystemDesignAndBuilding
>
> I used the following command to create the file system image, that was
>
> then loaded at address 0xfe480000 via U-boot:
> > mkfs.jffs2 -U -d rootfs -D rootfs_device.tab -b -e 0x20000 -o jffs2.img
>
IMHO, it's not a generation-time issue
>
[...]
That's all I have for now. Good luck.
Regards,
Mathieu Deschamps
Com2gether Design Center
Electronic and Embedded Engineering Services
www.com2gether.net
^ permalink raw reply
* Re: [PATCH] powerpc:Fix rheap alignment problem
From: Benjamin Herrenschmidt @ 2006-07-03 11:08 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-dev list, Paul Mackerras, linux-kernel
In-Reply-To: <200607020818.27603.pantelis.antoniou@gmail.com>
On Sun, 2006-07-02 at 08:18 +0300, Pantelis Antoniou wrote:
> On Sunday 02 July 2006 06:54, Rune Torgersen wrote:
> > From: Pantelis Antoniou
> > Sent: Sat 7/1/2006 9:50 AM
> > >Since genalloc is the blessed linux thing it might be best to use that & remove
> > >rheap completely. Oh well...
> >
> > Two problems with genalloc that I can see (for CPM programming):
> > 1) (minor) Does not have a way to specify alignment (genalloc does it for you)
> > 2) (major problerm, at least for me) Does not have a way to allocate a specified address in the pool.
> >
> > 2 is needed esp when programming MCC drivers, since a lot of the datastructures must be in DP RAM _and_ be in a specific spot. And if you cannot tell the allocator that I am using a specific address, then the allocator might very well give somebody else that portion of RAM. The only solution without a fixed allocator is to allocate ALL memory in the DP RAM and use your own allocator.
> >
>
> Yeah, that too.
>
> Too bad there are no main tree drivers like that, but they do exist.
>
> One could conceivably hack genalloc to do that, but will end up with
> something complex too.
>
> BTW, there are other uEngine based architectures with similar alignment
> requirements.
>
> So in conclusion, for the in-tree drivers genalloc is sufficient as an cpm memory allocator.
> For some out of tree drivers, it is not.
Sounds like a good enough justification to keep rheap for now then.
Ben.
^ permalink raw reply
* Re: Problem with Xilinx Uart Lite
From: Qichen Huang @ 2006-07-03 10:59 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: linuxppc-embedded
In-Reply-To: <44A5178A.5050808@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]
Hello Andrei,
Thank you. I have tried this patch, but without luck, the system can not
start, there's no login prompt.
Boot stopps after starting system.
The boot log looks like this:
loaded at: 00400000 004C51E0
board data at: 004C2138 004C2150
relocated to: 0040530C 00405324
zimage at: 00405811 004C1A00
avail ram: 004C6000 04000000
Linux/PPC load: console=ttl0 ip=off root=/dev/xsysace/disc0/part3 rw
Uncompressing Linux...done.
Now booting the kernel
......
Welcome to ML300 powerpc linux 2.4.21, E.I.S. edition
Starting system...
mounting /proc: done.
Mounting '/' read-write: mount: Cannot read /etc/mtab: No such file or
directory
done.
brining up loopback interface: done.
Setup IP-address for eth0: done.
Mounting /tmp: done.
Starting syslogd: done.
Starting klogd: done.
Starting
Thanks,
Qichen
ps. Sorry, I forgot to post this to the mailing list.
On 6/30/06, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
>
> Seeing a lot of ^M (LF) characters in the end of lines makes me think
> you are using [Win]DOS.
> This makes the patch to look somewhat funny - some of the lines terminated
> with
> <CR> only ("Unix style"), some - with <CR><LF> ("DOS style").
>
> Please try the attached patch. It should help.
>
> Thanks,
> Andrei
>
> Qichen Huang wrote:
> > Hello,
> >
> > attached is my xuartlite_serial.c
> >
> > Thanks,
> > Qichen
> >
> > On 6/30/06, *Andrei Konovalov* <akonovalov@ru.mvista.com
> > <mailto:akonovalov@ru.mvista.com>> wrote:
> >
> > > Xilinx OS Independent Code XAssert: xuartlite.c:194
> > > Code may crash due to unhandled errors.
> >
> > So this is inside XUartLite_Send().
> > Could you send me your xuartlite_serial.c?
> > Seems yours doesn't have one of the fixes.
> >
> > Thanks,
> > Andrei
>
>
>
[-- Attachment #2: Type: text/html, Size: 2681 bytes --]
^ permalink raw reply
* please pull powerpc.git 'master' branch
From: Paul Mackerras @ 2006-07-03 12:04 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from the "master" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
to get Ben's patches moving powerpc over to genirq, and three other
minor changes. The kernel/irq/chip.c change has been acked by Ingo
Molnar and Thomas Gleixner.
Thanks,
Paul.
Benjamin Herrenschmidt:
[POWERPC] Fix various offb and BootX-related issues
[POWERPC] Fix booting on Momentum "Apache" board (a Maple derivative)
[POWERPC] Fix error handling in detecting legacy serial ports
[POWERPC] Update the SWIM3 (powermac) floppy driver
genirq: Allow fasteoi handler to retrigger disabled interrupts
[POWERPC] Use the genirq framework
[POWERPC] New device-tree interrupt parsing code
[POWERPC] Copy i8259 code back to arch/ppc
[POWERPC] Add new interrupt mapping core and change platforms to use it
Dave Jones:
[POWERPC] fix implicit declaration on cell.
Jeremy Kerr:
[POWERPC] change get_property to return void *
Paul Mackerras:
[POWERPC] Add a default config for 32-bit CHRP machines
arch/powerpc/configs/chrp32_defconfig | 1378 ++++++++++++++++++++++++++
arch/powerpc/kernel/btext.c | 20
arch/powerpc/kernel/ibmebus.c | 9
arch/powerpc/kernel/irq.c | 659 ++++++++++--
arch/powerpc/kernel/legacy_serial.c | 57 +
arch/powerpc/kernel/misc_64.S | 10
arch/powerpc/kernel/pci_32.c | 37 +
arch/powerpc/kernel/pci_64.c | 33 -
arch/powerpc/kernel/prom.c | 454 ---------
arch/powerpc/kernel/prom_init.c | 20
arch/powerpc/kernel/prom_parse.c | 443 ++++++++
arch/powerpc/kernel/rtas_pci.c | 17
arch/powerpc/kernel/setup_32.c | 2
arch/powerpc/kernel/setup_64.c | 17
arch/powerpc/kernel/vio.c | 12
arch/powerpc/platforms/cell/interrupt.c | 419 ++++----
arch/powerpc/platforms/cell/interrupt.h | 19
arch/powerpc/platforms/cell/setup.c | 22
arch/powerpc/platforms/cell/spider-pic.c | 394 +++++--
arch/powerpc/platforms/cell/spu_base.c | 119 +-
arch/powerpc/platforms/chrp/pci.c | 11
arch/powerpc/platforms/chrp/setup.c | 101 +-
arch/powerpc/platforms/chrp/smp.c | 1
arch/powerpc/platforms/iseries/irq.c | 105 +-
arch/powerpc/platforms/iseries/irq.h | 2
arch/powerpc/platforms/iseries/setup.c | 8
arch/powerpc/platforms/maple/pci.c | 17
arch/powerpc/platforms/maple/setup.c | 94 +-
arch/powerpc/platforms/powermac/bootx_init.c | 33 +
arch/powerpc/platforms/powermac/low_i2c.c | 9
arch/powerpc/platforms/powermac/nvram.c | 5
arch/powerpc/platforms/powermac/pci.c | 68 +
arch/powerpc/platforms/powermac/pfunc_base.c | 13
arch/powerpc/platforms/powermac/pic.c | 422 ++++----
arch/powerpc/platforms/powermac/pmac.h | 2
arch/powerpc/platforms/powermac/setup.c | 3
arch/powerpc/platforms/pseries/ras.c | 82 +-
arch/powerpc/platforms/pseries/setup.c | 244 +++--
arch/powerpc/platforms/pseries/smp.c | 32 -
arch/powerpc/platforms/pseries/xics.c | 718 ++++++++------
arch/powerpc/platforms/pseries/xics.h | 17
arch/powerpc/sysdev/Makefile | 5
arch/powerpc/sysdev/i8259.c | 163 ++-
arch/powerpc/sysdev/mpic.c | 482 ++++++---
arch/ppc/syslib/Makefile | 2
drivers/block/swim3.c | 230 ++--
drivers/char/hvsi.c | 7
drivers/macintosh/macio-adb.c | 19
drivers/macintosh/macio_asic.c | 152 ++-
drivers/macintosh/smu.c | 6
drivers/macintosh/via-cuda.c | 24
drivers/macintosh/via-pmu.c | 33 -
drivers/net/mace.c | 4
drivers/serial/pmac_zilog.c | 6
drivers/video/offb.c | 284 ++---
include/asm-powerpc/i8259.h | 8
include/asm-powerpc/irq.h | 358 ++++++-
include/asm-powerpc/machdep.h | 2
include/asm-powerpc/mpic.h | 67 +
include/asm-powerpc/prom.h | 98 ++
include/asm-powerpc/spu.h | 1
kernel/irq/chip.c | 5
sound/aoa/core/snd-aoa-gpio-feature.c | 7
sound/aoa/soundbus/i2sbus/i2sbus-core.c | 7
sound/oss/dmasound/dmasound_awacs.c | 16
sound/ppc/pmac.c | 33 -
sound/ppc/tumbler.c | 8
67 files changed, 5412 insertions(+), 2743 deletions(-)
create mode 100644 arch/powerpc/configs/chrp32_defconfig
^ permalink raw reply
* RE: [PATCH] powerpc:Fix rheap alignment problem
From: Li Yang-r58472 @ 2006-07-03 12:19 UTC (permalink / raw)
To: 'Benjamin Herrenschmidt', Pantelis Antoniou
Cc: linuxppc-dev list, Paul Mackerras, linux-kernel
> > > Two problems with genalloc that I can see (for CPM programming):
> > > 1) (minor) Does not have a way to specify alignment (genalloc does it for
> you)
> > > 2) (major problerm, at least for me) Does not have a way to allocate a
> specified address in the pool.
> > >
> > > 2 is needed esp when programming MCC drivers, since a lot of the
> datastructures must be in DP RAM _and_ be in a specific spot. And if you cannot
> tell the allocator that I am using a specific address, then the allocator might
> very well give somebody else that portion of RAM. The only solution without
> a fixed allocator is to allocate ALL memory in the DP RAM and use your own
> allocator.
> > >
> >
> > Yeah, that too.
> >
> > Too bad there are no main tree drivers like that, but they do exist.
> >
> > One could conceivably hack genalloc to do that, but will end up with
> > something complex too.
> >
> > BTW, there are other uEngine based architectures with similar alignment
> > requirements.
> >
> > So in conclusion, for the in-tree drivers genalloc is sufficient as an cpm
> memory allocator.
> > For some out of tree drivers, it is not.
>
> Sounds like a good enough justification to keep rheap for now then.
As the reason I stated in the last mail, rheap should continue being used not only for this fix-address situation but also for CPM/QE buffer descriptor management. Rheap and genalloc are two different implementations of dynamic memory allocator, which have different suitable cases. Both of them should be kept for different applications.
>
> Ben.
^ permalink raw reply
* [PATCH] fix up front-LED Kconfig
From: Johannes Berg @ 2006-07-03 12:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Linux Kernel list
Rather long patch, apparently no one has updated the pmac32_defconfig in
a while.
---
This patch fixes the front-LED Kconfig issues I introduced while
creating it. Apparently having a dependency isn't enough to have the
select not evaluated or something like that.
The patch also changes the default configuration for pmac32 select the
default for the LED to be the IDE trigger. While I was at it, I
completely updated the defconfig and also added snd-aoa to it.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig
index addc793..3545af9 100644
--- a/arch/powerpc/configs/pmac32_defconfig
+++ b/arch/powerpc/configs/pmac32_defconfig
@@ -1,16 +1,18 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.17-rc5
-# Mon May 29 14:47:49 2006
+# Linux kernel version: 2.6.17
+# Mon Jul 3 14:20:49 2006
#
# CONFIG_PPC64 is not set
CONFIG_PPC32=y
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
+CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
@@ -29,6 +31,7 @@ # CONFIG_PPC_52xx is not set
# CONFIG_PPC_82xx is not set
# CONFIG_PPC_83xx is not set
# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_86xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_8xx is not set
@@ -39,6 +42,7 @@ CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
# CONFIG_SMP is not set
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
@@ -72,10 +76,12 @@ CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
+CONFIG_RT_MUTEXES=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
+CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
@@ -119,6 +125,9 @@ # CONFIG_EMBEDDED6xx is not set
# CONFIG_APUS is not set
# CONFIG_PPC_CHRP is not set
CONFIG_PPC_PMAC=y
+# CONFIG_PPC_CELL is not set
+# CONFIG_PPC_CELL_NATIVE is not set
+# CONFIG_UDBG_RTAS_CONSOLE is not set
CONFIG_MPIC=y
# CONFIG_PPC_RTAS is not set
# CONFIG_MMIO_NVRAM is not set
@@ -154,6 +163,7 @@ # CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
# CONFIG_KEXEC is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_SELECT_MEMORY_MODEL=y
@@ -164,6 +174,7 @@ CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
+# CONFIG_RESOURCES_64BIT is not set
CONFIG_PROC_DEVICETREE=y
# CONFIG_CMDLINE_BOOL is not set
CONFIG_PM=y
@@ -182,6 +193,7 @@ # CONFIG_PPC_I8259 is not set
CONFIG_PPC_INDIRECT_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
+# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_DEBUG is not set
#
@@ -256,6 +268,8 @@ CONFIG_INET_ESP=y
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
@@ -268,6 +282,7 @@ # CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
+# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
@@ -292,9 +307,11 @@ CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
+# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
+# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
@@ -313,6 +330,7 @@ CONFIG_IP_NF_TFTP=m
CONFIG_IP_NF_AMANDA=m
CONFIG_IP_NF_PPTP=m
CONFIG_IP_NF_H323=m
+# CONFIG_IP_NF_SIP is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
@@ -457,6 +475,7 @@ # CONFIG_SMC_IRCC_FIR is not set
# CONFIG_ALI_FIR is not set
# CONFIG_VLSI_FIR is not set
# CONFIG_VIA_FIR is not set
+# CONFIG_MCS_FIR is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
@@ -500,6 +519,7 @@ # CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
+# CONFIG_SYS_HYPERVISOR is not set
#
# Connector - unified userspace <-> kernelspace linker
@@ -600,7 +620,6 @@ # CONFIG_BLK_DEV_VIA82CXXX is not set
CONFIG_BLK_DEV_IDE_PMAC=y
CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y
CONFIG_BLK_DEV_IDEDMA_PMAC=y
-CONFIG_BLK_DEV_IDE_PMAC_BLINK=y
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
@@ -661,6 +680,7 @@ # CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_SATA is not set
+# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
@@ -705,9 +725,7 @@ CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
-CONFIG_MD_RAID5=m
-CONFIG_MD_RAID5_RESHAPE=y
-CONFIG_MD_RAID6=m
+# CONFIG_MD_RAID456 is not set
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=m
@@ -750,7 +768,6 @@ # Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
-# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
# CONFIG_IEEE1394_ETH1394 is not set
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
@@ -766,9 +783,12 @@ #
CONFIG_ADB=y
CONFIG_ADB_CUDA=y
CONFIG_ADB_PMU=y
+CONFIG_ADB_PMU_LED=y
+CONFIG_ADB_PMU_LED_IDE=y
CONFIG_PMAC_APM_EMU=m
CONFIG_PMAC_MEDIABAY=y
CONFIG_PMAC_BACKLIGHT=y
+CONFIG_PMAC_BACKLIGHT_LEGACY=y
CONFIG_INPUT_ADBHID=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_THERM_WINDTUNNEL=m
@@ -858,6 +878,7 @@ #
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
+# CONFIG_MYRI10GE is not set
#
# Token Ring devices
@@ -908,6 +929,7 @@ #
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
CONFIG_PRISM54=m
+# CONFIG_USB_ZD1201 is not set
# CONFIG_HOSTAP is not set
CONFIG_NET_WIRELESS=y
@@ -998,6 +1020,7 @@ #
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
+# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
#
@@ -1029,6 +1052,7 @@ #
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
+# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_GEN_RTC=y
# CONFIG_GEN_RTC_X is not set
@@ -1040,6 +1064,7 @@ #
# Ftape, the floppy tape device driver
#
CONFIG_AGP=m
+# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
CONFIG_AGP_UNINORTH=m
CONFIG_DRM=m
@@ -1092,6 +1117,7 @@ # CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_POWERMAC=y
# CONFIG_I2C_MPC is not set
# CONFIG_I2C_NFORCE2 is not set
+# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
@@ -1156,12 +1182,13 @@ # CONFIG_USB_DABUSB is not set
#
# Graphics support
#
+# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_MACMODES=y
-CONFIG_FB_FIRMWARE_EDID=y
+CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
# CONFIG_FB_CIRRUS is not set
@@ -1178,6 +1205,7 @@ # CONFIG_FB_VGA16 is not set
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_NVIDIA=y
CONFIG_FB_NVIDIA_I2C=y
+CONFIG_FB_NVIDIA_BACKLIGHT=y
# CONFIG_FB_RIVA is not set
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_MILLENIUM=y
@@ -1187,12 +1215,15 @@ # CONFIG_FB_MATROX_I2C is not set
# CONFIG_FB_MATROX_MULTIHEAD is not set
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
+CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
CONFIG_FB_ATY128=y
+CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY=y
CONFIG_FB_ATY_CT=y
# CONFIG_FB_ATY_GENERIC_LCD is not set
CONFIG_FB_ATY_GX=y
+CONFIG_FB_ATY_BACKLIGHT=y
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
@@ -1221,7 +1252,11 @@ CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
-# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_DEVICE=y
+CONFIG_LCD_CLASS_DEVICE=m
+CONFIG_LCD_DEVICE=y
#
# Sound
@@ -1278,6 +1313,18 @@ # CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
+# CONFIG_SND_DARLA20 is not set
+# CONFIG_SND_GINA20 is not set
+# CONFIG_SND_LAYLA20 is not set
+# CONFIG_SND_DARLA24 is not set
+# CONFIG_SND_GINA24 is not set
+# CONFIG_SND_LAYLA24 is not set
+# CONFIG_SND_MONA is not set
+# CONFIG_SND_MIA is not set
+# CONFIG_SND_ECHO3G is not set
+# CONFIG_SND_INDIGO is not set
+# CONFIG_SND_INDIGOIO is not set
+# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
@@ -1315,6 +1362,17 @@ CONFIG_SND_POWERMAC=m
CONFIG_SND_POWERMAC_AUTO_DRC=y
#
+# Apple Onboard Audio driver
+#
+CONFIG_SND_AOA=m
+CONFIG_SND_AOA_FABRIC_LAYOUT=m
+CONFIG_SND_AOA_ONYX=m
+CONFIG_SND_AOA_TAS=m
+CONFIG_SND_AOA_TOONIE=m
+CONFIG_SND_AOA_SOUNDBUS=m
+CONFIG_SND_AOA_SOUNDBUS_I2S=m
+
+#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
@@ -1355,6 +1413,7 @@ #
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
+# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
@@ -1431,7 +1490,6 @@ # CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
# CONFIG_USB_NET_CDC_SUBSET is not set
CONFIG_USB_NET_ZAURUS=m
-# CONFIG_USB_ZD1201 is not set
CONFIG_USB_MON=y
#
@@ -1499,10 +1557,12 @@ # CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
+# CONFIG_USB_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETSERVO is not set
# CONFIG_USB_IDMOUSE is not set
+CONFIG_USB_APPLEDISPLAY=m
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TEST is not set
@@ -1524,7 +1584,8 @@ # CONFIG_MMC is not set
#
# LED devices
#
-# CONFIG_NEW_LEDS is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
#
# LED drivers
@@ -1533,6 +1594,10 @@ #
#
# LED Triggers
#
+CONFIG_LEDS_TRIGGERS=y
+# CONFIG_LEDS_TRIGGER_TIMER is not set
+CONFIG_LEDS_TRIGGER_IDE_DISK=y
+# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
#
# InfiniBand support
@@ -1549,6 +1614,19 @@ #
# CONFIG_RTC_CLASS is not set
#
+# DMA Engine support
+#
+# CONFIG_DMA_ENGINE is not set
+
+#
+# DMA Clients
+#
+
+#
+# DMA Devices
+#
+
+#
# File systems
#
CONFIG_EXT2_FS=y
@@ -1569,6 +1647,7 @@ # CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
+CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
@@ -1649,6 +1728,7 @@ # CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_CIFS is not set
+# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
@@ -1732,6 +1812,7 @@ CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
+CONFIG_PLIST=y
#
# Instrumentation Support
@@ -1744,12 +1825,15 @@ # Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
# CONFIG_MAGIC_SYSRQ is not set
+# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_MUTEXES is not set
+# CONFIG_DEBUG_RT_MUTEXES is not set
+# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
@@ -1763,11 +1847,7 @@ CONFIG_XMON=y
CONFIG_XMON_DEFAULT=y
# CONFIG_BDI_SWITCH is not set
CONFIG_BOOTX_TEXT=y
-# CONFIG_PPC_EARLY_DEBUG_LPAR is not set
-# CONFIG_PPC_EARLY_DEBUG_G5 is not set
-# CONFIG_PPC_EARLY_DEBUG_RTAS is not set
-# CONFIG_PPC_EARLY_DEBUG_MAPLE is not set
-# CONFIG_PPC_EARLY_DEBUG_ISERIES is not set
+# CONFIG_PPC_EARLY_DEBUG is not set
#
# Security options
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
index d1266fe..53bba41 100644
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -773,20 +773,6 @@ config BLK_DEV_IDEDMA_PMAC
to transfer data to and from memory. Saying Y is safe and improves
performance.
-config BLK_DEV_IDE_PMAC_BLINK
- bool "Blink laptop LED on drive activity (DEPRECATED)"
- depends on BLK_DEV_IDE_PMAC && ADB_PMU
- select ADB_PMU_LED
- select LEDS_TRIGGERS
- select LEDS_TRIGGER_IDE_DISK
- help
- This option enables the use of the sleep LED as a hard drive
- activity LED.
- This option is deprecated, it only selects ADB_PMU_LED and
- LEDS_TRIGGER_IDE_DISK and changes the code in the new led class
- device to default to the ide-disk trigger (which should be set
- from userspace via sysfs).
-
config BLK_DEV_IDE_SWARM
tristate "IDE for Sibyte evaluation boards"
depends on SIBYTE_SB1xxx_SOC
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 54f3f6b..dc60038 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -90,6 +90,15 @@ config ADB_PMU_LED
and the ide-disk LED trigger and configure appropriately through
sysfs.
+config ADB_PMU_LED_IDE
+ bool "Use front LED as IDE LED by default"
+ depends on ADB_PMU_LED
+ select LEDS_TRIGGERS
+ select LEDS_TRIGGER_IDE_DISK
+ help
+ This option makes the front LED default to the IDE trigger
+ so that it blinks on IDE activity.
+
config PMAC_SMU
bool "Support for SMU based PowerMacs"
depends on PPC_PMAC64
diff --git a/drivers/macintosh/via-pmu-led.c b/drivers/macintosh/via-pmu-led.c
index af8375e..5189d54 100644
--- a/drivers/macintosh/via-pmu-led.c
+++ b/drivers/macintosh/via-pmu-led.c
@@ -74,7 +74,7 @@ static void pmu_led_set(struct led_class
static struct led_classdev pmu_led = {
.name = "pmu-front-led",
-#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
+#ifdef CONFIG_ADB_PMU_LED_IDE
.default_trigger = "ide-disk",
#endif
.brightness_set = pmu_led_set,
^ permalink raw reply related
* Re: sound connector detection
From: Johannes Berg @ 2006-07-03 13:30 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Richard Purdie, alsa-devel, Linux Kernel list,
linuxppc-dev list
In-Reply-To: <200607011609.59426.dtor@insightbb.com>
[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]
> I am not too happy with putting this kind of switches into input layer,
> it should be reserved for "real" buttons, ones that user can explicitely
> push or toggle (lid switch is on the edge here but it and sleep button
> are used for similar purposes so it makes sense to have it in input layer
> too). But "cable X connected" kind of events is too much [for input layer,
> there could well be a separate layer for it]. If we go this way we'd have
> to move cable detection code from network to input layer as well ;)
I sort of see the point. But I think it is indeed unfortunate that we
have all these events scattered throughout. I could live with the
current approach abusing the alsa mixer API, but there's little point in
making that element user-visible. So maybe I just need some new alsa
definitions here.
Although, come to think of it, a daemon keeping the mixer open blocks
unloading the module. I suppose I'd rather have it the other way around
like the eventdev system does -- the device goes away and all reads to
it fail.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: sound connector detection
From: Johannes Berg @ 2006-07-03 13:31 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Liam Girdwood, Linux Kernel list, linuxppc-dev list,
Richard Purdie, linux-input, alsa-devel
In-Reply-To: <200607022248.36459.dtor@insightbb.com>
[-- Attachment #1: Type: text/plain, Size: 245 bytes --]
On Sun, 2006-07-02 at 22:48 -0400, Dmitry Torokhov wrote:
> Maybe we should start looking into connector or a pure netlink
> implementation.
Might not be a bad idea. Then again, the whole alsa API could work over
netlink ;)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* RE: JFFS2 FS is read-only (not what I want)
From: Anantharaman Chetan-W16155 @ 2006-07-03 14:18 UTC (permalink / raw)
To: Ben Warren, linuxppc-embedded
In-Reply-To: <44A6E57A.3080302@qstreams.com>
Did you check to see if your flash banks are unlocked?
Chetan Anantharaman
Motorola Labs
-----Original Message-----
From: linuxppc-embedded-bounces+w16155=3Demail.mot.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+w16155=3Demail.mot.com@ozlabs.org] On
Behalf Of Ben Warren
Sent: Saturday, July 01, 2006 4:14 PM
To: linuxppc-embedded@ozlabs.org
Subject: JFFS2 FS is read-only (not what I want)
Hello,
When I boot from a JFFS2 file system on my eval board, the file system=20
is effectively read-only, and I can't figure out why. I'm pretty sure=20
the kernel's configured for R/W MTD block access. Any help is greatly=20
appreciated.
The hardware in use is:
Freescale MPC8349EMDS eval board.
8MB Q-flash with 64 uniform 128k sectors
Here are the symptoms:
# du -s
265492 . <-- only 265k of data
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/mtdblock4 2048 2048 0 100% /
# mount
/dev/mtdblock4 on / type jffs2 (rw)
/proc on /proc type proc (rw)
Here's what the kernel spits out at boot-up:
***
physmap flash device: 800000 at fe000000
phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Command set type 1
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition definition
Creating 6 MTD partitions on "phys_mapped_flash":
0x00000000-0x00040000 : "u-boot"
0x00040000-0x00080000 : "env"
0x00080000-0x00280000 : "kernel" <-- kernel boots=20
from here
0x00280000-0x00480000 : "initrd" <-- no initrd,=20
this is empty
0x00480000-0x00680000 : "jffs2" <-- 2MB
partition
0x00680000-0x00800000 : "user" <-- empty
***
I created the MTD partitions in a u-boot image that was pulled from the=20
GIT tree about a week ago, and my kernel is 2.6.17-based. I wrote some=20
board init code that sets the MTD physical mappings.=20
Here are the MTD and JFFS2 parts of my .config file:
***
# Memory Technology Devices (MTD)
#
CONFIG_MTD=3Dy
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=3Dy
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=3Dy
CONFIG_MTD_BLOCK=3Dy
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=3Dy
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=3Dy
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=3Dy
CONFIG_MTD_MAP_BANK_WIDTH_2=3Dy
CONFIG_MTD_MAP_BANK_WIDTH_4=3Dy
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=3Dy
CONFIG_MTD_CFI_I2=3Dy
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=3Dy
# CONFIG_MTD_CFI_AMDSTD is not set
CONFIG_MTD_CFI_STAA=3Dy
CONFIG_MTD_CFI_UTIL=3Dy
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=3Dy
CONFIG_MTD_PHYSMAP_START=3D0xFE000000
CONFIG_MTD_PHYSMAP_LEN=3D0x800000
CONFIG_MTD_PHYSMAP_BANKWIDTH=3D2
# CONFIG_MTD_PLATRAM is not set
# CONFIG_JFFS_FS is not set
CONFIG_JFFS2_FS=3Dy
CONFIG_JFFS2_FS_DEBUG=3D0
# CONFIG_JFFS2_FS_WRITEBUFFER is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=3Dy
CONFIG_JFFS2_RTIME=3Dy
# CONFIG_JFFS2_RUBIN is not set
***
The file system is the SELF that is included with DENX's ELDK, and built
as at:
http://www.denx.de/wiki/view/DULG/RootFileSystemDesignAndBuilding
I used the following command to create the file system image, that was=20
then loaded at address 0xfe480000 via U-boot:
> mkfs.jffs2 -U -d rootfs -D rootfs_device.tab -b -e 0x20000 -o
jffs2.img
I modified the table to name my serial devices /dev/ttyS0 and /dev/ttyS1
thanks for the help. Sorry if this is too verbose or includes the wrong
information.
regards,
Ben
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ 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