Booting the linux-ppc64 kernel & flattened device tree v0.4

[Benjamin Herrenschmidt]

Here is the kernel patch. It applies on top of the various prom_init.c
bug fixes that I already posted today on the linuxppc-dev &
linuxppc64-dev lists (those will be in the next -mm and maybe in
2.6.12).

This patch is intended to hit upstream by 2.6.13


Index: linux-work/arch/ppc64/kernel/prom_init.c
===
--- linux-work.orig/arch/ppc64/kernel/prom_init.c   2005-06-01 
16:02:28.0 +1000
+++ linux-work/arch/ppc64/kernel/prom_init.c2005-06-01 16:07:21.0 
+1000
@@ -1514,7 +1514,14 @@
return 0;
 }
 
-static void __init scan_dt_build_strings(phandle node, unsigned long 
*mem_start,
+/*
+ * The Open Firmware 1275 specification states properties must be 31 bytes or
+ * less, however not all firmwares obey this. Make it 64 bytes to be safe.
+ */
+#define MAX_PROPERTY_NAME 64
+
+static void __init scan_dt_build_strings(phandle node,
+unsigned long *mem_start,
 unsigned long *mem_end)
 {
unsigned long offset = reloc_offset();
@@ -1527,14 +1534,19 @@
/* get and store all property names */
prev_name = RELOC("");
for (;;) {
-   
-   /* 32 is max len of name including nul. */
-   namep = make_room(mem_start, mem_end, 32, 1);
+   namep = make_room(mem_start, mem_end, MAX_PROPERTY_NAME, 1);
if (call_prom("nextprop", 3, 1, node, prev_name, namep) <= 0) {
/* No more nodes: unwind alloc */
*mem_start = (unsigned long)namep;
break;
}
+
+   /* skip "name" */
+   if (strcmp(namep, RELOC("name")) == 0) {
+   *mem_start = (unsigned long)namep;
+   prev_name = RELOC("name");
+   continue;
+   }
soff = dt_find_string(namep);
if (soff != 0) {
*mem_start = (unsigned long)namep;
@@ -1555,72 +1567,83 @@
}
 }
 
-/*
- * The Open Firmware 1275 specification states properties must be 31 bytes or
- * less, however not all firmwares obey this. Make it 64 bytes to be safe.
- */
-#define MAX_PROPERTY_NAME 64
-
 static void __init scan_dt_build_struct(phandle node, unsigned long *mem_start,
unsigned long *mem_end)
 {
-   int l, align;
phandle child;
-   char *namep, *prev_name, *sstart, *p, *ep;
+   char *namep, *prev_name, *sstart, *p, *ep, *lp, *path;
unsigned long soff;
unsigned char *valp;
unsigned long offset = reloc_offset();
-   char pname[MAX_PROPERTY_NAME];
-   char *path;
-
-   path = RELOC(prom_scratch);
+   static char pname[MAX_PROPERTY_NAME] __initdata;
+   int l;
 
dt_push_token(OF_DT_BEGIN_NODE, mem_start, mem_end);
 
-   /* get the node's full name */
+   /* get the node's full name for debugging */
+   path = RELOC(prom_scratch);
+   memset(path, 0, PROM_SCRATCH_SIZE);
+   call_prom("package-to-path", 3, 1, node, path, PROM_SCRATCH_SIZE-1);
+   prom_debug("   %s\n", path);
+ 
+   /* get the node's full name for actual use */
namep = (char *)*mem_start;
l = call_prom("package-to-path", 3, 1, node,
  namep, *mem_end - *mem_start);
if (l >= 0) {
+   int had_fixup = 0;
+ 
/* Didn't fit?  Get more room. */
if (l+1 > *mem_end - *mem_start) {
namep = make_room(mem_start, mem_end, l+1, 1);
call_prom("package-to-path", 3, 1, node, namep, l);
}
-   namep[l] = '\0';
-   /* Fixup an Apple bug where they have bogus \0 chars in the
-* middle of the path in some properties
-*/
-   for (p = namep, ep = namep + l; p < ep; p++)
-   if (*p == '\0') {
-   memmove(p, p+1, ep - p);
-   ep--; l--;
-   }
-   *mem_start = _ALIGN(((unsigned long) namep) + strlen(namep) + 
1, 4);
+   ep = namep + l;
+   *ep = '\0';
+   /* now try to find the unit name in that mess */
+   for (p = namep, lp = NULL; p < ep; p++) {
+   if (*p == '/')
+   lp = p + 1;
+   /* bug fix: apple's OF has a funny bug where they have
+* a '\0' in the name/path string of some nodes.
+* We fix that up here
+*/
+   if (*p == '\0') {
+   memmove(p, p+1, ep - p);
+   ep--; l--;
+   had_fixup = 1;
+   }
+ 

Booting the linux-ppc64 kernel & flattened device tree v0.4

[Benjamin Herrenschmidt]

DO NOT REPLY TO ALL LISTS PLEASE ! (and CC me on replies).

Here's the fourth version of my document along with new kernel patches
for the new improved flattened format, and the first release of the
device-tree "compiler" tool. The patches will be posted as a reply to
this email. The compiler, dtc, can be downloaded, the URL is in the
document.

---

   Booting the Linux/ppc64 kernel without Open Firmware
   


(c) 2005 Benjamin Herrenschmidt , IBM Corp.

   May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.

   May 19, 2005: Rev 0.2 - Add chapter III and bits & pieces here or
   clarifies the fact that a lot of things are
   optional, the kernel only requires a very
   small device tree, though it is encouraged
   to provide an as complete one as possible.
 
   May 24, 2005: Rev 0.3 - Precise that DT block has to be in RAM
 - Misc fixes
 - Define version 3 and new format version 16
   for the DT block (version 16 needs kernel
   patches, will be fwd separately).
   String block now has a size, and full path
   is replaced by unit name for more
   compactness.
   linux,phandle is made optional, only nodes
   that are referenced by other nodes need it.
   "name" property is now automatically
   deduced from the unit name

   June 1, 2005: Rev 0.4 - Correct confusion between OF_DT_END and
   OF_DT_END_NODE in structure definition.
 - Change version 16 format to always align
   property data to 4 bytes. Since tokens are
   already aligned, that means no specific
   required alignement between property size
   and property data. The old style variable
   alignment would make it impossible to do
   "simple" insertion of properties using
   memove (thanks Milton for
   noticing). Updated kernel patch as well
 - Correct a few more alignement constraints
 - Add a chapter about the device-tree
   compiler and the textural representation of
   the tree that can be "compiled" by dtc.


 ToDo:

- Add some definitions of interrupt tree (simple/complex)
- Add some definitions for pci host bridges


I- Introduction
===


During the recent developpements of the Linux/ppc64 kernel, and more
specifically, the addition of new platform types outside of the old
IBM pSeries/iSeries pair, it was decided to enforce some strict rules
regarding the kernel entry and bootloader <-> kernel interfaces, in
order to avoid the degeneration that has become the ppc32 kernel entry
point and the way a new platform should be added to the kernel. The
legacy iSeries platform breaks those rules as it predates this scheme,
but no new board support will be accepted in the main tree that
doesn't follows them properly.

The main requirement that will be defined in more details below is
the presence of a device-tree whose format is defined after Open
Firmware specification. However, in order to make life easier
to embedded board vendors, the kernel doesn't require the device-tree
to represent every device in the system and only requires some nodes
and properties to be present. This will be described in details in
section III, but, for example, the kernel does not require you to
create a node for every PCI device in the system. It is a requirement
to have a node for PCI host bridges in order to provide interrupt
routing informations and memory/IO ranges, among others. It is also
recommended to define nodes for on chip devices and other busses that
doesn't specifically fit in an existing OF specification, like on chip
devices, this creates a great flexibility in the way the kernel can
them probe those and match drivers to device, without having to hard
code all sorts of tables. It also makes it more flexible for board
vendors to do minor hardware upgrades without impacting significantly
the kernel code or cluttering it with special cases.
 

1) Entry point
--

   There is one and one single entry point to the kernel, at the start
   of the kernel image. That entry point support two calling
   conventions:

a) Boot from Open Firmware. If your firmware is compatible
with Open Firmware (IEEE 1275) or provides an OF compatible
client interface API (support for "interpret" callback of
forth words isn't required), you can enter the

RFC: PHY Abstraction Layer II

[Andy Fleming]

On Jun 1, 2005, at 16:19, Stephen Hemminger wrote:

> Andy Fleming wrote:
>>
>> But not this one.  The phy_read and phy_write functions are  
>> reading  from and writing to a bus.  It is a reasonable  
>> implementation to have  the operation block in the bus driver, and  
>> be awoken when an  interrupt signals the operation is done.  All  
>> of the phydev spinlocks  have been arranged so as to prevent the  
>> lock being taken during  interrupt time.
>>
>> Unless I've misunderstood spinlocks (it wouldn't be the first  
>> time),  as long as the lock is never taken in interrupt time, it  
>> should be ok  to hold the lock, and wait for an interrupt before  
>> clearing the lock.
>>
>
>
> The problem is that sleeping is defined in the linux kernel as  
> meaning waiting on a mutual exclusion
> primitive (like semaphore) that puts the current thread to sleep.  
> It is not legal to sleep with a spinlock held.
> In the phy_read code you do:
> spin_lock_bh(&bus->mdio_lock);
>retval = bus->read(bus, phydev->addr, regnum);
>spin_unlock_bh(&bus->mdio_lock);
>
> If the bus->read function were to do something like start a request  
> and wait on a semaphore, then
> you would be sleeping with a spin lock held.  So bus->read can not  
> sleep! (as sleep is defined in the
> linux kernel).

Hmm...  I understand this reasoning, but I still need a way for a bus  
read to wait for an interrupt before returning.  I suppose I can just  
have the code spin while it waits, but that seems wrong, somehow.   
I'm open to any suggestions.

RFC: PHY Abstraction Layer II

[Andy Fleming]

On Jun 1, 2005, at 16:41, Stephen Hemminger wrote:

> On Wed, 1 Jun 2005 15:45:26 -0500
> Andy Fleming  wrote:
>>
>>> * get rid of bus read may sleep implication in comment.
>>>   since you are holding phy spin lock it better not!!
>>>
>>
>>
>
> On a different note, I am not sure that using sysfs/kobject bus object
> is the right thing for this object.  Isn't the phy instance really  
> just
> an kobject whose parent is the network device?  I can't see a 1 to N
> relationship between phy bus and phy objects existing.

Well, the MII Management bus is, in fact, a bus.  When a network  
driver wants to modify a PHY, it must access that bus.  Many ethernet  
controllers have a 1 to 1 relationship, since a typical NIC is a PCI  
card with 1 ethernet port (meaning one controller, and one PHY).   
However, many systems have multiple ethernet controllers attached to  
one bus, which configures multiple PHYs.  Currently, these systems  
have been relying on luck to prevent multiple accesses to the same bus.

This tends to work because all of the PHY support is contained within  
the ethernet driver, so it is easy for such drivers to ensure that  
only one PHY transaction is done at a time.  This system begins to  
fall apart, though, when the PHY drivers start operating more  
independently to react to changing PHY state.  It really begins to  
fall apart if you have multiple drivers trying to access a shared  
bus.  For instance, the 8560 ADS board has 2 gigabit ethernet ports  
controlled by the gianfar driver, and 2 10/100 ports in the CPM  
subsystem, controlled by the fcc_enet driver.

These two drivers each have an access point for the bus, which use  
different mechanisms (one is a bit bang interface, and one is  
register based).  Using the new abstraction, it is possible for the  
FCC driver to use the gianfar driver's bus, thus saving code, and  
reducing complexity.

>
> The main use I can see for being a driver object is to catch  
> suspend/resume,
> and wouldn't you want that to be tied to the network device.

It would be quite easy for the network driver to suspend or resume  
the PHY and bus objects under the new abstraction.  However, if eth0  
is suspended, should it suspend the whole bus, and all the PHYs on  
it?  By making the MII bus an independent entity, eth0 can be  
suspended, and it can choose to suspend its PHY, but eth1 can  
continue to access its PHY over the bus, since those aren't suspended.

linux2.4.24 on Memec EVB no output on console

[[EMAIL PROTECTED]]

Hi at all

I have already postet this problem there but i want make some adds there.

Configs:
I use Memec EVB with Virtex2Pro
u-boot 1.1.2
linux2.4.24 with modify ml300 config

I ported u-boot on this board and can download the uImage from the ethernet.

Problem:
Atfer uncompressing the kernel I get no output on console

=> bootm
## Booting image at 0040 ...
   Image Name:   Linux-2.4.24-pre2
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:720036 Bytes = 703.2 kB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

I have oportunity to debug the kernel and I can see that the kernel runs!
It write something in buffer and init the serial driver. But somewhere it get 
illegal
kernel access and thhe kernel call exeption handler. On which point  the 
problem is I
can't say because I can't find the start address from kernel, to set a 
breakpoint there
and debug. I can only stop the processor and then debug.

Perhaps had someone the same problems and can help me.

Many thangs for any help!

best regards,

Andreas

[PATCH][1/3] RapidIO support: core

[Greg KH]

On Wed, Jun 01, 2005 at 11:08:36AM -0700, Matt Porter wrote:
> Patch is 108KB and can be found here:
> ftp://source.mvista.com/pub/rio/l26_rio_core.patch

register_driver() does not return the number of devices bound to the
driver.  So your comment in rio_register_driver() is incorrect.  Just
return count.

Hm, if the patch was inline it would be easier to comment on stuff like
this, I'll wait till then for the rest :)

thanks,

greg k-h

[PATCH][1/3] RapidIO support: core

[Greg KH]

On Wed, Jun 01, 2005 at 11:08:36AM -0700, Matt Porter wrote:
> Adds a RapidIO subsystem to the kernel. RIO is a switched
> fabric interconnect used in higher-end embedded applications.
> The curious can look at the specs over at http://www.rapidio.org
> 
> The core code implements enumeration/discovery, management of
> devices/resources, and interfaces for RIO drivers.
> 
> There's a lot more to do to take advantages of all the hardware
> features. However, this should provide a good base for folks
> with RIO hardware to start contributing.
> 
> Signed-off-by: Matt Porter 
> 
> Patch is 108KB and can be found here:
> ftp://source.mvista.com/pub/rio/l26_rio_core.patch

Care to split it up into logical sections and post it?  It should be
small enough to do so that way.

thanks,

greg k-h

[PATCH][1/3] RapidIO support: core

[Matt Porter]

On Wed, Jun 01, 2005 at 11:08:36AM -0700, Matt Porter wrote:
> Adds a RapidIO subsystem to the kernel. RIO is a switched
> fabric interconnect used in higher-end embedded applications.
> The curious can look at the specs over at http://www.rapidio.org
> 
> The core code implements enumeration/discovery, management of
> devices/resources, and interfaces for RIO drivers.

I'm also hacking on a rioutils package (derived from pciutils)
that has a lsrio that works pretty much like the familiar
lspci tool.  The initial release can be grabbed from:
ftp://source.mvista.com/pub/rio/rioutils-0.10.tar.bz2

-Matt

RFC: PHY Abstraction Layer II

[Andy Fleming]

On May 31, 2005, at 12:59, Stephen Hemminger wrote:

> Here are some patches:
> * allow phy's to be modules
> * use driver owner for ref count
> * make local functions static where ever possible

I agree with all these.

> * get rid of bus read may sleep implication in comment.
>   since you are holding phy spin lock it better not!!

But not this one.  The phy_read and phy_write functions are reading  
from and writing to a bus.  It is a reasonable implementation to have  
the operation block in the bus driver, and be awoken when an  
interrupt signals the operation is done.  All of the phydev spinlocks  
have been arranged so as to prevent the lock being taken during  
interrupt time.

Unless I've misunderstood spinlocks (it wouldn't be the first time),  
as long as the lock is never taken in interrupt time, it should be ok  
to hold the lock, and wait for an interrupt before clearing the lock.

Andy Fleming

[PATCH] [RFC] ppc32 (linux-2.6.11.4): remove the limitation of 2MB consistent DMA memory on ppc440

[Shawn Jin]

Hi,

This patch removes the limitation of 2MB consistent DMA memory on
ppc440. Originally consistent_pte was allocated only one page no
matter what value of CONFIG_CONSISTENT_SIZE is set. By default
CONFIG_CONSISTENT_SIZE is 0x20. This causes some troubles on high
performance I/O applications which may require more than 2MB
consistent DMA memory.

The modifications allocate multiple pages for consistent pte table
according to CONFIG_CONSISTENT_SIZE. For example if
CONFIG_CONSISTENT_SIZE is set to 4MB, 2 pages are allocated for
consistent pte table. Please note that CONFIG_CONSISTENT_SIZE cannot
be any value. You have to find a free continuous memory space on your
system memory mapping.

The patch was tested successfully on Ocotea board. But I'm not sure if
it works on other systems. Use it at your own risk. However feedback
is more than welcome. :)

Regards,
-Shawn.
-- next part --
A non-text attachment was scrubbed...
Name: dma-mapping.patch
Type: application/octet-stream
Size: 4202 bytes
Desc: not available
Url : 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050601/e1c3e086/attachment.obj
 

Booting the linux-ppc64 kernel & flattened device tree v0.4

[Jon Loeliger]

On Wed, 2005-06-01 at 03:26, Benjamin Herrenschmidt wrote:
> DO NOT REPLY TO ALL LISTS PLEASE ! (and CC me on replies).
> 
> Here's the fourth version of my document along with new kernel patches
> for the new improved flattened format, and the first release of the
> device-tree "compiler" tool. The patches will be posted as a reply to
> this email. The compiler, dtc, can be downloaded, the URL is in the
> document.
> 
> ---

> 
> dtc source code can be found at 

Ben,

Here are diffs to:

- Fix multi-line C-style comments.

- Adjust the output of write_tree_source() such that it
  separates properties and nodes a bit better.

Thanks,
jdl


diff -u dtc.orig/dtc-lexer.l dtc/dtc-lexer.l
--- dtc.orig/dtc-lexer.l2005-06-01 11:44:29.02000 -0500
+++ dtc/dtc-lexer.l 2005-06-01 13:39:56.01000 -0500
@@ -34,8 +34,6 @@
 
 #include "y.tab.h"
 
-#undef LEXDEBUG1
-
 %}
 
 \"[^"]*\"  {
@@ -102,7 +100,7 @@
 
 <*>{WS}+   /* eat whitespace */
 
-<*>\/\*[^*]*(\*[^/][^*])*\*\/  /* eat comments */
+<*>\/\*([^*]|\**[^*/])*\*+\/   /* eat C comments */
 
 <*>\/\/.*\n/* eat line comments */
 
diff -u dtc.orig/treesource.c dtc/treesource.c
--- dtc.orig/treesource.c   2005-06-01 11:44:29.02000 -0500
+++ dtc/treesource.c2005-06-01 13:58:33.01000 -0500
@@ -131,10 +131,16 @@
break;
}
}
-   fprintf(f, "\n");
+   if (tree->children) {
+   fprintf(f, "\n");
+   }
for_each_child(tree, child) {
write_tree_source(f, child, level+1);
}
write_prefix(f, level);
fprintf(f, "};\n");
+
+   if (tree->next_sibling) {
+   fprintf(f, "\n");
+   }
 }

ML300-gpio

[Andrei Konovalov]

colui77 at virgilio.it wrote:
> hi all,
> I'm working with the ML300 platform running the shipped Montavista Linux
> (and hw configuration). I need to use the onboard gpio and I found a driver,
> the xilinx_gpio, that I have loaded (insmod xilinx_gpio). After insmoding
> the driver it is registered in /dev/xgpio (why is not it loaded in /proc/
> before?) I have tried to use the GPIOs...
> 
> cat "1100" > /dev/xgpio

You must use ioctl's.
This driver has the same API as IBM OCP GPIO driver.
Please check include/linux/ibm_ocp_gpio.h.

Thanks,
Andrei

> I was expecting some leds lighting but nothing at all...
> Is there someone experienced with the ml300 gpios? 
> Please I need help
> Luigi
> 
> 
> 
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RFC: PHY Abstraction Layer II

[Stephen Hemminger]

On Wed, 1 Jun 2005 15:45:26 -0500
Andy Fleming  wrote:

> 
> On May 31, 2005, at 12:59, Stephen Hemminger wrote:
> 
> > Here are some patches:
> > * allow phy's to be modules
> > * use driver owner for ref count
> > * make local functions static where ever possible
> 
> I agree with all these.
> 
> > * get rid of bus read may sleep implication in comment.
> >   since you are holding phy spin lock it better not!!
> 

On a different note, I am not sure that using sysfs/kobject bus object
is the right thing for this object.  Isn't the phy instance really just
an kobject whose parent is the network device?  I can't see a 1 to N
relationship between phy bus and phy objects existing. 

The main use I can see for being a driver object is to catch suspend/resume,
and wouldn't you want that to be tied to the network device.

Does linuxppc_2_4_devel still accept patch?

[ming lei]

Hi,

I found there is a serious problem in head_440.S
regarding the handling of mmucr in DataTLBmiss and
InstructionTLBmiss exceptions in 2.4 linux ppc branch.
Where should I submit the changes?

Which branch right now is active for ppc44x
development? Have we moved to linux kernel 2.6
official development already?

Ming

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

RFC: PHY Abstraction Layer II

[Stephen Hemminger]

Andy Fleming wrote:

>
> On May 31, 2005, at 12:59, Stephen Hemminger wrote:
>
>> Here are some patches:
>> * allow phy's to be modules
>> * use driver owner for ref count
>> * make local functions static where ever possible
>
>
> I agree with all these.
>
>> * get rid of bus read may sleep implication in comment.
>>   since you are holding phy spin lock it better not!!
>
>
> But not this one.  The phy_read and phy_write functions are reading  
> from and writing to a bus.  It is a reasonable implementation to have  
> the operation block in the bus driver, and be awoken when an  
> interrupt signals the operation is done.  All of the phydev spinlocks  
> have been arranged so as to prevent the lock being taken during  
> interrupt time.
>
> Unless I've misunderstood spinlocks (it wouldn't be the first time),  
> as long as the lock is never taken in interrupt time, it should be ok  
> to hold the lock, and wait for an interrupt before clearing the lock.


The problem is that sleeping is defined in the linux kernel as meaning 
waiting on a mutual exclusion
primitive (like semaphore) that puts the current thread to sleep. It is 
not legal to sleep with a spinlock held.
In the phy_read code you do:
   
   spin_lock_bh(&bus->mdio_lock);
retval = bus->read(bus, phydev->addr, regnum);
spin_unlock_bh(&bus->mdio_lock);

If the bus->read function were to do something like start a request and 
wait on a semaphore, then
you would be sleeping with a spin lock held.  So bus->read can not 
sleep! (as sleep is defined in the
linux kernel).

   

bd_t Cleaning: Board Changes

[Kumar Gala]

Well, as 85xx/83xx maintainer I'm ok with it.  We should probably need 
4xx (Matt) and 8xx/82xx (Dan/Tom) agreement.

- kumar

On Jun 1, 2005, at 1:10 PM, Mark A. Greer wrote:

> Jon Loeliger wrote:
>
>> 
>>
>> Part Two of Four, the Board Changes.
>>
>> ppc/platforms/4xx/ash.h |   21 -
>> ppc/platforms/4xx/bubinga.c |4
>> ppc/platforms/4xx/bubinga.h |   23 -
>> ppc/platforms/4xx/cpci405.h |2
>> ppc/platforms/4xx/ebony.c   |9
>> ppc/platforms/4xx/ep405.c   |   12
>> ppc/platforms/4xx/ep405.h   |   13
>> ppc/platforms/4xx/luan.c|7
>> ppc/platforms/4xx/oak.c |   15
>> ppc/platforms/4xx/oak.h |   19 -
>> ppc/platforms/4xx/oak_setup.h   |2
>> ppc/platforms/4xx/ocotea.c  |   13
>> ppc/platforms/4xx/redwood5.h|   13
>> ppc/platforms/4xx/redwood6.c|   27 -
>> ppc/platforms/4xx/redwood6.h|   13
>> ppc/platforms/4xx/sycamore.h|   22 -
>> ppc/platforms/4xx/walnut.h  |   22 -
>> ppc/platforms/4xx/xilinx_ml300.h|   12
>> ppc/platforms/83xx/mpc834x_sys.c|   49 +-
>> ppc/platforms/83xx/mpc834x_sys.h|1
>> ppc/platforms/85xx/mpc8540_ads.c|   57 ++-
>> ppc/platforms/85xx/mpc8560_ads.c|   21 -
>> ppc/platforms/85xx/mpc85xx_ads_common.c |   10
>> ppc/platforms/85xx/mpc85xx_ads_common.h |1
>> ppc/platforms/85xx/mpc85xx_cds_common.c |   48 +-
>> ppc/platforms/85xx/mpc85xx_cds_common.h |1
>> ppc/platforms/85xx/sbc8560.c|   19 -
>> ppc/platforms/85xx/sbc85xx.c|   14
>> ppc/platforms/85xx/sbc85xx.h|1
>> ppc/platforms/85xx/stx_gp3.c|   34 -
>> ppc/platforms/85xx/stx_gp3.h|1
>> ppc/platforms/bseip.h   |   13
>> ppc/platforms/ccm.h |2
>> ppc/platforms/cpci690.h |   10
>> ppc/platforms/est8260.h |   18
>> ppc/platforms/fads.h|2
>> ppc/platforms/hdpu.c|   13
>> ppc/platforms/hermes.h  |2
>> ppc/platforms/ip860.h   |2
>> ppc/platforms/ivms8.h   |2
>> ppc/platforms/katana.c  |6
>> ppc/platforms/lantec.h  |2
>> ppc/platforms/lite5200.c|9
>> ppc/platforms/lwmon.h   |2
>> ppc/platforms/mbx.h |   22 -
>> ppc/platforms/pcu_e.h   |2
>> ppc/platforms/pq2ads.c  |1
>> ppc/platforms/pq2ads.h  |2
>> ppc/platforms/radstone_ppc7d.c  |   32 -
>> ppc/platforms/radstone_ppc7d.h  |2
>> ppc/platforms/rpx8260.h |   19 -
>> ppc/platforms/rpxclassic.h  |   13
>> ppc/platforms/rpxlite.h |   13
>> ppc/platforms/sandpoint.c   |   11
>> ppc/platforms/sandpoint.h   |2
>> ppc/platforms/sbc82xx.c |6
>> ppc/platforms/sbc82xx.h |2
>> ppc/platforms/sbs8260.h |   18
>> ppc/platforms/spd8xx.h  |2
>> ppc/platforms/tqm8260.h |2
>> ppc/platforms/tqm8260_setup.c   |1
>> ppc/platforms/tqm8xx.h  |2
>>
>>
>>
> 
>
> All,
>
> So is this patch going to go in?  I haven't seen anyone "push it up".
> The reason I'm asking is that I have a couple patches that I would like
> to push up but they will collide with this one so I need to know if it
> (or a variation thereof) is going to go in or not.
>
> Thanks,
>
> Mark
>
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

[RFC] handle access to non-present IO ports on 8xx

[Marcelo Tosatti]

Hi,

Accessing non present "IO ports" on 8xx generates MCE's. The exception is easily
triggered during insertion/removal/suspension of PCMCIA cards. 

The following (against ancient v2.4) adds exception table entries for I/O
instructions on 8xx (copied from the original Paul's PowerMac code), and
changes MachineCheckException() slightly to cover 8xx specific's (on 8xx
the MCE can be generated while executing the IO access instruction itself,
which is not the case on PowerMac's, as the comment on traps.c details).

A few things I'm wondering:

1) why does the current PowerMac version covers only inb() and not outb() ?  
I had to add outb() exception table entries for 8xx.

2) Is the same wanted for other embedded PPC's? 

3) How to make the misc.S exception entries and additional instructions 
selectable only on the platform who need it? #ifdef does not sound 
a good idea. 

Nevermind the "#ifdef CONFIG_ALL_PPC" crap - that needs to be done
properly.


Index: arch/ppc/kernel/misc.S
===
RCS file: /mnt/test1/tslinux_mv21/linux-216/arch/ppc/kernel/misc.S,v
retrieving revision 1.2
diff -u -r1.2 misc.S
--- arch/ppc/kernel/misc.S  22 Oct 2003 19:34:30 -  1.2
+++ arch/ppc/kernel/misc.S  1 Jun 2005 17:59:30 -
@@ -736,8 +736,23 @@
subir4,r4,1
blelr-
 00:lbz r5,0(r3)
-   eieio
-   stbur5,1(r4)
+01:eieio
+02:stbur5,1(r4)
+03:twi 0, r5, 0
+04:isync
+05:nop
+06:.section .fixup,"ax"
+07:b 9f
+   .text
+08:.section __ex_table, "a"
+   .align 2
+   .long 00b, 07b
+   .long 01b, 07b
+   .long 02b, 07b
+   .long 03b, 07b
+   .long 04b, 07b
+   .long 05b, 07b
+   .text
bdnz00b
blr
 
@@ -747,10 +762,27 @@
subir4,r4,1
blelr-
 00:lbzur5,1(r4)
-   stb r5,0(r3)
-   eieio
+01:stb r5,0(r3)
+02:eieio
+03:twi 0, r5, 0
+04:isync
+05:nop
+06:.section .fixup,"ax"
+07:b 9f
+   .text
+08:.section __ex_table, "a"
+   .align 2
+   .long 00b, 07b
+   .long 01b, 07b
+   .long 02b, 07b
+   .long 03b, 07b
+   .long 04b, 07b
+   .long 05b, 07b
+   .text
+
bdnz00b
-   blr 
+9: blr 
+
 
 _GLOBAL(_insw)
cmpwi   0,r5,0
@@ -758,10 +790,25 @@
subir4,r4,2
blelr-
 00:lhbrx   r5,0,r3
-   eieio
-   sthur5,2(r4)
+01:eieio
+02:sthur5,2(r4)
+03:twi 0, r5, 0
+04:isync
+05:nop
+06:.section .fixup,"ax"
+07:b 9f
+   .text
+08:.section __ex_table, "a"
+   .align 2
+   .long 00b, 07b
+   .long 01b, 07b
+   .long 02b, 07b
+   .long 03b, 07b
+   .long 04b, 07b
+   .long 05b, 07b
+   .text
bdnz00b
-   blr
+9: blr
 
 _GLOBAL(_outsw)
cmpwi   0,r5,0
@@ -769,10 +816,25 @@
subir4,r4,2
blelr-
 00:lhzur5,2(r4)
-   eieio
-   sthbrx  r5,0,r3 
+01:eieio
+02:sthbrx  r5,0,r3 
+03:twi 0, r5, 0
+04:isync
+05:nop
+06:.section .fixup,"ax"
+07:b 9f
+   .text
+08:.section __ex_table, "a"
+   .align 2
+   .long 00b, 07b
+   .long 01b, 07b
+   .long 02b, 07b
+   .long 03b, 07b
+   .long 04b, 07b
+   .long 05b, 07b
+   .text
bdnz00b
-   blr 
+9: blr 
 
 _GLOBAL(_insl)
cmpwi   0,r5,0
@@ -780,10 +842,25 @@
subir4,r4,4
blelr-
 00:lwbrx   r5,0,r3
-   eieio
-   stwur5,4(r4)
+01:eieio
+02:stwur5,4(r4)
+03:twi 0, r5, 0
+04:isync
+05:nop
+06:.section .fixup,"ax"
+07:b 9f
+   .text
+08:.section __ex_table, "a"
+   .align 2
+   .long 00b, 07b
+   .long 01b, 07b
+   .long 02b, 07b
+   .long 03b, 07b
+   .long 04b, 07b
+   .long 05b, 07b
+   .text
bdnz00b
-   blr
+9: blr
 
 _GLOBAL(_outsl)
cmpwi   0,r5,0
@@ -791,10 +868,26 @@
subir4,r4,4
blelr-
 00:lwzur5,4(r4)
-   stwbrx  r5,0,r3
-   eieio
+01:stwbrx  r5,0,r3
+02:eieio
+02:stwur5,4(r4)
+03:twi 0, r5, 0
+04:isync
+05:nop
+06:.section .fixup,"ax"
+07:b 9f
+   .text
+08:.section __ex_table, "a"
+   .align 2
+   .long 00b, 07b
+   .long 01b, 07b
+   .long 02b, 07b
+   .long 03b, 07b
+   .long 04b, 07b
+   .long 05b, 07b
+   .text
bdnz00b
-   blr 
+9: blr 
 
 _GLOBAL(ide_insw

[PATCH] ppc32: Removed dependency on CONFIG_CPM2 for building mpc85xx_device.c

[Kumar Gala]

Previously we needed CONFIG_CPM2 enabled to get the proper IRQ
ifdef's for CPM interrupts.  Recent changes have caused that to
be no longer necessary.

Signed-off-by: Kumar Gala 

---
commit 22774efc1bef9f9a0fd9b34d44bf10da787e3d91
tree 115c991f9030418e78a7aa0f23d678d0141e0746
parent 6e7c21f278abb17a9bbdc6fd1f1b1b96e6677fdb
author Kumar K. Gala  Wed, 01 Jun 2005 12:34:30 
-0500
committer Kumar K. Gala  Wed, 01 Jun 2005 12:34:30 
-0500

 arch/ppc/syslib/mpc85xx_devices.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/ppc/syslib/mpc85xx_devices.c 
b/arch/ppc/syslib/mpc85xx_devices.c
--- a/arch/ppc/syslib/mpc85xx_devices.c
+++ b/arch/ppc/syslib/mpc85xx_devices.c
@@ -321,7 +321,6 @@ struct platform_device ppc_sys_platform_
},
},
},
-#ifdef CONFIG_CPM2
[MPC85xx_CPM_FCC1] = {
.name = "fsl-cpm-fcc",
.id = 1,
@@ -575,7 +574,6 @@ struct platform_device ppc_sys_platform_
},
},
},
-#endif /* CONFIG_CPM2 */
[MPC85xx_eTSEC1] = {
.name = "fsl-gianfar",
.id = 1,

ML300-gpio

[[EMAIL PROTECTED]]

hi all,
I'm working with the ML300 platform running the shipped Montavista Linux
(and hw configuration). I need to use the onboard gpio and I found a driver,
the xilinx_gpio, that I have loaded (insmod xilinx_gpio). After insmoding
the driver it is registered in /dev/xgpio (why is not it loaded in /proc/
before?) I have tried to use the GPIOs...

cat "1100" > /dev/xgpio

I was expecting some leds lighting but nothing at all...
Is there someone experienced with the ml300 gpios? 
Please I need help
Luigi

Booting the linux-ppc64 kernel & flattened device tree v0.4

[Jon Loeliger]

On Wed, 2005-06-01 at 03:26, Benjamin Herrenschmidt wrote:
> Here's the fourth version of my document along with new kernel patches
> for the new improved flattened format, and the first release of the
> device-tree "compiler" tool. The patches will be posted as a reply to
> this email. The compiler, dtc, can be downloaded, the URL is in the
> document.

Ben,

Does it make sense to do this as well?

Thanks,
jdl


diff -Nur dtc.orig/lsprop.c dtc/lsprop.c
--- dtc.orig/lsprop.c   1969-12-31 18:00:00.0 -0600
+++ dtc/lsprop.c2005-06-01 11:43:01.02000 -0500
@@ -0,0 +1,221 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int recurse;
+int maxbytes = 128;
+int words_per_line = 0;
+char *buf;
+
+void lsprop(FILE *f, char *name);
+void lsdir(char *name);
+
+main(int ac, char **av)
+{
+FILE *f;
+int i;
+struct stat sb;
+char *endp;
+
+while ((i = getopt(ac, av, "Rm:w:")) != EOF) {
+   switch (i) {
+   case 'R':
+   recurse = 1;
+   break;
+   case 'm':
+   maxbytes = strtol(optarg, &endp, 0);
+   if (endp == optarg) {
+   fprintf(stderr, "%s: bad argument (%s) to -m option\n", av[0],
+   optarg);
+   exit(1);
+   }
+   maxbytes = (maxbytes + 15) & -16;
+   break;
+   case 'w':
+   words_per_line = strtol(optarg, &endp, 0);
+   if (endp == optarg) {
+   fprintf(stderr, "%s: bad argument (%s) to -w option\n",
+   av[0], optarg);
+   exit(1);
+   }
+   break;
+   }
+}
+
+buf = malloc(maxbytes);
+if (buf == 0) {
+   fprintf(stderr, "%s: virtual memory exhausted\n", av[0]);
+   exit(1);
+}
+
+if (optind == ac)
+   lsdir(".");
+else
+   for (i = optind; i < ac; ++i) {
+   if (stat(av[i], &sb) < 0) {
+   perror(av[i]);
+   continue;
+   }
+   if (S_ISREG(sb.st_mode)) {
+   f = fopen(av[i], "r");
+   if (f == NULL) {
+   perror(av[i]);
+   continue;
+   }
+   lsprop(f, av[i]);
+   fclose(f);
+   } else if (S_ISDIR(sb.st_mode)) {
+   lsdir(av[i]);
+   }
+   }
+exit(0);
+}
+
+void lsdir(char *name)
+{
+DIR *d;
+struct dirent *de;
+char *p, *q;
+struct stat sb;
+FILE *f;
+int np = 0;
+
+d = opendir(name);
+if (d == NULL) {
+   perror(name);
+   return;
+}
+
+p = malloc(strlen(name) + 520);
+if (p == 0) {
+   fprintf(stderr, "%s: virtual memory exhausted\n", name);
+   closedir(d);
+   return;
+}
+strcpy(p, name);
+q = p + strlen(p);
+while (q > p && q[-1] == '/')
+   --q;
+if (q == p + 1 && p[0] == '.')
+   q = p;
+else
+   *q++ = '/';
+
+while ((de = readdir(d)) != NULL) {
+   if (strcmp(de->d_name, ".") == 0 || strcmp(de->d_name, "..") == 0)
+   continue;
+   strcpy(q, de->d_name);
+   if (stat(p, &sb) < 0) {
+   perror(p);
+   continue;
+   }
+   if (S_ISREG(sb.st_mode)) {
+   f = fopen(p, "r");
+   if (f == NULL) {
+   perror(p);
+   } else {
+   lsprop(f, de->d_name);
+   fclose(f);
+   ++np;
+   }
+   }
+}
+rewinddir(d);
+while ((de = readdir(d)) != NULL) {
+   if (strcmp(de->d_name, ".") == 0 || strcmp(de->d_name, "..") == 0)
+   continue;
+   strcpy(q, de->d_name);
+   if (lstat(p, &sb) < 0) {
+   perror(p);
+   continue;
+   }
+   if (S_ISDIR(sb.st_mode)) {
+   if (np)
+   printf("\n");
+   printf("%s:\n", p);
+   lsdir(p);
+   ++np;
+   }
+}
+free(p);
+closedir(d);
+}
+
+void lsprop(FILE *f, char *name)
+{
+int n, nw, npl, i, j;
+
+n = fread(buf, 1, maxbytes, f);
+if (n < 0) {
+   printf("%s: read error\n", name);
+   return;
+}
+printf("%-16s", name);
+if (strlen(name) > 16)
+   printf("\n\t\t");
+for (i = 0; i < n; ++i)
+   if (buf[i] >= 0x7f ||
+   (buf[i] < 0x20 && buf[i] != '\r' && buf[i] != '\n'
+&& buf[i] != '\t' && buf[i] != 0))
+   break;
+if (i == n && n != 0 && (n == 1 || buf[0] != 0) && buf[n-1] == 0) {
+   printf(" \"");
+   for (i = 0; i < n - 1; ++i)
+   if (buf[i] == 0)
+   printf("\"\n\t\t \"");
+   else if (buf[i] == '\r' || buf[i] == '\n')
+   printf("\n\t\t ");
+   else
+   putchar(buf[i]);
+   putchar('"');
+} else if ((n & 3) == 0) {
+   nw = n >> 2;
+   if (nw == 1) {
+   i = *(int *)buf;
+   printf(" %.8x", i);
+   if (i > -0x1 && !(i >= 0 && i <= 9))
+   printf(" (%d)", i);
+   } else {

How to allocate uncached memory on 82xx?

[Alex Zeffertt]

Hi all,

Can anybody tell me how to make uncached a region of memory on the
PowerQUICCII (MPC8280).  The region is allocated with

kmalloc(size,GFP_KERNEL | GFP_DMA);

TIA,

Alex

[PATCH][3/3] RapidIO support: net driver over messaging

[Matt Porter]

Adds an "Ethernet" driver which sends Ethernet packets over the
standard RapidIO messaging. This depends on the core RIO
patch for mailbox/doorbell access.

Signed-off-by: Matt Porter 

Index: drivers/net/Kconfig
===
--- f0bf7810dbe8c4073832d6c3785364084e9523a7/drivers/net/Kconfig  (mode:100644)
+++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/Kconfig  (mode:100644)
@@ -2185,6 +2185,20 @@
tristate "iSeries Virtual Ethernet driver support"
depends on NETDEVICES && PPC_ISERIES
 
+config RIONET
+   tristate "RapidIO Ethernet over messaging driver support"
+   depends on NETDEVICES && RAPIDIO
+
+config RIONET_TX_SIZE
+   int "Number of outbound queue entries"
+   depends on RIONET
+   default "128"
+
+config RIONET_RX_SIZE
+   int "Number of inbound queue entries"
+   depends on RIONET
+   default "128"
+
 config FDDI
bool "FDDI driver support"
depends on NETDEVICES && (PCI || EISA)
Index: drivers/net/Makefile
===
--- f0bf7810dbe8c4073832d6c3785364084e9523a7/drivers/net/Makefile  (mode:100644)
+++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/Makefile  (mode:100644)
@@ -58,6 +58,7 @@
 obj-$(CONFIG_VIA_RHINE) += via-rhine.o
 obj-$(CONFIG_VIA_VELOCITY) += via-velocity.o
 obj-$(CONFIG_ADAPTEC_STARFIRE) += starfire.o
+obj-$(CONFIG_RIONET) += rionet.o
 
 #
 # end link order section
Index: drivers/net/rionet.c
===
--- /dev/null  (tree:f0bf7810dbe8c4073832d6c3785364084e9523a7)
+++ 4ed27b6e30a69f314a2ca131e80ac45e2111f245/drivers/net/rionet.c  (mode:100644)
@@ -0,0 +1,622 @@
+/*
+ * rionet - Ethernet driver over RapidIO messaging services
+ *
+ * Copyright 2005 MontaVista Software, Inc.
+ * Matt Porter 
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME"rionet"
+#define DRV_VERSION "0.1"
+#define DRV_AUTHOR  "Matt Porter "
+#define DRV_DESC"Ethernet over RapidIO"
+
+MODULE_AUTHOR(DRV_AUTHOR);
+MODULE_DESCRIPTION(DRV_DESC);
+MODULE_LICENSE("GPL");
+
+#define RIONET_DEFAULT_MSGLEVEL0
+#define RIONET_DOORBELL_JOIN   0x1000
+#define RIONET_DOORBELL_LEAVE  0x1001
+
+#define RIONET_MAILBOX 0
+
+#define RIONET_TX_RING_SIZECONFIG_RIONET_TX_SIZE
+#define RIONET_RX_RING_SIZECONFIG_RIONET_RX_SIZE
+
+LIST_HEAD(rionet_peers);
+
+struct rionet_private {
+   struct rio_mport *mport;
+   struct sk_buff *rx_skb[RIONET_RX_RING_SIZE];
+   struct sk_buff *tx_skb[RIONET_TX_RING_SIZE];
+   struct net_device_stats stats;
+   int rx_slot;
+   int tx_slot;
+   int tx_cnt;
+   int ack_slot;
+   spinlock_t lock;
+   u32 msg_enable;
+};
+
+struct rionet_peer {
+   struct list_head node;
+   struct rio_dev *rdev;
+   struct resource *res;
+};
+
+static int rionet_check = 0;
+static int rionet_capable = 1;
+static struct net_device *sndev = NULL;
+
+/*
+ * This is a fast lookup table for for translating TX
+ * Ethernet packets into a destination RIO device. It
+ * could be made into a hash table to save memory depending
+ * on system trade-offs.
+ */
+static struct rio_dev *rionet_active[RIO_MAX_ROUTE_ENTRIES];
+
+#define is_rionet_capable(pef, src_ops, dst_ops)   \
+   ((pef & RIO_PEF_INB_MBOX) &&\
+(pef & RIO_PEF_INB_DOORBELL) &&\
+(src_ops & RIO_SRC_OPS_DOORBELL) &&\
+(dst_ops & RIO_DST_OPS_DOORBELL))
+#define dev_rionet_capable(dev) \
+   is_rionet_capable(dev->pef, dev->src_ops, dev->dst_ops)
+
+#define RIONET_MAC_MATCH(x)(*(u32 *)x == 0x00010001)
+#define RIONET_GET_DESTID(x)   (*(u16 *)(x + 4))
+
+static struct net_device_stats *rionet_stats(struct net_device *ndev)
+{
+   struct rionet_private *rnet = ndev->priv;
+   return &rnet->stats;
+}
+
+static int rionet_rx_clean(struct net_device *ndev)
+{
+   int i;
+   int error = 0;
+   struct rionet_private *rnet = ndev->priv;
+   void *data;
+
+   i = rnet->rx_slot;
+
+   do {
+   if (!rnet->rx_skb[i]) {
+   rnet->stats.rx_dropped++;
+   continue;
+   }
+
+   if (!(data = rio_get_inb_message(rnet->mport, RIONET_MAILBOX)))
+   break;
+
+   rnet->rx_skb[i]->data = data;
+   skb_put(rnet->rx_skb[i], RIO_MAX_MSG_SIZE);
+   rnet->rx_skb[i]->dev = sndev;
+   rn

[PATCH][2/3] RapidIO support: ppc32

[Matt Porter]

Adds PPC32 RIO support.  Init code for the MPC85xx RIO ports
and glue for the STx GP3 board to use it.

Signed-off-by: Matt Porter 

Index: arch/ppc/Kconfig
===
--- 750e10a6553cacbd2b92b52fe40afdc8062f4f78/arch/ppc/Kconfig  (mode:100644)
+++ f0bf7810dbe8c4073832d6c3785364084e9523a7/arch/ppc/Kconfig  (mode:100644)
@@ -1177,6 +1177,14 @@
 
 source "drivers/pcmcia/Kconfig"
 
+config RAPIDIO
+   bool "RapidIO support" if MPC8540 || MPC8560
+   help
+ If you say Y here, the kernel will include drivers and
+ infrastructure code to support RapidIO interconnect devices.
+
+source "drivers/rio/Kconfig"
+
 endmenu
 
 menu "Advanced setup"
Index: arch/ppc/configs/stx_gp3_defconfig
===
--- 750e10a6553cacbd2b92b52fe40afdc8062f4f78/arch/ppc/configs/stx_gp3_defconfig 
 (mode:100644)
+++ f0bf7810dbe8c4073832d6c3785364084e9523a7/arch/ppc/configs/stx_gp3_defconfig 
 (mode:100644)
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.11-rc2
-# Wed Jan 26 14:32:58 2005
+# Linux kernel version: 2.6.12-rc4
+# Tue May 24 18:11:04 2005
 #
 CONFIG_MMU=y
 CONFIG_GENERIC_HARDIRQS=y
@@ -11,6 +11,7 @@
 CONFIG_PPC=y
 CONFIG_PPC32=y
 CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
 
 #
 # Code maturity level options
@@ -18,6 +19,7 @@
 CONFIG_EXPERIMENTAL=y
 CONFIG_CLEAN_COMPILE=y
 CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
 
 #
 # General setup
@@ -29,7 +31,6 @@
 # CONFIG_BSD_PROCESS_ACCT is not set
 CONFIG_SYSCTL=y
 # CONFIG_AUDIT is not set
-CONFIG_LOG_BUF_SHIFT=14
 CONFIG_HOTPLUG=y
 CONFIG_KOBJECT_UEVENT=y
 # CONFIG_IKCONFIG is not set
@@ -37,6 +38,9 @@
 CONFIG_KALLSYMS=y
 # CONFIG_KALLSYMS_ALL is not set
 # CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_BASE_FULL=y
 CONFIG_FUTEX=y
 CONFIG_EPOLL=y
 # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
@@ -46,6 +50,7 @@
 CONFIG_CC_ALIGN_LOOPS=0
 CONFIG_CC_ALIGN_JUMPS=0
 # CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
 
 #
 # Loadable module support
@@ -69,9 +74,11 @@
 CONFIG_E500=y
 CONFIG_BOOKE=y
 CONFIG_FSL_BOOKE=y
+# CONFIG_PHYS_64BIT is not set
 # CONFIG_SPE is not set
 CONFIG_MATH_EMULATION=y
 # CONFIG_CPU_FREQ is not set
+# CONFIG_PM is not set
 CONFIG_85xx=y
 CONFIG_PPC_INDIRECT_PCI_BE=y
 
@@ -96,6 +103,7 @@
 CONFIG_BINFMT_ELF=y
 CONFIG_BINFMT_MISC=m
 # CONFIG_CMDLINE_BOOL is not set
+CONFIG_ISA_DMA_API=y
 
 #
 # Bus options
@@ -104,15 +112,15 @@
 CONFIG_PCI_DOMAINS=y
 # CONFIG_PCI_LEGACY_PROC is not set
 # CONFIG_PCI_NAMES is not set
+# CONFIG_PCI_DEBUG is not set
 
 #
 # PCCARD (PCMCIA/CardBus) support
 #
 # CONFIG_PCCARD is not set
-
-#
-# PC-card bridges
-#
+CONFIG_RAPIDIO=y
+CONFIG_RAPIDIO_8_BIT_TRANSPORT=y
+CONFIG_RAPIDIO_DISC_TIMEOUT=30
 
 #
 # Advanced setup
@@ -152,7 +160,7 @@
 CONFIG_PARPORT_PC=m
 # CONFIG_PARPORT_PC_FIFO is not set
 # CONFIG_PARPORT_PC_SUPERIO is not set
-# CONFIG_PARPORT_OTHER is not set
+# CONFIG_PARPORT_GSC is not set
 # CONFIG_PARPORT_1284 is not set
 
 #
@@ -264,7 +272,6 @@
 # CONFIG_SCSI_BUSLOGIC is not set
 # CONFIG_SCSI_DMX3191D is not set
 # CONFIG_SCSI_EATA is not set
-# CONFIG_SCSI_EATA_PIO is not set
 # CONFIG_SCSI_FUTURE_DOMAIN is not set
 # CONFIG_SCSI_GDTH is not set
 # CONFIG_SCSI_IPS is not set
@@ -274,7 +281,6 @@
 # CONFIG_SCSI_IMM is not set
 # CONFIG_SCSI_SYM53C8XX_2 is not set
 # CONFIG_SCSI_IPR is not set
-# CONFIG_SCSI_QLOGIC_ISP is not set
 # CONFIG_SCSI_QLOGIC_FC is not set
 # CONFIG_SCSI_QLOGIC_1280 is not set
 CONFIG_SCSI_QLA2XXX=m
@@ -283,6 +289,7 @@
 # CONFIG_SCSI_QLA2300 is not set
 # CONFIG_SCSI_QLA2322 is not set
 # CONFIG_SCSI_QLA6312 is not set
+# CONFIG_SCSI_LPFC is not set
 # CONFIG_SCSI_DC395x is not set
 # CONFIG_SCSI_DC390T is not set
 # CONFIG_SCSI_NSP32 is not set
@@ -322,7 +329,6 @@
 #
 CONFIG_PACKET=y
 # CONFIG_PACKET_MMAP is not set
-# CONFIG_NETLINK_DEV is not set
 CONFIG_UNIX=y
 # CONFIG_NET_KEY is not set
 CONFIG_INET=y
@@ -431,7 +437,7 @@
 #
 # Network testing
 #
-# CONFIG_NET_PKTGEN is not set
+CONFIG_NET_PKTGEN=y
 # CONFIG_NETPOLL is not set
 # CONFIG_NET_POLL_CONTROLLER is not set
 # CONFIG_HAMRADIO is not set
@@ -499,6 +505,7 @@
 # Wan interfaces
 #
 # CONFIG_WAN is not set
+CONFIG_RIONET=y
 # CONFIG_FDDI is not set
 # CONFIG_HIPPI is not set
 # CONFIG_PLIP is not set
@@ -536,20 +543,6 @@
 # CONFIG_INPUT_EVBUG is not set
 
 #
-# Input I/O drivers
-#
-# CONFIG_GAMEPORT is not set
-CONFIG_SOUND_GAMEPORT=y
-CONFIG_SERIO=y
-CONFIG_SERIO_I8042=y
-CONFIG_SERIO_SERPORT=y
-# 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 is not set
-
-#
 # Input Device Drivers
 #
 CONFIG_INPUT_KEYBOARD=y
@@ -567,6 +560,19 @@
 # CONFIG_INPUT_MISC is not set
 
 #
+# Hardware I/O ports
+#
+CONFIG_SERIO=y
+CONFIG_SERIO_I8042=y
+CONFIG_SERIO_SERPORT=y
+# CONFIG_SERIO_PARKBD is not set
+# CONFIG

bd_t Cleaning: Board Changes

[Mark A. Greer]

Jon Loeliger wrote:

> 
>
>Part Two of Four, the Board Changes.
>
> ppc/platforms/4xx/ash.h |   21 -
> ppc/platforms/4xx/bubinga.c |4 
> ppc/platforms/4xx/bubinga.h |   23 -
> ppc/platforms/4xx/cpci405.h |2 
> ppc/platforms/4xx/ebony.c   |9 
> ppc/platforms/4xx/ep405.c   |   12 
> ppc/platforms/4xx/ep405.h   |   13 
> ppc/platforms/4xx/luan.c|7 
> ppc/platforms/4xx/oak.c |   15 
> ppc/platforms/4xx/oak.h |   19 -
> ppc/platforms/4xx/oak_setup.h   |2 
> ppc/platforms/4xx/ocotea.c  |   13 
> ppc/platforms/4xx/redwood5.h|   13 
> ppc/platforms/4xx/redwood6.c|   27 -
> ppc/platforms/4xx/redwood6.h|   13 
> ppc/platforms/4xx/sycamore.h|   22 -
> ppc/platforms/4xx/walnut.h  |   22 -
> ppc/platforms/4xx/xilinx_ml300.h|   12 
> ppc/platforms/83xx/mpc834x_sys.c|   49 +-
> ppc/platforms/83xx/mpc834x_sys.h|1 
> ppc/platforms/85xx/mpc8540_ads.c|   57 ++-
> ppc/platforms/85xx/mpc8560_ads.c|   21 -
> ppc/platforms/85xx/mpc85xx_ads_common.c |   10 
> ppc/platforms/85xx/mpc85xx_ads_common.h |1 
> ppc/platforms/85xx/mpc85xx_cds_common.c |   48 +-
> ppc/platforms/85xx/mpc85xx_cds_common.h |1 
> ppc/platforms/85xx/sbc8560.c|   19 -
> ppc/platforms/85xx/sbc85xx.c|   14 
> ppc/platforms/85xx/sbc85xx.h|1 
> ppc/platforms/85xx/stx_gp3.c|   34 -
> ppc/platforms/85xx/stx_gp3.h|1 
> ppc/platforms/bseip.h   |   13 
> ppc/platforms/ccm.h |2 
> ppc/platforms/cpci690.h |   10 
> ppc/platforms/est8260.h |   18 
> ppc/platforms/fads.h|2 
> ppc/platforms/hdpu.c|   13 
> ppc/platforms/hermes.h  |2 
> ppc/platforms/ip860.h   |2 
> ppc/platforms/ivms8.h   |2 
> ppc/platforms/katana.c  |6 
> ppc/platforms/lantec.h  |2 
> ppc/platforms/lite5200.c|9 
> ppc/platforms/lwmon.h   |2 
> ppc/platforms/mbx.h |   22 -
> ppc/platforms/pcu_e.h   |2 
> ppc/platforms/pq2ads.c  |1 
> ppc/platforms/pq2ads.h  |2 
> ppc/platforms/radstone_ppc7d.c  |   32 -
> ppc/platforms/radstone_ppc7d.h  |2 
> ppc/platforms/rpx8260.h |   19 -
> ppc/platforms/rpxclassic.h  |   13 
> ppc/platforms/rpxlite.h |   13 
> ppc/platforms/sandpoint.c   |   11 
> ppc/platforms/sandpoint.h   |2 
> ppc/platforms/sbc82xx.c |6 
> ppc/platforms/sbc82xx.h |2 
> ppc/platforms/sbs8260.h |   18 
> ppc/platforms/spd8xx.h  |2 
> ppc/platforms/tqm8260.h |2 
> ppc/platforms/tqm8260_setup.c   |1 
> ppc/platforms/tqm8xx.h  |2 
>
>  
>


All,

So is this patch going to go in?  I haven't seen anyone "push it up".  
The reason I'm asking is that I have a couple patches that I would like 
to push up but they will collide with this one so I need to know if it 
(or a variation thereof) is going to go in or not.

Thanks,

Mark

Newbie question on Linux-PPC

[Srivatsan CR]

 
Dear all,
 
I am having a MPC8260 based board with the following memory map.
  
Device  Start address End address
EPROM   0x0x03FF
SDRAM   0x04000x13FF
 
I have a doubt regarding Linux Port onto this board. I have read on the web
that Linux usually expects the SDRAM at 0x0, is it that the porting of linux
onto this board is totally impossible? If the porting is possible can anyone
help me out where to change the memory mapping of Linux for MPC8260?
 
Thanking you all for your time. Kindly help me out to solve this issue.
 
With Regards,
C.R.Srivatsan
 
-- next part --
An HTML attachment was scrubbed...
URL: 
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050601/b5972dc1/attachment.htm
 

[PATCH][1/3] RapidIO support: core

[Matt Porter]

Adds a RapidIO subsystem to the kernel. RIO is a switched
fabric interconnect used in higher-end embedded applications.
The curious can look at the specs over at http://www.rapidio.org

The core code implements enumeration/discovery, management of
devices/resources, and interfaces for RIO drivers.

There's a lot more to do to take advantages of all the hardware
features. However, this should provide a good base for folks
with RIO hardware to start contributing.

Signed-off-by: Matt Porter 

Patch is 108KB and can be found here:
ftp://source.mvista.com/pub/rio/l26_rio_core.patch

-Matt

[PATCH] cpm_uart: Route SCC2 pins for the STx GP3 board

[Matt Porter]

Adds SCC2 pin routing specific to the GP3 board.

Signed-off-by: Matt Porter 
Signed-off-by: Kumar Gala 

Index: drivers/serial/cpm_uart/cpm_uart_cpm2.c
===
--- 
b4bedd69e60ae8cc7d89f3c97c617a444eb43292/drivers/serial/cpm_uart/cpm_uart_cpm2.c
  (mode:100644)
+++ uncommitted/drivers/serial/cpm_uart/cpm_uart_cpm2.c  (mode:100644)
@@ -134,12 +134,21 @@
 
 void scc2_lineif(struct uart_cpm_port *pinfo)
 {
+   /*
+* STx GP3 uses the SCC2 secondary option pin assignment
+* which this driver doesn't account for in the static
+* pin assignments. This kind of board specific info
+* really has to get out of the driver so boards can
+* be supported in a sane fashion.
+*/
+#ifndef CONFIG_STX_GP3
volatile iop_cpm2_t *io = &cpm2_immr->im_ioport;
io->iop_pparb |= 0x008b;
io->iop_pdirb |= 0x0088;
io->iop_psorb |= 0x0088;
io->iop_pdirb &= ~0x0003;
io->iop_psorb &= ~0x0003;
+#endif
cpm2_immr->im_cpmux.cmx_scr &= 0xff00;
cpm2_immr->im_cpmux.cmx_scr |= 0x0009;
pinfo->brg = 2;

Newbie question on Linux-PPC

[Wolfgang Denk]

In message <3B58B875DBDE504F94D2A1A1C9DF6F1FD00500 at 
bglnt005.asia.ad.flextronics.com> you wrote:
> I am having a MPC8260 based board with the following memory map.
>   
> Device  Start address End address
> EPROM   0x0x03FF
> SDRAM   0x04000x13FF
>  
> I have a doubt regarding Linux Port onto this board. I have read on the web
> that Linux usually expects the SDRAM at 0x0, is it that the porting of linux
> onto this board is totally impossible? If the porting is possible can anyone

No, proting is still possible, it involves just one additional  step:
fixong your boot loader to provide a different memory map.

> help me out where to change the memory mapping of Linux for MPC8260?

In your boot loader.

> --_=_NextPart_001_01C5666C.2B0053B0
> Content-Type: text/html
> Content-Transfer-Encoding: quoted-printable
> 
>