LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [RFC][PATCH] QE device tree node definition
From: Li Yang @ 2006-09-25 10:02 UTC (permalink / raw)
  To: linuxppc-dev

Here is OF device tree node spec used in QE/8360 support patches.

Signed-off-by: Jiang Bo <Tanya.jiang@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>

---
This is a repost of previous patch to be reviewed together
with QE/8360 support patches.
Vitaly will add CPM part and maybe post an integrated
spec of QE/CPM later.

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 5c0ba23..b3218a1 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1442,6 +1442,231 @@ platforms are moved over to use the flat
        };
 
 
+   h) Freescale QUICC Engine module (QE)
+   This represents qe module that is installed on PowerQUICC II Pro.
+   Hopefully it will merge backward compatibility with CPM/CPM2.
+   Basically, it is a bus of devices, that could act more or less
+   as a complete entity (UCC, USB etc ). All of them should be siblings on
+   the "root" qe node, using the common properties from there.
+   The description below applies to the the qe of MPC8360 and
+   more nodes and properties would be extended in the future.
+
+   i) Root QE device
+
+   Required properties:
+   - device_type : should be "qe";
+   - model : precise model of the QE, Can be "QE", "CPM", or "CPM2"
+   - 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.
+   - bus-frequency : the clock frequency for QUICC Engine.
+  
+   Recommended properties
+   - brg-frequency : the internal clock source frequency for baud-rate
+     generators in Hz.
+
+   Example:
+	qe@e0100000 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		#interrupt-cells = <2>;
+		device_type = "qe";
+		model = "QE";
+		ranges = <0 e0100000 00100000>;
+		reg = <e0100000 480 e0110000 c000>;
+		brg-frequency = <0>;
+		bus-frequency = <179A7B00>;
+	}
+
+
+   ii) 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".
+   - 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";
+	};
+
+
+   iii) USB (Universal Serial Bus Controller)
+
+   Required properties:
+   - device_type : should be "usb".
+   - compatible : could be "qe_udc" or "fhci-hcd".
+   - mode : the could be "host" or "slave".
+   - 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";
+	};
+
+
+   iv) UCC (Unified Communications Controllers)
+
+   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 : represents the UCC receive clock source.
+     0x00 : clock source is disabled;
+     0x1~0x10 : clock source is BRG1~BRG16 respectively;
+     0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively.
+   - t--clock: represents the UCC transmit clock source;
+     0x00 : clock source is disabled;
+     0x1~0x10 : clock source is BRG1~BRG16 respectively;
+     0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively.
+   - 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>;
+	};
+
+
+   v) 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.
+   - num-ports : number of Parallel I/O ports
+
+   Example:
+	par_io@1400 {
+		reg = <1400 100>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		device_type = "par_io";
+		num-ports = <7>;
+		ucc_pin@01 {
+			......
+		};
+
+
+   vi) 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.
 
 

^ permalink raw reply related

* Re: linux-2.6 system ACE driver - need help
From: Ameet Patil @ 2006-09-25  9:23 UTC (permalink / raw)
  To: agnel juni; +Cc: linuxppc-embedded
In-Reply-To: <20060919224349.25812.qmail@web8408.mail.in.yahoo.com>

agnel juni wrote:
> Hi Ameet
>
> I have posted a few messages regarding Ssytem ACE driver for Linux-2.6.
>
> We are working on a AMCC 440SPe based custom board.
>
> We applied the patch from
> //http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>  //and applied against 2.6.16-2 kernel.
>
> We are trying to make the driver work in interrupt mode.
>
> First, I would like to know if the driver tested in interrupt mode.
>
> We are able to mount the CF, but it is very inconsistent.
>
> Same is the case with fdisk command. When it fails,we get errors which you could see in the screen-dump below.//
> //
> Are we missing to apply the right patch? Please let us know your 
> inputs to go forward.
> Looking forwards for your reply.
>
> Thanks
> Junita
>
> /*************** Screen dump ********************/
> # fdisk /dev/xsysace
> 1. sector = 0 xsa_cur_req->sector=0
> System ACE: Error 0 when reading sector 2.
> 2. sector = 2 xsa_cur_req->sector=16
> end_request: I/O error, System ACE: Error 0 when reading sectoru dev 
> xsa, sector 16
> Buffer I/O error on device xsa, logical block 2
> 1. sector = 184 xsa_cur_req->sector=184
>  
> Command (m for help): p
>  
> Disk /dev/xsysace: 524 MB, 524869632 bytes
> 17 heads, 59 sectors/track, 1022 cylinders
> Units = cylinders of 1003 * 512 = 513536 bytes
>  
>        Device Boot      Start         End      Blocks   Id  System
> /dev/xsysace1               1        1022      512503+   6  FAT16
>  
> Command (m for help): q
> And for 'mount'
> #
> #
> # mount -t msdos /dev/xsysace /root/cf
> 1. sector = 0 xsa_cur_req->sector=0
> 1. sector = 503 xsa_cur_req->sector=503
> 1. sector = 504 xsa_cur_req->sector=504
> 1. sector = 506 xsa_cur_req->sector=506
> 1. sector = 508 xsa_cur_req->sector=508
> 1. sector = 510 xsa_cur_req->sector=510
> # cd /root/cf
> < Here Prints Some Symbols like + - etc, which i am
>   not able to capture/copy -------------ERROR
> b: No such file or directory--------------------------------ERROR
> pci.h
> #
> Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.n0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.0Minicom2.00.d#
> # cp pci.h /root/
> # cd ../
> # ls
> app     cf      hello1  pci.h
> #
> #/root
>  /dev/xsysace /root/cf
> FAT: bogus number of reserved sectors
> VFS: Can't find a valid FAT filesystem on dev xsa.
> mount: Mounting /dev/xsysace on /root/cf failed: Invalid argument
> #
>  
>
>
> //
>
>
>
> //
>
> ------------------------------------------------------------------------
> Find out what India is talking about on - Yahoo! Answers India 
> <http://us.rd.yahoo.com/mail/in/yanswers/*http://in.answers.yahoo.com/>
> Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. 
> Get it NOW 
> <http://us.rd.yahoo.com/mail/in/messengertagline/*http://in.messenger.yahoo.com> 


Hi Agnel,
    The driver was last tested with 2.6.17 kernel and till date works 
fine in the interrupt mode. I have been using it since the last 4 months 
now. It should also work on 2.6.16-2 kernel I think, but I have not 
tested this. Have you made any changes to the driver? If so... please 
give the details so I can give you better feedback as to where things 
might have gone wrong. When time permits I shall try my patch on the 
2.6.16-2 kernel and let you know if it works for me.

Thanks,
-Ameet

^ permalink raw reply

* Re: [PATCH] aoa is pmac-only
From: Johannes Berg @ 2006-09-25  8:53 UTC (permalink / raw)
  To: Al Viro; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <20060923002425.GY29920@ftp.linux.org.uk>

On Sat, 2006-09-23 at 01:24 +0100, Al Viro wrote:

>  menu "Apple Onboard Audio driver"
> -	depends on SND!=n && PPC
> +	depends on SND!=n && PPC_PMAC

Oh, that's right.

Acked-by: Johannes Berg <johannes@sipsolutions.net>

johannes

^ permalink raw reply

* Re: Booting problems
From: Peter Korsgaard @ 2006-09-25  7:55 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <451608B7.9010707@dlasys.net>

>>>>> "David" == David H Lynch <dhlii@dlasys.net> writes:

Hi,

David>     I have tried blindly jiggering with the
David> CONFIG_ADVANCED_OPTIONS setting with no noticable effect.  The
David> total zImage.elf size is just shy of 3Mb.

David>     Does anyone have an idea what I need to do to be able to
David> load a larger image ?

How big is your vmlinux? I guess you are running into the 4MB limit.

See the recent thread about it:
http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/023977.html

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* Re: Lite5200 NFS mount issue
From: Grant Likely @ 2006-09-25  7:00 UTC (permalink / raw)
  To: Andersson Tord; +Cc: Linuxppc-embedded
In-Reply-To: <18CE82D3EF6EA84F9A1A79D6051A090028500C@CORPAPPL020.corp.saab.se>

On 9/21/06, Andersson Tord <Tord.Andersson@combitech.se> wrote:
> Hi,
>
> I have some additional information on the problems we had with NFS on the Lite5200 card and the
> 2.4.25 kernel (DENX linuxppc_2_4_devel 2006-04-06) .
> When analyzing the IP traffic with Etherreal, it was seen that the problems were
> caused by loss of fragmented IP-packets. When the IP fragmentation was removed by forcing NFS's
> UDP size to less than the Ethernet MTU size, the problems disappeared.
> We used the kernel NFS argument option to this effect;
>
>         nfsroot=${serverip}:${rootpath},rsize=1024,wsize=1024

After having similar problems, I've had good luck by forcing nfs to
use tcp by appending ',tcp' to the nfsroot= argument.

g.


-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* RE: Lite5200 NFS mount issue
From: Andersson Tord  @ 2006-09-25  6:54 UTC (permalink / raw)
  To: Edward Jubenville, Linuxppc-embedded

Hi,

Thanks for your reply! However, I don't think we have a network or
switch related issue here,=20
as the problem is also found when using a crossed ethernet-cable between
the host and the target.

Best regards,

Tord


>=20
> You may not be having a board problem or a kernel problem.  I=20
> had exactly the same problem with an almost identical=20
> configuration as you.  Using Etherreal at various points in=20
> my network, I found that an Ethernet switch in the=20
> communication path was dropping packets before the board ever=20
> saw them.  I solved it the same way that you did (with=20
> rsize/wsize), and it has worked fine ever since.
>=20
> See my post on 7/26/2006, subject "Re: Slow boot with NFS,=20
> server not responding".
>=20
> Ed Jubenville
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org=20
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20

^ permalink raw reply

* Trouble booting Kernel 2.6.12 on powerpc 8540
From: revathy @ 2006-09-25  5:51 UTC (permalink / raw)
  To: linuxppc-embedded

Hi,
   First time iam porting linux kernel 2.6.12 on MPC8540(PIC) board.In
platform code  i have set the CCSRBAR  to 0xff70 0000 which is the
default value for 8540. it gets hanged at "Uncompressing kernel image...ok".Iam
using u-boot-1.1.2.

Should i edit anything in .config file?

Thanks and Regards
Revathy

^ permalink raw reply

* Unable to boot kernel 2.6 from u-boot 1.1.2 in MPC8540
From: revathy @ 2006-09-25  6:15 UTC (permalink / raw)
  To: linuxppc-embedded

Hi all,

I am currently working on a MPC8540 based custom board to port linux-2.6.x. 
 iam using  kernel-2.6.12 in which platform code  CCSRBAR   is set to 0xff70 0000 which is the
default value for 8540 found from HRM. it hangs at "Uncompressing kernel image...ok".Iam
using u-boot-1.1.2.



Should i edit anything in .config file?
or am i missing something anywhere?

 Could someone help me to solve this issue.

Thanks and Regards
Revathy

^ permalink raw reply

* RE: kernel opps during PCI read
From: Liu Dave-r63238 @ 2006-09-25  3:54 UTC (permalink / raw)
  To: Tony Hardie, linuxppc-embedded
In-Reply-To: <CE711B0E5D7A1A4096A808997E00832901B32FEE@fmt-ex01.net.com>

[-- Attachment #1: Type: text/plain, Size: 2623 bytes --]

The machine checking is happening when you configuration read from PCI
bus.
please check the register settings for PCI.
 
-DAve

	Hiya, I'm running into the following issue running on our custom
PPC8270 (PQ2FADS style) system.

	It only seems to happen when we load the system just a little
(more PCI interrupts and transactions).

	 

	Any ideas?

	 

	 

	/ # [  456.440195] Machine check in kernel mode.

	[  456.442646] Caused by (from SRR1=41030): Transfer error ack
signal

	[  456.448828] Oops: machine check, sig: 7 [#1]

	[  456.453088] PREEMPT

	[  456.455269] NIP: C00119CC LR: C0011914 CTR: C0011334

	[  456.460233] REGS: c01fbd40 TRAP: 0200   Tainted: P
(2.6.17.3)

	[  456.466493] MSR: 00041030 <ME,IR,DR>  CR: 22002082  XER:
20000000

	[  456.472589] TASK = c01b5f20[0] 'swapper' THREAD: c01fa000

	[  456.477809] GPR00: 00000000 C01FBDF0 C01B5F20 00000000
FFFFFF7F 00000003 00000001 C01FBE18

	[  456.486164] GPR08: 00000000 F0010904 00000000 F0010907
00000000 100934F0 07FFF000 00000001

	[  456.494520] GPR16: 00800000 07FFE964 FFFFFFFF 00000000
07FFC6BC 007FFF00 FF800040 07FA7770

	[  456.502876] GPR24: C0210000 C01FBE58 00000001 000000CF
C01FBE18 000000A0 C024A000 C03AAA00

	[  456.511406] NIP [C00119CC] indirect_read_config+0x100/0x14c

	[  456.516977] LR [C0011914] indirect_read_config+0x48/0x14c

	[  456.522373] Call Trace:

	[  456.524812] [C01FBDF0] [C01FA028]
init_thread_union+0x28/0x2000 (unreliable)

	[  456.531862] [C01FBE10] [C00E2FB0]
pci_bus_read_config_byte+0x60/0xa8

	[  456.538216] [C01FBE50] [C909373C] OnInterrupt+0x40/0x178
[bridge]

	[  456.544309] [C01FBE70] [C003EA54] handle_IRQ_event+0x64/0xb8

	[  456.549966] [C01FBE90] [C003EBE0] __do_IRQ+0x138/0x1c0

	[  456.555102] [C01FBEC0] [C0009D04] do_IRQ+0x44/0x88

	[  456.559889] [C01FBEE0] [C0004914] ret_from_except+0x0/0x14

	[  456.565372] [C01FBFA0] [C000C9B8] cpu_idle+0xe0/0xf8

	[  456.570334] [C01FBFB0] [C0003A64] rest_init+0x3c/0x4c

	[  456.575382] [C01FBFC0] [C01FC6C4] start_kernel+0x1d0/0x228

	[  456.580865] [C01FBFF0] [000032C0] 0x32c0

	[  456.584781] Instruction dump:

	[  456.587741] bb410008 38210020 7c0803a6 4e800020 887f004c
813e0010 5460063e 7c004a78

	[  456.595487] 3120ffff 7d490110 4bffff70 7c0928ae <0c000000>
4c00012c 901c0000 38600000

	 [  456.615184] Kernel panic - not syncing: Aiee, killing
interrupt handler!

	 

	Cheers

	Tony

	 

	Tony Hardie B.Sc
	VX Software Architect
	Net.com
	6900 Paseo Padre Parkway
	Fremont
	CA, 94555
	Ph: 510-574-2386
	Mob: 510-449-4339

	 


[-- Attachment #2: Type: text/html, Size: 11623 bytes --]

^ permalink raw reply

* Re: AC power not detected if no battery present
From: Jeremy Kerr @ 2006-09-25  0:40 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <1159081888.5924.20.camel@localhost.localdomain>

Ben,

> Maybe simply buy forcing it when there is no battery ? I fail to see
> how the machine could be up without battery _and_ without AC :)

"It should be noted that, unlike PC's, computers running Mac OS do not 
use conventional power supplies, and instead use power crystals."

  -- http://uncyclopedia.org/wiki/Mac_OS_X



Jeremy

^ permalink raw reply

* [PATCH] update powerpc defconfig files after libata kconfig breakage
From: Olaf Hering @ 2006-09-24 18:53 UTC (permalink / raw)
  To: Paul Mackeras, linuxppc-dev


Update defconfig files after libata .config breakage

 sed -i 's/CONFIG_SCSI_SATA_/CONFIG_SATA_/;s/CONFIG_SCSI_SATA/CONFIG_ATA/' arch/powerpc/configs/*g

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 arch/powerpc/configs/chrp32_defconfig       |    2 +-
 arch/powerpc/configs/g5_defconfig           |   28 ++++++++++++++--------------
 arch/powerpc/configs/iseries_defconfig      |    2 +-
 arch/powerpc/configs/mpc7448_hpc2_defconfig |   28 ++++++++++++++--------------
 arch/powerpc/configs/mpc834x_itx_defconfig  |   28 ++++++++++++++--------------
 arch/powerpc/configs/pmac32_defconfig       |    2 +-
 arch/powerpc/configs/ppc64_defconfig        |   28 ++++++++++++++--------------
 arch/powerpc/configs/pseries_defconfig      |    2 +-
 8 files changed, 60 insertions(+), 60 deletions(-)

Index: linux-2.6/arch/powerpc/configs/chrp32_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/chrp32_defconfig
+++ linux-2.6/arch/powerpc/configs/chrp32_defconfig
@@ -492,7 +492,7 @@ CONFIG_SCSI_SPI_ATTRS=y
 # 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_ATA is not set
 # CONFIG_SCSI_HPTIOP is not set
 # CONFIG_SCSI_BUSLOGIC is not set
 # CONFIG_SCSI_DMX3191D is not set
Index: linux-2.6/arch/powerpc/configs/g5_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/g5_defconfig
+++ linux-2.6/arch/powerpc/configs/g5_defconfig
@@ -490,23 +490,23 @@ CONFIG_SCSI_SPI_ATTRS=y
 # CONFIG_MEGARAID_NEWGEN is not set
 # CONFIG_MEGARAID_LEGACY is not set
 # CONFIG_MEGARAID_SAS is not set
-CONFIG_SCSI_SATA=y
-# CONFIG_SCSI_SATA_AHCI is not set
-CONFIG_SCSI_SATA_SVW=y
+CONFIG_ATA=y
+# CONFIG_SATA_AHCI is not set
+CONFIG_SATA_SVW=y
 # CONFIG_SCSI_ATA_PIIX is not set
-# CONFIG_SCSI_SATA_MV is not set
-# CONFIG_SCSI_SATA_NV is not set
+# CONFIG_SATA_MV is not set
+# CONFIG_SATA_NV is not set
 # CONFIG_SCSI_PDC_ADMA is not set
 # CONFIG_SCSI_HPTIOP is not set
-# CONFIG_SCSI_SATA_QSTOR is not set
-# CONFIG_SCSI_SATA_PROMISE is not set
-# CONFIG_SCSI_SATA_SX4 is not set
-# CONFIG_SCSI_SATA_SIL is not set
-# CONFIG_SCSI_SATA_SIL24 is not set
-# CONFIG_SCSI_SATA_SIS is not set
-# CONFIG_SCSI_SATA_ULI is not set
-# CONFIG_SCSI_SATA_VIA is not set
-# CONFIG_SCSI_SATA_VITESSE is not set
+# CONFIG_SATA_QSTOR is not set
+# CONFIG_SATA_PROMISE is not set
+# CONFIG_SATA_SX4 is not set
+# CONFIG_SATA_SIL is not set
+# CONFIG_SATA_SIL24 is not set
+# CONFIG_SATA_SIS is not set
+# CONFIG_SATA_ULI is not set
+# CONFIG_SATA_VIA is not set
+# CONFIG_SATA_VITESSE is not set
 # CONFIG_SCSI_BUSLOGIC is not set
 # CONFIG_SCSI_DMX3191D is not set
 # CONFIG_SCSI_EATA is not set
Index: linux-2.6/arch/powerpc/configs/iseries_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/iseries_defconfig
+++ linux-2.6/arch/powerpc/configs/iseries_defconfig
@@ -475,7 +475,7 @@ CONFIG_SCSI_FC_ATTRS=y
 # 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_ATA is not set
 # CONFIG_SCSI_HPTIOP is not set
 # CONFIG_SCSI_BUSLOGIC is not set
 # CONFIG_SCSI_DMX3191D is not set
Index: linux-2.6/arch/powerpc/configs/mpc7448_hpc2_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/mpc7448_hpc2_defconfig
+++ linux-2.6/arch/powerpc/configs/mpc7448_hpc2_defconfig
@@ -413,23 +413,23 @@ CONFIG_BLK_DEV_SD=y
 # CONFIG_MEGARAID_NEWGEN is not set
 # CONFIG_MEGARAID_LEGACY is not set
 # CONFIG_MEGARAID_SAS is not set
-CONFIG_SCSI_SATA=y
-# CONFIG_SCSI_SATA_AHCI is not set
-# CONFIG_SCSI_SATA_SVW is not set
+CONFIG_ATA=y
+# CONFIG_SATA_AHCI is not set
+# CONFIG_SATA_SVW is not set
 # CONFIG_SCSI_ATA_PIIX is not set
-CONFIG_SCSI_SATA_MV=y
-# CONFIG_SCSI_SATA_NV is not set
+CONFIG_SATA_MV=y
+# CONFIG_SATA_NV is not set
 # CONFIG_SCSI_PDC_ADMA is not set
 # CONFIG_SCSI_HPTIOP is not set
-# CONFIG_SCSI_SATA_QSTOR is not set
-# CONFIG_SCSI_SATA_PROMISE is not set
-# CONFIG_SCSI_SATA_SX4 is not set
-# CONFIG_SCSI_SATA_SIL is not set
-# CONFIG_SCSI_SATA_SIL24 is not set
-# CONFIG_SCSI_SATA_SIS is not set
-# CONFIG_SCSI_SATA_ULI is not set
-# CONFIG_SCSI_SATA_VIA is not set
-# CONFIG_SCSI_SATA_VITESSE is not set
+# CONFIG_SATA_QSTOR is not set
+# CONFIG_SATA_PROMISE is not set
+# CONFIG_SATA_SX4 is not set
+# CONFIG_SATA_SIL is not set
+# CONFIG_SATA_SIL24 is not set
+# CONFIG_SATA_SIS is not set
+# CONFIG_SATA_ULI is not set
+# CONFIG_SATA_VIA is not set
+# CONFIG_SATA_VITESSE is not set
 # CONFIG_SCSI_BUSLOGIC is not set
 # CONFIG_SCSI_DMX3191D is not set
 # CONFIG_SCSI_EATA is not set
Index: linux-2.6/arch/powerpc/configs/mpc834x_itx_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/mpc834x_itx_defconfig
+++ linux-2.6/arch/powerpc/configs/mpc834x_itx_defconfig
@@ -464,23 +464,23 @@ CONFIG_SCSI_SPI_ATTRS=y
 # CONFIG_MEGARAID_NEWGEN is not set
 # CONFIG_MEGARAID_LEGACY is not set
 # CONFIG_MEGARAID_SAS is not set
-CONFIG_SCSI_SATA=y
-# CONFIG_SCSI_SATA_AHCI is not set
-# CONFIG_SCSI_SATA_SVW is not set
+CONFIG_ATA=y
+# CONFIG_SATA_AHCI is not set
+# CONFIG_SATA_SVW is not set
 # CONFIG_SCSI_ATA_PIIX is not set
-# CONFIG_SCSI_SATA_MV is not set
-# CONFIG_SCSI_SATA_NV is not set
+# CONFIG_SATA_MV is not set
+# CONFIG_SATA_NV is not set
 # CONFIG_SCSI_PDC_ADMA is not set
 # CONFIG_SCSI_HPTIOP is not set
-# CONFIG_SCSI_SATA_QSTOR is not set
-# CONFIG_SCSI_SATA_PROMISE is not set
-# CONFIG_SCSI_SATA_SX4 is not set
-CONFIG_SCSI_SATA_SIL=y
-# CONFIG_SCSI_SATA_SIL24 is not set
-# CONFIG_SCSI_SATA_SIS is not set
-# CONFIG_SCSI_SATA_ULI is not set
-# CONFIG_SCSI_SATA_VIA is not set
-# CONFIG_SCSI_SATA_VITESSE is not set
+# CONFIG_SATA_QSTOR is not set
+# CONFIG_SATA_PROMISE is not set
+# CONFIG_SATA_SX4 is not set
+CONFIG_SATA_SIL=y
+# CONFIG_SATA_SIL24 is not set
+# CONFIG_SATA_SIS is not set
+# CONFIG_SATA_ULI is not set
+# CONFIG_SATA_VIA is not set
+# CONFIG_SATA_VITESSE is not set
 # CONFIG_SCSI_BUSLOGIC is not set
 # CONFIG_SCSI_DMX3191D is not set
 # CONFIG_SCSI_EATA is not set
Index: linux-2.6/arch/powerpc/configs/pmac32_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/pmac32_defconfig
+++ linux-2.6/arch/powerpc/configs/pmac32_defconfig
@@ -682,7 +682,7 @@ CONFIG_SCSI_AIC7XXX_OLD=m
 # 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_ATA is not set
 # CONFIG_SCSI_HPTIOP is not set
 # CONFIG_SCSI_BUSLOGIC is not set
 # CONFIG_SCSI_DMX3191D is not set
Index: linux-2.6/arch/powerpc/configs/ppc64_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/ppc64_defconfig
+++ linux-2.6/arch/powerpc/configs/ppc64_defconfig
@@ -520,23 +520,23 @@ CONFIG_SCSI_ISCSI_ATTRS=m
 # CONFIG_MEGARAID_NEWGEN is not set
 # CONFIG_MEGARAID_LEGACY is not set
 # CONFIG_MEGARAID_SAS is not set
-CONFIG_SCSI_SATA=y
-# CONFIG_SCSI_SATA_AHCI is not set
-CONFIG_SCSI_SATA_SVW=y
+CONFIG_ATA=y
+# CONFIG_SATA_AHCI is not set
+CONFIG_SATA_SVW=y
 # CONFIG_SCSI_ATA_PIIX is not set
-# CONFIG_SCSI_SATA_MV is not set
-# CONFIG_SCSI_SATA_NV is not set
+# CONFIG_SATA_MV is not set
+# CONFIG_SATA_NV is not set
 # CONFIG_SCSI_PDC_ADMA is not set
 # CONFIG_SCSI_HPTIOP is not set
-# CONFIG_SCSI_SATA_QSTOR is not set
-# CONFIG_SCSI_SATA_PROMISE is not set
-# CONFIG_SCSI_SATA_SX4 is not set
-# CONFIG_SCSI_SATA_SIL is not set
-# CONFIG_SCSI_SATA_SIL24 is not set
-# CONFIG_SCSI_SATA_SIS is not set
-# CONFIG_SCSI_SATA_ULI is not set
-# CONFIG_SCSI_SATA_VIA is not set
-# CONFIG_SCSI_SATA_VITESSE is not set
+# CONFIG_SATA_QSTOR is not set
+# CONFIG_SATA_PROMISE is not set
+# CONFIG_SATA_SX4 is not set
+# CONFIG_SATA_SIL is not set
+# CONFIG_SATA_SIL24 is not set
+# CONFIG_SATA_SIS is not set
+# CONFIG_SATA_ULI is not set
+# CONFIG_SATA_VIA is not set
+# CONFIG_SATA_VITESSE is not set
 # CONFIG_SCSI_BUSLOGIC is not set
 # CONFIG_SCSI_DMX3191D is not set
 # CONFIG_SCSI_EATA is not set
Index: linux-2.6/arch/powerpc/configs/pseries_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/pseries_defconfig
+++ linux-2.6/arch/powerpc/configs/pseries_defconfig
@@ -506,7 +506,7 @@ CONFIG_SCSI_SAS_ATTRS=m
 # 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_ATA is not set
 # CONFIG_SCSI_HPTIOP is not set
 # CONFIG_SCSI_BUSLOGIC is not set
 # CONFIG_SCSI_DMX3191D is not set

^ permalink raw reply

* Re: [PATCH] UPIO_TSI cleanup
From: Sergei Shtylyov @ 2006-09-24 15:00 UTC (permalink / raw)
  To: Al Viro; +Cc: linuxppc-dev, rmk+serial
In-Reply-To: <E1GQvYX-0002iX-IN@ZenIV.linux.org.uk>

Hello.

Al Viro wrote:
> (le32_to_cpu(x) >> 8) & 0xff is a very odd way to spell (x >> 16) & 0xff,
> even if that code is hit only on ppc.  The value is host-endian - we've
> got it from readl(), after all...

> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
>  drivers/serial/8250.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)

> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index 0ae9ced..10c2daa 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c

    Shouldn't this go to rmk+serial@arm.linux.org.uk instead?

> @@ -320,8 +320,8 @@ #endif
>  
>  	case UPIO_TSI:
>  		if (offset == UART_IIR) {
> -			tmp = readl((u32 *)(up->port.membase + UART_RX));
> -			return (cpu_to_le32(tmp) >> 8) & 0xff;
> +			tmp = readl(up->port.membase + (UART_IIR & ~3));
> +			return (tmp >> 16) & 0xff; /* UART_IIR % 4 == 2 */
>  		} else
>  			return readb(up->port.membase + offset);
>  

    I'd also like to suggest actually writing to IER in the serial_out() even 
if the UUE bit is set, jusk mask 2 MSBs off (Xscale UART detection code which 
breaks Tsi10x UART sould have been CONFIG_ARM dependent I think). The whole 
UPIO_TSI thing looks much like an abuse to me, however it still seems to be a 
necessary evil... :-/

WBR, Sergei

^ permalink raw reply

* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: Grant Likely @ 2006-09-24 14:35 UTC (permalink / raw)
  To: David H. Lynch Jr.; +Cc: linuxppc-embedded
In-Reply-To: <45161ADB.4020106@dlasys.net>

On 9/23/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> > I've been half heartedly looking at what needs to be done to generate
> > a device tree based on either system.mhs or xparameters.h.  I'm
> > probably going to write a tiny C program that is compiled against
> > xparameters.h and spits out a valid dts file.  The dts file can then
> > be run through the device tree compiler to produce the flattened
> > device tree structure.
>     That sounds somewhat interesting.
>
>     But as was somewhat raised elsewhere - what about partial
> reprogramming the FPGA on the fly ?

Then you'll need to register/unregister devices from the platform bus
on the fly (assuming the FPGA is reprogrammed after control is passed
to Linux).  The device tree is primarily for passing information from
the boot loader to linux.  Once linux is booted and the fdt is used to
populate the platform buss, you can safely ignore it.

> > Device trees don't have to be static.  They can be generated/modified
> > on the fly if the bootloader supports it.  Or you can pass a different
> > tree depending on what IP you have on the board.
>     Can you populate the tree dynamically inside the Linux setup code ?

Yes; there is a common library that is being developed to
generate/modify the device tree from anywhere; boot loader, inside the
kernel (like for kexec), etc.  Search the mailing list.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* [PATCH] enable sysrq in pmac32_defconfig
From: Olaf Hering @ 2006-09-24  8:38 UTC (permalink / raw)
  To: Paul Mackeras, linuxppc-dev


Enable sysrq also for pmac32

Signed-off-by: Olaf Hering <olaf@aepfle.de>

Index: linux-2.6/arch/powerpc/configs/pmac32_defconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/configs/pmac32_defconfig
+++ linux-2.6/arch/powerpc/configs/pmac32_defconfig
@@ -1826,7 +1826,7 @@ CONFIG_OPROFILE=y
 # Kernel hacking
 #
 # CONFIG_PRINTK_TIME is not set
-# CONFIG_MAGIC_SYSRQ is not set
+CONFIG_MAGIC_SYSRQ=y
 # CONFIG_UNUSED_SYMBOLS is not set
 CONFIG_DEBUG_KERNEL=y
 CONFIG_LOG_BUF_SHIFT=14

^ permalink raw reply

* Re: AC power not detected if no battery present
From: Benjamin Herrenschmidt @ 2006-09-24  7:11 UTC (permalink / raw)
  To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060924064008.GA7925@aepfle.de>

On Sun, 2006-09-24 at 08:40 +0200, Olaf Hering wrote:
> PMU_PWR_AC_PRESENT in pmu_power_flags is never set if booted without
> battery. This leads to 'AC Power' == 0 in /proc/pmu/info.
> How can this be fixed properly?

Maybe simply buy forcing it when there is no battery ? I fail to see how
the machine could be up without battery _and_ without AC :)

Ben.

^ permalink raw reply

* AC power not detected if no battery present
From: Olaf Hering @ 2006-09-24  6:40 UTC (permalink / raw)
  To: linuxppc-dev


PMU_PWR_AC_PRESENT in pmu_power_flags is never set if booted without
battery. This leads to 'AC Power' == 0 in /proc/pmu/info.
How can this be fixed properly?

^ permalink raw reply

* Re: Ethernet driver for Linux kernel 2.6 running on ML403
From: David H. Lynch Jr. @ 2006-09-24  5:42 UTC (permalink / raw)
  To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0609191427o11146c54q650738bcb10f8d98@mail.gmail.com>

Grant Likely wrote:
>
> Step 1: run away
> Step 2: don't look back.
    There are days.

>
> Just kidding.  Unless you want to help move Virtex support from
> arch/ppc to arch/powerpc, you don't really need to worry about device
> trees for a while.
>
> If you are interested, look at
> Documentation/powerpc/booting-without-of.txt.  Then start poking Matt
> Porter about when he's going to get 4xx ported to arch/powerpc.
    That depends. I am a consultant. My works is primarily paid for by
my clients, clients.
    I tinker when I am not otherwise busy. But I am very busy, despite
being short on work !?

   
>
> I've been half heartedly looking at what needs to be done to generate
> a device tree based on either system.mhs or xparameters.h.  I'm
> probably going to write a tiny C program that is compiled against
> xparameters.h and spits out a valid dts file.  The dts file can then
> be run through the device tree compiler to produce the flattened
> device tree structure.
    That sounds somewhat interesting.

    But as was somewhat raised elsewhere - what about partial
reprogramming the FPGA on the fly ?
   
    One of the fundimental issues I am facing, is that I have to deal
with a system where nothing is certain except that there is a
    ppc405 present. There will always be more than that - but there is
not another component that MUST be present.
    As things go forward, more optional components get added.
    Pico is not yet doing partial FPGA reprogramming on the fly - but I
am certain it is coming. It fits perfectly with the goals and objectives
    of the company and its clients.

    For the moment the problem is fairly small. But it is only going to
get worse with time. The decisions I make now, will either make my life
pleasant or horrible later.
    Better to work towards where we are going now.

    I guess I need to digest
Documentation/powerpc/booting-without-of.txt. now. At the moment things
are  busy
>
>>
>>      The vague Picture I have is the have something to do with some
>> datastructure that Mac's typically create at or prior to boot. And
>> that for
>> embedded systems we are building them
>>      externally compiling them and then attaching the compiled device
>> tree
>> to our project.
>
> That right.  You don't compile device base addresses, irqs, etc into
> the kernel.  You pass them in at boot time with a data structure.
>
>>
>>      I got a Xilinv V4 device currently with a Pic, UartLite, TEMAC,
>> Flash
>> and Keyhole (pseuodo serial host interface). Of those it is only certain
>> that the flash will always be there.
>>      We have bit images with Keyhole only, Uartlite only TEMAC only,
>> Sometimes we have a Pic sometimes not. I was trying to get to the
>> point were
>> I could dynamically add what was there
>>      to Platform devices during initialization.
>>
>>      If Device trees are static, then do they even apply to what I
>> have to
>> deal with ?
>
> Device trees don't have to be static.  They can be generated/modified
> on the fly if the bootloader supports it.  Or you can pass a different
> tree depending on what IP you have on the board.
    Can you populate the tree dynamically inside the Linux setup code ?

>
> Cheers,
> g.
>


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

^ permalink raw reply

* Booting problems
From: David H. Lynch Jr. @ 2006-09-24  4:25 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]


    I am booting a compressed initramfs kernel.

    I have hit what appears to be a size issue. simply adding more data
to the initramfs source directory,
    or adding even a small amount of unused code to my  kernel causes it
to hang after relocation during boot.
    The point of failure varies with the size of the kernel image.

    I have tried blindly jiggering with the  CONFIG_ADVANCED_OPTIONS
setting with no noticable effect.
    The total zImage.elf size is just shy of 3Mb.

    Does anyone have an idea what I need to do to be able to load a
larger image ?

[-- Attachment #2: Type: text/html, Size: 994 bytes --]

^ permalink raw reply

* RE: MPC5200b kernel module memory mapping
From: Steven Kaiser @ 2006-09-23 20:55 UTC (permalink / raw)
  To: 'Markus Klotzbücher'; +Cc: linuxppc-embedded
In-Reply-To: <87slilxf92.fsf@creamnet.de>

Markus:

> > sure I am setting up the LocalBus chip select registers ok.
> 
> I would guess this is not the case. What kind of device is this?

You are correct.  I was so concerned about the linux driver stuff (
request_region(), ioremap(), etc ), that I was locked into endless studies
on that and see now I clearly overlooked some simple chip setting up.  Doh!
Thanks for reorienting my focus--

My chip is a Freescale MPC5200b:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5200B

So here's what I've doing that seems to work, as verified by an
oscilloscope:

// 64k I/O Port Space: 0x60000000 - 0x60001000 -> 0x60000000 - 0x60001000 
#define MPC5xxx_MM_CS2_START	(MPC5xxx_MBAR + 0x0014)
#define MPC5xxx_MM_CS2_STOP	(MPC5xxx_MBAR + 0x0018)
#define MPC5xxx_MM_IPBI		(MPC5xxx_MBAR + 0x0054)

#define MALab_MM_START		0x60000000U
#define MALab_MM_END		0x6000ffffU
#define MALab_MM_SIZE		0x00010000U

void *ioaddr = NULL;

int init_module(void) { ...

	// reserve a page of memory for our hardware /proc/iomem
	if ( check_region(MALab_MM_START,MALab_MM_SIZE) ) {
		printk (KERN_ALERT "LED init_module: memory already in
use\n");
		return -EBUSY;
	}
	request_region(MALab_MM_START,MALab_MM_SIZE,LED_DEVICE_NAME);

	// enable LocalBus chip select CS2 to hit on our address range
	*(volatile u32 *)MPC5xxx_MM_IPBI &= ~0x00040000;
	*(volatile u16 *)(MPC5xxx_MM_CS2_START + 2) = MALab_MM_START >> 16;
	*(volatile u16 *)(MPC5xxx_MM_CS2_STOP + 2) = MALab_MM_END >> 16;
	*(volatile u32 *)MPC5xxx_MM_IPBI |= 0x00040000;

	// LocalBus Chip Select 2 Configuration Register
	*(volatile u32 *)(MPC5xxx_MBAR + 0x0308) = 0x03031110;
	// LocalBus Chip Select Control Register
	*(volatile u32 *)(MPC5xxx_MBAR + 0x0318) |= 0x01000000;

	// map our physical address into kernal virtual address space
	ioaddr = ioremap(MALab_MM_START,MALab_MM_SIZE);
	printk(KERN_ALERT "ioaddr: 0x%08x\n", (u32)ioaddr);


then later, any of these calls work (even in interrupt routines it appears):

u32	buf[10];

	*(volatile u16 *)ioaddr = 0x5555;
	outw(0x5555,ioaddr);
	outsw(ioaddr,buf,10);

I guess this is simple stuff for most everybody here.

Steve

^ permalink raw reply

* RE: MPC5200b kernel module memory mapping
From: Steven Kaiser @ 2006-09-23 20:46 UTC (permalink / raw)
  To: 'Markus Klotzbücher'; +Cc: linuxppc-embedded
In-Reply-To: <87slilxf92.fsf@creamnet.de>

Markus:

> > sure I am setting up the LocalBus chip select registers ok.
> 
> I would guess this is not the case. What kind of device is this?

It is a Freescale MPC5200b:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5200B

You are correct.  I was so concerned about the linux driver stuff (
request_region(), ioremap(), etc ), that I was locked into endless studies
on that and see now I clearly overlooked some simple chip setting up.  Doh!
Thanks for reorienting my focus--

int init_module(void) { ...

	// reserve a page of memory for our hardware /proc/iomem
	if ( check_region(MALab_MM_START,MALab_MM_SIZE) ) {
		printk (KERN_ALERT "LED init_module: memory already in
use\n");
		return -EBUSY;
	}
	request_region(MALab_MM_START,MALab_MM_SIZE,LED_DEVICE_NAME);

	// enable LocalBus chip select CS2 to hit on our address range
	*(volatile u32 *)MPC5xxx_MM_IPBI &= ~0x00040000;
	*(volatile u16 *)(MPC5xxx_MM_CS2_START + 2) = MALab_MM_START >> 16;
	*(volatile u16 *)(MPC5xxx_MM_CS2_STOP + 2) = MALab_MM_END >> 16;
	*(volatile u32 *)MPC5xxx_MM_IPBI |= 0x00040000;

	// LocalBus Chip Select 2,3 Configuration Register
	*(volatile u32 *)(MPC5xxx_MBAR + 0x0308) = 0x03031110;
	*(volatile u32 *)(MPC5xxx_MBAR + 0x030c) = 0x03031110;
	// LocalBus Chip Select Control Register
	*(volatile u32 *)(MPC5xxx_MBAR + 0x0318) |= 0x01000000;

	// map our physical address into kernal virtual address space
	ioaddr = ioremap(MALab_MM_START,MALab_MM_SIZE);
	printk(KERN_ALERT "ioaddr: 0x%08x\n", (u32)ioaddr);


and later, any of these calls work:

^ permalink raw reply

* Re: [PATCH 2.6.19-rc1] ehca firmware interface based on Anton Blanchard's new hvcall interface
From: Hoang-Nam Nguyen @ 2006-09-23 20:45 UTC (permalink / raw)
  To: Roland Dreier
  Cc: pmac, linux-kernel, openib-general, openfabrics-ewg, linuxppc-dev,
	Christoph.Raisch/Germany/IBM
In-Reply-To: <adahcyzfkd0.fsf@cisco.com>

Hi Roland,
> Anyway both Paul and I merged with Linus today, so the hcall cleanup
> and ehca are both upstream.  It would be great if you could do a quick
> check to make sure that ehca works in Linus's current git tree.
I compiled Linus's git tree and did some basic tests successfully
with ehca (ipoib, userspace, netpipe tcp/ib).
Thanks!
Nam Nguyen

^ permalink raw reply

* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Sergei Shtylyov @ 2006-09-23 15:48 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: Matt Porter, Paul Mackerras, linuxppc-dev
In-Reply-To: <91D1965E-2377-4ADB-B6F9-2B5A1549D75B@kernel.crashing.org>

Hello.

Segher Boessenkool wrote:
>>    Well, is there need for duplication of size if "reg" prop must  be 
>> present anyway?

> No, not really.  But this way, "reg" can be absent, actually.

    Is this a joke? :-)
    Or you're supposing that UART is only usable to the bootwrapper? Or you're 
going to add support for this new prop to the main kernel as well?

> Segher

WBR, Sergei

^ permalink raw reply

* [PATCH] #elif that should've been #elif defined
From: Al Viro @ 2006-09-23 15:45 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel

 #elif CONFIG_44x
in ibm4xx.h should've been
 #elif defined(CONFIG_44x)

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
 include/asm-ppc/ibm4xx.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/asm-ppc/ibm4xx.h b/include/asm-ppc/ibm4xx.h
index cf62b69..499c146 100644
--- a/include/asm-ppc/ibm4xx.h
+++ b/include/asm-ppc/ibm4xx.h
@@ -86,7 +86,7 @@ #define _ISA_MEM_BASE	0
 #define PCI_DRAM_OFFSET	0
 #endif
 
-#elif CONFIG_44x
+#elif defined(CONFIG_44x)
 
 #if defined(CONFIG_BAMBOO)
 #include <platforms/4xx/bamboo.h>
-- 
1.4.2.GIT

^ permalink raw reply related

* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Segher Boessenkool @ 2006-09-23 10:15 UTC (permalink / raw)
  To: Mark A. Greer; +Cc: Paul Mackerras, Matt Porter, linuxppc-dev
In-Reply-To: <20060923081836.GA25298@mag.az.mvista.com>

> All I'm try to say is that "fw,address" is just like the "reg"  
> property
> except that it holds the effective addr not the physical addr and the
> size of the address is determined by the existence of "/cpus/64-bit"
> not #address-cells.  That's all.

Sounds good.

>> Yes.  Except a "cell" is not what you think it is.  A "cell" is the
>> size of numbers OF deals with internally; just deal with it.  Of
>> course, there's things like "#address-cells", which really mean
>> "#-32bit-things-per-address".
>
> Okay, well, when I talked about cells I meant "#-32bit-things-per- 
> address".
> Obviously it was silly of me to think that "#address-cells" meant  
> the # of
> address cells...

Some background might clear things up (or not)...  A "cell" is the
unit of data in a Forth system.  When OF was young (and not yet
called OF), all systems were 32-bit, and the 32-bit-thingies in
the properties (which weren't yet called properties) in the device
tree were called cells as well.  When 64-bit came into the picture,
everything fell apart.  The "correct" name for the property thingies
now is "integers as encoded with encode-int".  Maybe we can compromise
on calling it "property cells" or something.

The situation is even worse with "package", let's not go there :-)


Segher

^ permalink raw reply

* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Mark A. Greer @ 2006-09-23  8:18 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: Paul Mackerras, Matt Porter, linuxppc-dev
In-Reply-To: <74E4B2E4-B59C-4998-B9FC-A77245C6AF6B@kernel.crashing.org>

On Sat, Sep 23, 2006 at 02:54:12AM +0200, Segher Boessenkool wrote:
> >Here is where I think we are for getting the effective base addr
> >of the regs for the console uart in the bootwrapper:
> >
> >1) We add the "fw,address" property to the uart's dt node.  That
> >property provides the effective base address of the uart's registers
> >left over by the firmware.  The format is similar to that of the
> >"reg" property in that it contains an "address size" tuple.
> 
> I completely lost you here, sorry.  Maybe it's me.  Care to
> repeat this in a (perhaps more verbose) way that I might
> understand?

Well, I'm still new to the dt stuff and probably use the wrong
terminology all the time.  I tried to use the same type of description
that is used in ./Documentation/powerpc/booting-without-of.txt.

For example:

	'"reg" properties are always a tuple of the type "address size"
	where the number of cells of address and size is specified by
	the bus #address-cells and #size-cells.'

All I'm try to say is that "fw,address" is just like the "reg" property
except that it holds the effective addr not the physical addr and the
size of the address is determined by the existence of "/cpus/64-bit"
not #address-cells.  That's all.

> >2) The effective address width (32 or 64 bits) (i.e., the # cells in
> >the "address" portion of the tuple) is indicated by the presence of  
> >the
> >"/cpus/64-bit" property.  If it exists, the effective addr space is
> >64-bits wide (2 cells); if not, its 32-bits wide (1 cell).
> 
> Yes.  Except a "cell" is not what you think it is.  A "cell" is the
> size of numbers OF deals with internally; just deal with it.  Of
> course, there's things like "#address-cells", which really mean
> "#-32bit-things-per-address".

Okay, well, when I talked about cells I meant "#-32bit-things-per-address".
Obviously it was silly of me to think that "#address-cells" meant the # of
address cells...

Mark

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox