* 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
* 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
* 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: 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: [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: 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
* [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
* ML403 patch for UBOOT
From: alayrac @ 2006-09-25 11:21 UTC (permalink / raw)
To: Linuxppc-embedded
I'm new member of this mailing list an I'm looking for some information
on UBOOT on ML403.
stevea-mdi talk about a pacth from Ameet
(http://www.linux2knowmore.com) but I did not succeed to find this
pacth.
The one attached to the mail
(http://patchwork.ozlabs.org/linuxppc/patch?id=6502) seems to be for
linux 2.6.17-4 and not for UBOOT.
Is there something I'm doing wrong?
Where can I found a pacth for UBOOT for ML403?
Thank you in advance for any help
Chris
^ permalink raw reply
* RE: ML403 patch for UBOOT
From: Ming Liu @ 2006-09-25 12:34 UTC (permalink / raw)
To: christophe.alayrac; +Cc: Linuxppc-embedded
In-Reply-To: <1159183304.11649.17.camel@Serge-Linux>
Hi,
Here it is...
http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/023912.html
Regards
Ming
>From: alayrac <christophe.alayrac@univ-orleans.fr>
>Reply-To: christophe.alayrac@univ-orleans.fr
>To: Linuxppc-embedded@ozlabs.org
>Subject: ML403 patch for UBOOT
>Date: Mon, 25 Sep 2006 13:21:43 +0200
>
>I'm new member of this mailing list an I'm looking for some information
>on UBOOT on ML403.
>
>stevea-mdi talk about a pacth from Ameet
>(http://www.linux2knowmore.com) but I did not succeed to find this
>pacth.
>The one attached to the mail
>(http://patchwork.ozlabs.org/linuxppc/patch?id=6502) seems to be for
>linux 2.6.17-4 and not for UBOOT.
>
>Is there something I'm doing wrong?
>
>Where can I found a pacth for UBOOT for ML403?
>
>Thank you in advance for any help
>
>Chris
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn
^ permalink raw reply
* RE: ML403 patch for UBOOT
From: alayrac @ 2006-09-25 13:02 UTC (permalink / raw)
To: Linuxppc-embedded
In-Reply-To: <BAY110-F21CF9E20190CB4CC022CCFB2240@phx.gbl>
Le lundi 25 septembre 2006 à 12:34 +0000, Ming Liu a écrit :
> Hi,
> Here it is...
>
> http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/023912.html
>
> Regards
> Ming
>
Thank you Ming for your prompt reply. It is exactly the pacth I've found
previously.
The pacth start with the following lines :
diff -Naur linux-2.6.17-4.patch1/arch/ppc/platforms/4xx/xilinx_ml300.h
linux-2.6.17-4.working/arch/ppc/platforms/4xx/xilinx_ml300.h
--- linux-2.6.17-4.patch1/arch/ppc/platforms/4xx/xilinx_ml300.h 2006-07-25 16:42:50.000000000 -0400
+++ linux-2.6.17-4.working/arch/ppc/platforms/4xx/xilinx_ml300.h 2006-08-02 19:47:00.000000000 -0400
I understand from that that it try to change linux-2.6.17-4 xilinx_ml300.h
If I type from u-boot (1.1.4) source code directory
patch -i U-BOOT
with U-BOOT the text file containing that pacth then it stop askink for file path.
So I wonder if the pacth is for UBOOT or Linux 2.6.17-4 kernel source?
I should precise that I'm a beginner with Uboot and linux 2.6 (already port linux 2.4 on ML403 using BYU instructions)
I must miss something basic...
Thanks for your help
Chris
>
> >From: alayrac <christophe.alayrac@univ-orleans.fr>
> >Reply-To: christophe.alayrac@univ-orleans.fr
> >To: Linuxppc-embedded@ozlabs.org
> >Subject: ML403 patch for UBOOT
> >Date: Mon, 25 Sep 2006 13:21:43 +0200
> >
> >I'm new member of this mailing list an I'm looking for some information
> >on UBOOT on ML403.
> >
> >stevea-mdi talk about a pacth from Ameet
> >(http://www.linux2knowmore.com) but I did not succeed to find this
> >pacth.
> >The one attached to the mail
> >(http://patchwork.ozlabs.org/linuxppc/patch?id=6502) seems to be for
> >linux 2.6.17-4 and not for UBOOT.
> >
> >Is there something I'm doing wrong?
> >
> >Where can I found a pacth for UBOOT for ML403?
> >
> >Thank you in advance for any help
> >
> >Chris
> >
> >
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _________________________________________________________________
> 免费下载 MSN Explorer: http://explorer.msn.com/lccn
>
>
^ permalink raw reply
* Unable to boot linux on Xilinx ML403 board
From: Mohan Krishna T @ 2006-09-25 12:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <mailman.0.1159188664.24974.linuxppc-embedded@ozlabs.org>
Hi all,
I am working on Xilinx ML403 board. I am trying to boot with
Linux 2.4. My hardware includes a UART16550 and EMAC (OPB Ethernet) in
scatter gather mode. When I boot the linux. It is coming up to the following
point and hanging indefinitely. I have pasted my booting sequence below:
----------------------------------------------------------------------------
---------
loaded at: 00400000 0076F1E4
board data at: 0076C13C 0076C154
relocated to: 00405638 00405650
zimage at: 00405C03 004AE1BF
initrd at: 004AF000 0076B17B
avail ram: 00770000 08000000
Linux/PPC load: console=3Dtty1 console=3DttyS0,9600 ip=3Doff =
root=3D/dev/ram rw
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.4.20_mvl31-ml403 (mta=40xinmta20) (gcc version 3.3.1
(MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) =2378 Mon Sep 25 16:53:39 IST
2006
Xilinx Virtex-II Pro and Virtex-4 port (C) 2002-2004 MontaVista Software,
Inc. (source=40mvista.com)
On node 0 totalpages: 32768
zone(0): 32768 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=3Dtty1 console=3DttyS0,9600 ip=3Doff =
root=3D/dev/ram rw
Xilinx INTC =230 at 0x41200000 mapped to 0xFDFFE000
Calibrating delay loop... 199.88 BogoMIPS
Memory: 125080k available (1188k kernel code, 396k data, 56k init, 0k
highmem)
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
OCP uart ver 1.6.2 init complete
LSP Revision 42
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rgooch=40atnf.csiro.au)
devfs: boot_options: 0x1
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0xfdfff003 (irq =3D 29) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: using sgDMA mode.
eth0: No PHY detected. Assuming a PHY at address 0.
eth0: Xilinx EMAC =230 at 0x40C00000 mapped to 0xCA00D000, irq=3D31
eth0: id 2.0l; block id 11, type 1
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
----------------------------------------------------------------------------
----------
Thanks in advance..
Regards
Mohan Krishna
DISCLAIMER
=E2=80=9CThe information contained in this e-mail message and/or =
attachments to it may contain confidential or privileged information. If =
you are not the intended recipient, any dissemination, use, review, =
distribution, printing or copying of the information contained in this =
e-mail message and/or attachments to it are strictly prohibited. If you =
have received this communication in error, please notify us by reply =
e-mail or telephone and immediately and permanently delete the message and =
any attachments. Thank you=22=
^ permalink raw reply
* Inet error in uClib
From: tran vanle @ 2006-09-25 14:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 5704 bytes --]
Hi all
I have just build uClibc -0.9.28 with ppc_85xx-gcc ,platform powerpc with kernel 2.6.15 and i have this error
ppc_85xx-gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-builtin -nostdinc -D_LIBC -I../../include -I. -Os -funit-at-a-time -isystem /prodev/csprj/tools/denx/usr/bin/../lib/gcc/powerpc-linux/4.0.0/include -DNDEBUG -fpic -D_DL_FINI_CRT_COMPAT -c ether_addr.c -o ether_addr.o
In file included from ../../include/linux/posix_types.h:47,
from ../../include/linux/types.h:13,
from ../../include/linux/if_ether.h:24,
from ../../include/netinet/if_ether.h:26,
from ../../include/netinet/ether.h:26,
from ether_addr.c:32:
../../include/asm/posix_types.h:10: error: conflicting types for '__kernel_ino_t'
../../include/bits/kernel_types.h:39: error: previous declaration of '__kernel_ino_t' was here
../../include/asm/posix_types.h:11: error: redefinition of typedef '__kernel_mode_t'
../../include/bits/kernel_types.h:40: error: previous declaration of '__kernel_mode_t' was here
../../include/asm/posix_types.h:12: error: redefinition of typedef '__kernel_off_t'
../../include/bits/kernel_types.h:42: error: previous declaration of '__kernel_off_t' was here
../../include/asm/posix_types.h:13: error: redefinition of typedef '__kernel_pid_t'
../../include/bits/kernel_types.h:43: error: previous declaration of '__kernel_pid_t' was here
../../include/asm/posix_types.h:14: error: redefinition of typedef '__kernel_uid_t'
../../include/bits/kernel_types.h:44: error: previous declaration of '__kernel_uid_t' was here
../../include/asm/posix_types.h:15: error: redefinition of typedef '__kernel_gid_t'
../../include/bits/kernel_types.h:45: error: previous declaration of '__kernel_gid_t' was here
../../include/asm/posix_types.h:16: error: redefinition of typedef '__kernel_ptrdiff_t'
../../include/bits/kernel_types.h:48: error: previous declaration of '__kernel_ptrdiff_t' was here
../../include/asm/posix_types.h:17: error: redefinition of typedef '__kernel_time_t'
../../include/bits/kernel_types.h:49: error: previous declaration of '__kernel_time_t' was here
../../include/asm/posix_types.h:18: error: redefinition of typedef '__kernel_clock_t'
../../include/bits/kernel_types.h:51: error: previous declaration of '__kernel_clock_t' was here
../../include/asm/posix_types.h:21: error: redefinition of typedef '__kernel_suseconds_t'
../../include/bits/kernel_types.h:50: error: previous declaration of '__kernel_suseconds_t' was here
../../include/asm/posix_types.h:22: error: redefinition of typedef '__kernel_daddr_t'
../../include/bits/kernel_types.h:52: error: previous declaration of '__kernel_daddr_t' was here
../../include/asm/posix_types.h:23: error: redefinition of typedef '__kernel_caddr_t'
../../include/bits/kernel_types.h:53: error: previous declaration of '__kernel_caddr_t' was here
../../include/asm/posix_types.h:24: error: redefinition of typedef '__kernel_uid16_t'
../../include/bits/kernel_types.h:55: error: previous declaration of '__kernel_uid16_t' was here
../../include/asm/posix_types.h:25: error: redefinition of typedef '__kernel_gid16_t'
../../include/bits/kernel_types.h:56: error: previous declaration of '__kernel_gid16_t' was here
../../include/asm/posix_types.h:26: error: redefinition of typedef '__kernel_uid32_t'
../../include/bits/kernel_types.h:57: error: previous declaration of '__kernel_uid32_t' was here
../../include/asm/posix_types.h:27: error: redefinition of typedef '__kernel_gid32_t'
../../include/bits/kernel_types.h:58: error: previous declaration of '__kernel_gid32_t' was here
../../include/asm/posix_types.h:28: error: redefinition of typedef '__kernel_old_uid_t'
../../include/bits/kernel_types.h:59: error: previous declaration of '__kernel_old_uid_t' was here
../../include/asm/posix_types.h:29: error: redefinition of typedef '__kernel_old_gid_t'
../../include/bits/kernel_types.h:60: error: previous declaration of '__kernel_old_gid_t' was here
../../include/asm/posix_types.h:38: error: redefinition of typedef '__kernel_nlink_t'
../../include/bits/kernel_types.h:41: error: previous declaration of '__kernel_nlink_t' was here
../../include/asm/posix_types.h:39: error: redefinition of typedef '__kernel_ipc_pid_t'
../../include/bits/kernel_types.h:54: error: previous declaration of '__kernel_ipc_pid_t' was here
../../include/asm/posix_types.h:40: error: redefinition of typedef '__kernel_size_t'
../../include/bits/kernel_types.h:46: error: previous declaration of '__kernel_size_t' was here
../../include/asm/posix_types.h:41: error: redefinition of typedef '__kernel_ssize_t'
../../include/bits/kernel_types.h:47: error: previous declaration of '__kernel_ssize_t' was here
../../include/asm/posix_types.h:42: error: redefinition of typedef '__kernel_old_dev_t'
../../include/bits/kernel_types.h:61: error: previous declaration of '__kernel_old_dev_t' was here
../../include/asm/posix_types.h:49: error: redefinition of typedef '__kernel_loff_t'
../../include/bits/kernel_types.h:62: error: previous declaration of '__kernel_loff_t' was here
../../include/asm/posix_types.h:55: error: conflicting types for '__kernel_fsid_t'
../../include/bits/kernel_types.h:67: error: previous declaration of '__kernel_fsid_t' was here
make[2]: *** [ether_addr.o] Error 1
make[2]: Leaving directory `/home/vantran/usr/src/uClibc/libc/inet'
make[1]: *** [_dir_inet] Error 2
make[1]: Leaving directory `/home/vantran/usr/src/uClibc/libc'
make: *** [_dir_libc] Error 2
Please help me
Thanks all
---------------------------------
On Yahoo!7
Break a world record with Total Girl's World’s Largest Slumber Party
[-- Attachment #2: Type: text/html, Size: 6506 bytes --]
^ permalink raw reply
* [PATCH 2.6.19-rc1] ehea firmware interface based on Anton Blanchard's new hvcall interface
From: Jan-Bernd Themann @ 2006-09-25 13:50 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, pmac, linux-kernel,
linux-ppc, Christoph Raisch, Marcus Eder
Hello Jeff,
this eHEA patch reflects changes according to Anton's new hvcall interface
which has been commited in Paul's git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
Thanks to this change our pHYP interface needs less lines of code.
In addition to the above changes the patch includes a bug fix (port state
notification) and minor changes (default queue length, coding style updates).
Thanks,
Jan-Bernd Themann
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 13 -
drivers/net/ehea/ehea_main.c | 12
drivers/net/ehea/ehea_phyp.c | 559 +++++++++++++++++--------------------------
3 files changed, 244 insertions(+), 340 deletions(-)
diff -Nurp -X dontdiff kernel_ehea_28/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h
--- kernel_ehea_28/drivers/net/ehea/ehea.h 2006-09-25 06:53:20.937708434 -0700
+++ patched_kernel/drivers/net/ehea/ehea.h 2006-09-25 06:16:39.152956418 -0700
@@ -39,7 +39,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0028"
+#define DRV_VERSION "EHEA_0033"
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -50,6 +50,7 @@
#define EHEA_MAX_ENTRIES_SQ 32767
#define EHEA_MIN_ENTRIES_QP 127
+#define EHEA_SMALL_QUEUES
#define EHEA_NUM_TX_QP 1
#ifdef EHEA_SMALL_QUEUES
@@ -59,11 +60,11 @@
#define EHEA_DEF_ENTRIES_RQ2 1023
#define EHEA_DEF_ENTRIES_RQ3 1023
#else
-#define EHEA_MAX_CQE_COUNT 32000
-#define EHEA_DEF_ENTRIES_SQ 16000
-#define EHEA_DEF_ENTRIES_RQ1 32080
-#define EHEA_DEF_ENTRIES_RQ2 4020
-#define EHEA_DEF_ENTRIES_RQ3 4020
+#define EHEA_MAX_CQE_COUNT 4080
+#define EHEA_DEF_ENTRIES_SQ 4080
+#define EHEA_DEF_ENTRIES_RQ1 8160
+#define EHEA_DEF_ENTRIES_RQ2 2040
+#define EHEA_DEF_ENTRIES_RQ3 2040
#endif
#define EHEA_MAX_ENTRIES_EQ 20
diff -Nurp -X dontdiff kernel_ehea_28/drivers/net/ehea/ehea_main.c patched_kernel/drivers/net/ehea/ehea_main.c
--- kernel_ehea_28/drivers/net/ehea/ehea_main.c 2006-09-25 06:53:20.938708444 -0700
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2006-09-25 06:16:39.153956426 -0700
@@ -544,7 +544,7 @@ static irqreturn_t ehea_send_irq_handler
return IRQ_HANDLED;
}
-static irqreturn_t ehea_recv_irq_handler(int irq, void *param,
+static irqreturn_t ehea_recv_irq_handler(int irq, void *param,
struct pt_regs *regs)
{
struct ehea_port_res *pr = param;
@@ -553,7 +553,7 @@ static irqreturn_t ehea_recv_irq_handler
return IRQ_HANDLED;
}
-static irqreturn_t ehea_qp_aff_irq_handler(int irq, void *param,
+static irqreturn_t ehea_qp_aff_irq_handler(int irq, void *param,
struct pt_regs *regs)
{
struct ehea_port *port = param;
@@ -769,7 +769,7 @@ static void ehea_parse_eqe(struct ehea_a
if (EHEA_BMASK_GET(NEQE_PORT_UP, eqe)) {
if (!netif_carrier_ok(port->netdev)) {
ret = ehea_sense_port_attr(
- adapter->port[portnum]);
+ port);
if (ret) {
ehea_error("failed resensing port "
"attributes");
@@ -821,7 +821,7 @@ static void ehea_parse_eqe(struct ehea_a
netif_stop_queue(port->netdev);
break;
default:
- ehea_error("unknown event code %x", ec);
+ ehea_error("unknown event code %x, eqe=0x%lX", ec, eqe);
break;
}
}
@@ -850,7 +850,7 @@ static void ehea_neq_tasklet(unsigned lo
adapter->neq->fw_handle, event_mask);
}
-static irqreturn_t ehea_interrupt_neq(int irq, void *param,
+static irqreturn_t ehea_interrupt_neq(int irq, void *param,
struct pt_regs *regs)
{
struct ehea_adapter *adapter = param;
@@ -1845,7 +1845,7 @@ static int ehea_start_xmit(struct sk_buf
if (netif_msg_tx_queued(port)) {
ehea_info("post swqe on QP %d", pr->qp->init_attr.qp_nr);
- ehea_dump(swqe, sizeof(*swqe), "swqe");
+ ehea_dump(swqe, 512, "swqe");
}
ehea_post_swqe(pr->qp, swqe);
diff -Nurp -X dontdiff kernel_ehea_28/drivers/net/ehea/ehea_phyp.c patched_kernel/drivers/net/ehea/ehea_phyp.c
--- kernel_ehea_28/drivers/net/ehea/ehea_phyp.c 2006-09-25 06:53:20.939708454 -0700
+++ patched_kernel/drivers/net/ehea/ehea_phyp.c 2006-09-25 06:16:39.153956426 -0700
@@ -44,71 +44,99 @@ static inline u16 get_order_of_qentries(
#define H_ALL_RES_TYPE_MR 5
#define H_ALL_RES_TYPE_MW 6
-static long ehea_hcall_9arg_9ret(unsigned long opcode,
- unsigned long arg1, unsigned long arg2,
- unsigned long arg3, unsigned long arg4,
- unsigned long arg5, unsigned long arg6,
- unsigned long arg7, unsigned long arg8,
- unsigned long arg9, unsigned long *out1,
- unsigned long *out2,unsigned long *out3,
- unsigned long *out4,unsigned long *out5,
- unsigned long *out6,unsigned long *out7,
- unsigned long *out8,unsigned long *out9)
+static long ehea_plpar_hcall_norets(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7)
{
- long hret;
+ long ret;
int i, sleep_msecs;
for (i = 0; i < 5; i++) {
- hret = plpar_hcall_9arg_9ret(opcode,arg1, arg2, arg3, arg4,
- arg5, arg6, arg7, arg8, arg9, out1,
- out2, out3, out4, out5, out6, out7,
- out8, out9);
- if (H_IS_LONG_BUSY(hret)) {
- sleep_msecs = get_longbusy_msecs(hret);
+ ret = plpar_hcall_norets(opcode, arg1, arg2, arg3, arg4,
+ arg5, arg6, arg7);
+
+ if (H_IS_LONG_BUSY(ret)) {
+ sleep_msecs = get_longbusy_msecs(ret);
msleep_interruptible(sleep_msecs);
continue;
}
- if (hret < H_SUCCESS)
- ehea_error("op=%lx hret=%lx "
- "i1=%lx i2=%lx i3=%lx i4=%lx i5=%lx i6=%lx "
- "i7=%lx i8=%lx i9=%lx "
- "o1=%lx o2=%lx o3=%lx o4=%lx o5=%lx o6=%lx "
- "o7=%lx o8=%lx o9=%lx",
- opcode, hret, arg1, arg2, arg3, arg4, arg5,
- arg6, arg7, arg8, arg9, *out1, *out2, *out3,
- *out4, *out5, *out6, *out7, *out8, *out9);
- return hret;
+ if (ret < H_SUCCESS)
+ ehea_error("opcode=%lx ret=%lx"
+ " arg1=%lx arg2=%lx arg3=%lx arg4=%lx"
+ " arg5=%lx arg6=%lx arg7=%lx ",
+ opcode, ret,
+ arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7);
+
+ return ret;
}
+
return H_BUSY;
}
-u64 ehea_h_query_ehea_qp(const u64 adapter_handle, const u8 qp_category,
- const u64 qp_handle, const u64 sel_mask, void *cb_addr)
+static long ehea_plpar_hcall9(unsigned long opcode,
+ unsigned long *outs, /* array of 9 outputs */
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9)
{
- u64 dummy;
+ long ret;
+ int i, sleep_msecs;
- if ((((u64)cb_addr) & (PAGE_SIZE - 1)) != 0) {
- ehea_error("not on pageboundary");
- return H_PARAMETER;
+ for (i = 0; i < 5; i++) {
+ ret = plpar_hcall9(opcode, outs,
+ arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, arg9);
+
+ if (H_IS_LONG_BUSY(ret)) {
+ sleep_msecs = get_longbusy_msecs(ret);
+ msleep_interruptible(sleep_msecs);
+ continue;
+ }
+
+ if (ret < H_SUCCESS)
+ ehea_error("opcode=%lx ret=%lx"
+ " arg1=%lx arg2=%lx arg3=%lx arg4=%lx"
+ " arg5=%lx arg6=%lx arg7=%lx arg8=%lx"
+ " arg9=%lx"
+ " out1=%lx out2=%lx out3=%lx out4=%lx"
+ " out5=%lx out6=%lx out7=%lx out8=%lx"
+ " out9=%lx",
+ opcode, ret,
+ arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, arg9,
+ outs[0], outs[1], outs[2], outs[3],
+ outs[4], outs[5], outs[6], outs[7],
+ outs[8]);
+
+ return ret;
}
- return ehea_hcall_9arg_9ret(H_QUERY_HEA_QP,
- adapter_handle, /* R4 */
- qp_category, /* R5 */
- qp_handle, /* R6 */
- sel_mask, /* R7 */
- virt_to_abs(cb_addr), /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return H_BUSY;
+}
+
+u64 ehea_h_query_ehea_qp(const u64 adapter_handle, const u8 qp_category,
+ const u64 qp_handle, const u64 sel_mask, void *cb_addr)
+{
+ return ehea_plpar_hcall_norets(H_QUERY_HEA_QP,
+ adapter_handle, /* R4 */
+ qp_category, /* R5 */
+ qp_handle, /* R6 */
+ sel_mask, /* R7 */
+ virt_to_abs(cb_addr), /* R8 */
+ 0, 0);
}
/* input param R5 */
@@ -180,6 +208,7 @@ u64 ehea_h_alloc_resource_qp(const u64 a
u64 *qp_handle, struct h_epas *h_epas)
{
u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
u64 allocate_controls =
EHEA_BMASK_SET(H_ALL_RES_QP_EQPO, init_attr->low_lat_rq1 ? 1 : 0)
@@ -219,45 +248,29 @@ u64 ehea_h_alloc_resource_qp(const u64 a
EHEA_BMASK_SET(H_ALL_RES_QP_TH_RQ2, init_attr->rq2_threshold)
| EHEA_BMASK_SET(H_ALL_RES_QP_TH_RQ3, init_attr->rq3_threshold);
- u64 r5_out = 0;
- u64 r6_out = 0;
- u64 r7_out = 0;
- u64 r8_out = 0;
- u64 r9_out = 0;
- u64 g_la_user_out = 0;
- u64 r11_out = 0;
- u64 r12_out = 0;
-
- hret = ehea_hcall_9arg_9ret(H_ALLOC_HEA_RESOURCE,
- adapter_handle, /* R4 */
- allocate_controls, /* R5 */
- init_attr->send_cq_handle, /* R6 */
- init_attr->recv_cq_handle, /* R7 */
- init_attr->aff_eq_handle, /* R8 */
- r9_reg, /* R9 */
- max_r10_reg, /* R10 */
- r11_in, /* R11 */
- threshold, /* R12 */
- qp_handle, /* R4 */
- &r5_out, /* R5 */
- &r6_out, /* R6 */
- &r7_out, /* R7 */
- &r8_out, /* R8 */
- &r9_out, /* R9 */
- &g_la_user_out, /* R10 */
- &r11_out, /* R11 */
- &r12_out); /* R12 */
+ hret = ehea_plpar_hcall9(H_ALLOC_HEA_RESOURCE,
+ outs,
+ adapter_handle, /* R4 */
+ allocate_controls, /* R5 */
+ init_attr->send_cq_handle, /* R6 */
+ init_attr->recv_cq_handle, /* R7 */
+ init_attr->aff_eq_handle, /* R8 */
+ r9_reg, /* R9 */
+ max_r10_reg, /* R10 */
+ r11_in, /* R11 */
+ threshold); /* R12 */
- init_attr->qp_nr = (u32)r5_out;
+ *qp_handle = outs[0];
+ init_attr->qp_nr = (u32)outs[1];
init_attr->act_nr_send_wqes =
- (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_SWQE, r6_out);
+ (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_SWQE, outs[2]);
init_attr->act_nr_rwqes_rq1 =
- (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R1WQE, r6_out);
+ (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R1WQE, outs[2]);
init_attr->act_nr_rwqes_rq2 =
- (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R2WQE, r6_out);
+ (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R2WQE, outs[2]);
init_attr->act_nr_rwqes_rq3 =
- (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R3WQE, r6_out);
+ (u16)EHEA_BMASK_GET(H_ALL_RES_QP_ACT_R3WQE, outs[2]);
init_attr->act_wqe_size_enc_sq = init_attr->wqe_size_enc_sq;
init_attr->act_wqe_size_enc_rq1 = init_attr->wqe_size_enc_rq1;
@@ -265,25 +278,25 @@ u64 ehea_h_alloc_resource_qp(const u64 a
init_attr->act_wqe_size_enc_rq3 = init_attr->wqe_size_enc_rq3;
init_attr->nr_sq_pages =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_SQ, r8_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_SQ, outs[4]);
init_attr->nr_rq1_pages =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ1, r8_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ1, outs[4]);
init_attr->nr_rq2_pages =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ2, r9_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ2, outs[5]);
init_attr->nr_rq3_pages =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ3, r9_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_SIZE_RQ3, outs[5]);
init_attr->liobn_sq =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_SQ, r11_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_SQ, outs[7]);
init_attr->liobn_rq1 =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ1, r11_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ1, outs[7]);
init_attr->liobn_rq2 =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ2, r12_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ2, outs[8]);
init_attr->liobn_rq3 =
- (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ3, r12_out);
+ (u32)EHEA_BMASK_GET(H_ALL_RES_QP_LIOBN_RQ3, outs[8]);
if (!hret)
- hcp_epas_ctor(h_epas, g_la_user_out, g_la_user_out);
+ hcp_epas_ctor(h_epas, outs[6], outs[6]);
return hret;
}
@@ -292,31 +305,24 @@ u64 ehea_h_alloc_resource_cq(const u64 a
struct ehea_cq_attr *cq_attr,
u64 *cq_handle, struct h_epas *epas)
{
- u64 hret, dummy, act_nr_of_cqes_out, act_pages_out;
- u64 g_la_privileged_out, g_la_user_out;
-
- hret = ehea_hcall_9arg_9ret(H_ALLOC_HEA_RESOURCE,
- adapter_handle, /* R4 */
- H_ALL_RES_TYPE_CQ, /* R5 */
- cq_attr->eq_handle, /* R6 */
- cq_attr->cq_token, /* R7 */
- cq_attr->max_nr_of_cqes, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- cq_handle, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &act_nr_of_cqes_out, /* R7 */
- &act_pages_out, /* R8 */
- &g_la_privileged_out, /* R9 */
- &g_la_user_out, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
- cq_attr->act_nr_of_cqes = act_nr_of_cqes_out;
- cq_attr->nr_pages = act_pages_out;
+ hret = ehea_plpar_hcall9(H_ALLOC_HEA_RESOURCE,
+ outs,
+ adapter_handle, /* R4 */
+ H_ALL_RES_TYPE_CQ, /* R5 */
+ cq_attr->eq_handle, /* R6 */
+ cq_attr->cq_token, /* R7 */
+ cq_attr->max_nr_of_cqes, /* R8 */
+ 0, 0, 0, 0); /* R9-R12 */
+
+ *cq_handle = outs[0];
+ cq_attr->act_nr_of_cqes = outs[3];
+ cq_attr->nr_pages = outs[4];
if (!hret)
- hcp_epas_ctor(epas, g_la_privileged_out, g_la_user_out);
+ hcp_epas_ctor(epas, outs[5], outs[6]);
return hret;
}
@@ -361,9 +367,8 @@ u64 ehea_h_alloc_resource_cq(const u64 a
u64 ehea_h_alloc_resource_eq(const u64 adapter_handle,
struct ehea_eq_attr *eq_attr, u64 *eq_handle)
{
- u64 hret, dummy, eq_liobn, allocate_controls;
- u64 ist1_out, ist2_out, ist3_out, ist4_out;
- u64 act_nr_of_eqes_out, act_pages_out;
+ u64 hret, allocate_controls;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
/* resource type */
allocate_controls =
@@ -372,27 +377,20 @@ u64 ehea_h_alloc_resource_eq(const u64 a
| EHEA_BMASK_SET(H_ALL_RES_EQ_INH_EQE_GEN, !eq_attr->eqe_gen)
| EHEA_BMASK_SET(H_ALL_RES_EQ_NON_NEQ_ISN, 1);
- hret = ehea_hcall_9arg_9ret(H_ALLOC_HEA_RESOURCE,
- adapter_handle, /* R4 */
- allocate_controls, /* R5 */
- eq_attr->max_nr_of_eqes, /* R6 */
- 0, 0, 0, 0, 0, 0, /* R7-R10 */
- eq_handle, /* R4 */
- &dummy, /* R5 */
- &eq_liobn, /* R6 */
- &act_nr_of_eqes_out, /* R7 */
- &act_pages_out, /* R8 */
- &ist1_out, /* R9 */
- &ist2_out, /* R10 */
- &ist3_out, /* R11 */
- &ist4_out); /* R12 */
-
- eq_attr->act_nr_of_eqes = act_nr_of_eqes_out;
- eq_attr->nr_pages = act_pages_out;
- eq_attr->ist1 = ist1_out;
- eq_attr->ist2 = ist2_out;
- eq_attr->ist3 = ist3_out;
- eq_attr->ist4 = ist4_out;
+ hret = ehea_plpar_hcall9(H_ALLOC_HEA_RESOURCE,
+ outs,
+ adapter_handle, /* R4 */
+ allocate_controls, /* R5 */
+ eq_attr->max_nr_of_eqes, /* R6 */
+ 0, 0, 0, 0, 0, 0); /* R7-R10 */
+
+ *eq_handle = outs[0];
+ eq_attr->act_nr_of_eqes = outs[3];
+ eq_attr->nr_pages = outs[4];
+ eq_attr->ist1 = outs[5];
+ eq_attr->ist2 = outs[6];
+ eq_attr->ist3 = outs[7];
+ eq_attr->ist4 = outs[8];
return hret;
}
@@ -402,31 +400,22 @@ u64 ehea_h_modify_ehea_qp(const u64 adap
void *cb_addr, u64 *inv_attr_id, u64 *proc_mask,
u16 *out_swr, u16 *out_rwr)
{
- u64 hret, dummy, act_out_swr, act_out_rwr;
-
- if ((((u64)cb_addr) & (PAGE_SIZE - 1)) != 0) {
- ehea_error("not on page boundary");
- return H_PARAMETER;
- }
+ u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
- hret = ehea_hcall_9arg_9ret(H_MODIFY_HEA_QP,
- adapter_handle, /* R4 */
- (u64) cat, /* R5 */
- qp_handle, /* R6 */
- sel_mask, /* R7 */
- virt_to_abs(cb_addr), /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- inv_attr_id, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &act_out_swr, /* R7 */
- &act_out_rwr, /* R8 */
- proc_mask, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
- *out_swr = act_out_swr;
- *out_rwr = act_out_rwr;
+ hret = ehea_plpar_hcall9(H_MODIFY_HEA_QP,
+ outs,
+ adapter_handle, /* R4 */
+ (u64) cat, /* R5 */
+ qp_handle, /* R6 */
+ sel_mask, /* R7 */
+ virt_to_abs(cb_addr), /* R8 */
+ 0, 0, 0, 0); /* R9-R12 */
+
+ *inv_attr_id = outs[0];
+ *out_swr = outs[3];
+ *out_rwr = outs[4];
+ *proc_mask = outs[5];
return hret;
}
@@ -435,122 +424,81 @@ u64 ehea_h_register_rpage(const u64 adap
const u8 queue_type, const u64 resource_handle,
const u64 log_pageaddr, u64 count)
{
- u64 dummy, reg_control;
+ u64 reg_control;
reg_control = EHEA_BMASK_SET(H_REG_RPAGE_PAGE_SIZE, pagesize)
| EHEA_BMASK_SET(H_REG_RPAGE_QT, queue_type);
- return ehea_hcall_9arg_9ret(H_REGISTER_HEA_RPAGES,
- adapter_handle, /* R4 */
- reg_control, /* R5 */
- resource_handle, /* R6 */
- log_pageaddr, /* R7 */
- count, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall_norets(H_REGISTER_HEA_RPAGES,
+ adapter_handle, /* R4 */
+ reg_control, /* R5 */
+ resource_handle, /* R6 */
+ log_pageaddr, /* R7 */
+ count, /* R8 */
+ 0, 0); /* R9-R10 */
}
u64 ehea_h_register_smr(const u64 adapter_handle, const u64 orig_mr_handle,
const u64 vaddr_in, const u32 access_ctrl, const u32 pd,
struct ehea_mr *mr)
{
- u64 hret, dummy, lkey_out;
+ u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
+
+ hret = ehea_plpar_hcall9(H_REGISTER_SMR,
+ outs,
+ adapter_handle , /* R4 */
+ orig_mr_handle, /* R5 */
+ vaddr_in, /* R6 */
+ (((u64)access_ctrl) << 32ULL), /* R7 */
+ pd, /* R8 */
+ 0, 0, 0, 0); /* R9-R12 */
- hret = ehea_hcall_9arg_9ret(H_REGISTER_SMR,
- adapter_handle , /* R4 */
- orig_mr_handle, /* R5 */
- vaddr_in, /* R6 */
- (((u64)access_ctrl) << 32ULL), /* R7 */
- pd, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &mr->handle, /* R4 */
- &dummy, /* R5 */
- &lkey_out, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
- mr->lkey = (u32)lkey_out;
+ mr->handle = outs[0];
+ mr->lkey = (u32)outs[2];
return hret;
}
u64 ehea_h_disable_and_get_hea(const u64 adapter_handle, const u64 qp_handle)
{
- u64 hret, dummy, ladr_next_sq_wqe_out;
- u64 ladr_next_rq1_wqe_out, ladr_next_rq2_wqe_out, ladr_next_rq3_wqe_out;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
- hret = ehea_hcall_9arg_9ret(H_DISABLE_AND_GET_HEA,
- adapter_handle, /* R4 */
- H_DISABLE_GET_EHEA_WQE_P, /* R5 */
- qp_handle, /* R6 */
- 0, 0, 0, 0, 0, 0, /* R7-R12 */
- &ladr_next_sq_wqe_out, /* R4 */
- &ladr_next_rq1_wqe_out, /* R5 */
- &ladr_next_rq2_wqe_out, /* R6 */
- &ladr_next_rq3_wqe_out, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
- return hret;
+ return ehea_plpar_hcall9(H_DISABLE_AND_GET_HEA,
+ outs,
+ adapter_handle, /* R4 */
+ H_DISABLE_GET_EHEA_WQE_P, /* R5 */
+ qp_handle, /* R6 */
+ 0, 0, 0, 0, 0, 0); /* R7-R12 */
}
u64 ehea_h_free_resource(const u64 adapter_handle, const u64 res_handle)
{
- u64 dummy;
-
- return ehea_hcall_9arg_9ret(H_FREE_RESOURCE,
- adapter_handle, /* R4 */
- res_handle, /* R5 */
- 0, 0, 0, 0, 0, 0, 0, /* R6-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall_norets(H_FREE_RESOURCE,
+ adapter_handle, /* R4 */
+ res_handle, /* R5 */
+ 0, 0, 0, 0, 0); /* R6-R10 */
}
u64 ehea_h_alloc_resource_mr(const u64 adapter_handle, const u64 vaddr,
const u64 length, const u32 access_ctrl,
const u32 pd, u64 *mr_handle, u32 *lkey)
{
- u64 hret, dummy, lkey_out;
+ u64 hret;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
- hret = ehea_hcall_9arg_9ret(H_ALLOC_HEA_RESOURCE,
- adapter_handle, /* R4 */
- 5, /* R5 */
- vaddr, /* R6 */
- length, /* R7 */
- (((u64) access_ctrl) << 32ULL),/* R8 */
- pd, /* R9 */
- 0, 0, 0, /* R10-R12 */
- mr_handle, /* R4 */
- &dummy, /* R5 */
- &lkey_out, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
- *lkey = (u32) lkey_out;
+ hret = ehea_plpar_hcall9(H_ALLOC_HEA_RESOURCE,
+ outs,
+ adapter_handle, /* R4 */
+ 5, /* R5 */
+ vaddr, /* R6 */
+ length, /* R7 */
+ (((u64) access_ctrl) << 32ULL), /* R8 */
+ pd, /* R9 */
+ 0, 0, 0); /* R10-R12 */
+ *mr_handle = outs[0];
+ *lkey = (u32)outs[2];
return hret;
}
@@ -570,23 +518,14 @@ u64 ehea_h_register_rpage_mr(const u64 a
u64 ehea_h_query_ehea(const u64 adapter_handle, void *cb_addr)
{
- u64 hret, dummy, cb_logaddr;
+ u64 hret, cb_logaddr;
cb_logaddr = virt_to_abs(cb_addr);
- hret = ehea_hcall_9arg_9ret(H_QUERY_HEA,
- adapter_handle, /* R4 */
- cb_logaddr, /* R5 */
- 0, 0, 0, 0, 0, 0, 0, /* R6-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ hret = ehea_plpar_hcall_norets(H_QUERY_HEA,
+ adapter_handle, /* R4 */
+ cb_logaddr, /* R5 */
+ 0, 0, 0, 0, 0); /* R6-R10 */
#ifdef DEBUG
ehea_dmp(cb_addr, sizeof(struct hcp_query_ehea), "hcp_query_ehea");
#endif
@@ -597,36 +536,28 @@ u64 ehea_h_query_ehea_port(const u64 ada
const u8 cb_cat, const u64 select_mask,
void *cb_addr)
{
- u64 port_info, dummy;
+ u64 port_info;
u64 cb_logaddr = virt_to_abs(cb_addr);
u64 arr_index = 0;
port_info = EHEA_BMASK_SET(H_MEHEAPORT_CAT, cb_cat)
| EHEA_BMASK_SET(H_MEHEAPORT_PN, port_num);
- return ehea_hcall_9arg_9ret(H_QUERY_HEA_PORT,
- adapter_handle, /* R4 */
- port_info, /* R5 */
- select_mask, /* R6 */
- arr_index, /* R7 */
- cb_logaddr, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall_norets(H_QUERY_HEA_PORT,
+ adapter_handle, /* R4 */
+ port_info, /* R5 */
+ select_mask, /* R6 */
+ arr_index, /* R7 */
+ cb_logaddr, /* R8 */
+ 0, 0); /* R9-R10 */
}
u64 ehea_h_modify_ehea_port(const u64 adapter_handle, const u16 port_num,
const u8 cb_cat, const u64 select_mask,
void *cb_addr)
{
- u64 port_info, dummy, inv_attr_ident, proc_mask;
+ u64 outs[PLPAR_HCALL9_BUFSIZE];
+ u64 port_info;
u64 arr_index = 0;
u64 cb_logaddr = virt_to_abs(cb_addr);
@@ -635,29 +566,21 @@ u64 ehea_h_modify_ehea_port(const u64 ad
#ifdef DEBUG
ehea_dump(cb_addr, sizeof(struct hcp_ehea_port_cb0), "Before HCALL");
#endif
- return ehea_hcall_9arg_9ret(H_MODIFY_HEA_PORT,
- adapter_handle, /* R4 */
- port_info, /* R5 */
- select_mask, /* R6 */
- arr_index, /* R7 */
- cb_logaddr, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &inv_attr_ident, /* R4 */
- &proc_mask, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall9(H_MODIFY_HEA_PORT,
+ outs,
+ adapter_handle, /* R4 */
+ port_info, /* R5 */
+ select_mask, /* R6 */
+ arr_index, /* R7 */
+ cb_logaddr, /* R8 */
+ 0, 0, 0, 0); /* R9-R12 */
}
u64 ehea_h_reg_dereg_bcmc(const u64 adapter_handle, const u16 port_num,
const u8 reg_type, const u64 mc_mac_addr,
const u16 vlan_id, const u32 hcall_id)
{
- u64 r5_port_num, r6_reg_type, r7_mc_mac_addr, r8_vlan_id, dummy;
+ u64 r5_port_num, r6_reg_type, r7_mc_mac_addr, r8_vlan_id;
u64 mac_addr = mc_mac_addr >> 16;
r5_port_num = EHEA_BMASK_SET(H_REGBCMC_PN, port_num);
@@ -665,41 +588,21 @@ u64 ehea_h_reg_dereg_bcmc(const u64 adap
r7_mc_mac_addr = EHEA_BMASK_SET(H_REGBCMC_MACADDR, mac_addr);
r8_vlan_id = EHEA_BMASK_SET(H_REGBCMC_VLANID, vlan_id);
- return ehea_hcall_9arg_9ret(hcall_id,
- adapter_handle, /* R4 */
- r5_port_num, /* R5 */
- r6_reg_type, /* R6 */
- r7_mc_mac_addr, /* R7 */
- r8_vlan_id, /* R8 */
- 0, 0, 0, 0, /* R9-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall_norets(hcall_id,
+ adapter_handle, /* R4 */
+ r5_port_num, /* R5 */
+ r6_reg_type, /* R6 */
+ r7_mc_mac_addr, /* R7 */
+ r8_vlan_id, /* R8 */
+ 0, 0); /* R9-R12 */
}
u64 ehea_h_reset_events(const u64 adapter_handle, const u64 neq_handle,
const u64 event_mask)
{
- u64 dummy;
-
- return ehea_hcall_9arg_9ret(H_RESET_EVENTS,
- adapter_handle, /* R4 */
- neq_handle, /* R5 */
- event_mask, /* R6 */
- 0, 0, 0, 0, 0, 0, /* R7-R12 */
- &dummy, /* R4 */
- &dummy, /* R5 */
- &dummy, /* R6 */
- &dummy, /* R7 */
- &dummy, /* R8 */
- &dummy, /* R9 */
- &dummy, /* R10 */
- &dummy, /* R11 */
- &dummy); /* R12 */
+ return ehea_plpar_hcall_norets(H_RESET_EVENTS,
+ adapter_handle, /* R4 */
+ neq_handle, /* R5 */
+ event_mask, /* R6 */
+ 0, 0, 0, 0); /* R7-R12 */
}
^ permalink raw reply
* Re: ML403 patch for UBOOT
From: Frank D Lombardo @ 2006-09-25 16:11 UTC (permalink / raw)
To: christophe.alayrac; +Cc: Linuxppc-embedded
In-Reply-To: <1159189359.4848.6.camel@Serge-Linux>
alayrac wrote:
> Le lundi 25 septembre 2006 à 12:34 +0000, Ming Liu a écrit :
>
>> Hi,
>> Here it is...
>>
>> http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/023912.html
>>
>> Regards
>> Ming
>>
>>
> Thank you Ming for your prompt reply. It is exactly the pacth I've found
> previously.
> The pacth start with the following lines :
> diff -Naur linux-2.6.17-4.patch1/arch/ppc/platforms/4xx/xilinx_ml300.h
> linux-2.6.17-4.working/arch/ppc/platforms/4xx/xilinx_ml300.h
> --- linux-2.6.17-4.patch1/arch/ppc/platforms/4xx/xilinx_ml300.h 2006-07-25 16:42:50.000000000 -0400
> +++ linux-2.6.17-4.working/arch/ppc/platforms/4xx/xilinx_ml300.h 2006-08-02 19:47:00.000000000 -0400
>
> I understand from that that it try to change linux-2.6.17-4 xilinx_ml300.h
> If I type from u-boot (1.1.4) source code directory
> patch -i U-BOOT
> with U-BOOT the text file containing that pacth then it stop askink for file path.
>
> So I wonder if the pacth is for UBOOT or Linux 2.6.17-4 kernel source?
>
> I should precise that I'm a beginner with Uboot and linux 2.6 (already port linux 2.4 on ML403 using BYU instructions)
> I must miss something basic...
>
> Thanks for your help
>
> Chris
>
Chris,
You are correct, that patch is for the Linux kernel and should be
applied to the kernel if you are planning on using u-boot. It ensures
that the board_info structure in the kernel matches the one used by u-boot.
Xilinx has a u-boot tree that works with the ML403 board. It is
available here:
http://www.xilinx.com/ml410-p/designs/u-boot.zip
Good luck,
Frank
^ permalink raw reply
* Re: ML403 patch for UBOOT
From: Peter Ryser @ 2006-09-25 16:19 UTC (permalink / raw)
To: Linuxppc-embedded
In-Reply-To: <1159183304.11649.17.camel@Serge-Linux>
You might want to start with XAPP542
http://direct.xilinx.com/bvdocs/appnotes/xapp542.pdf
http://direct.xilinx.com/bvdocs/appnotes/xapp542.zip
The zip file includes the U-Boot patch for Linux kernel 2.4.
- Peter
alayrac wrote:
>I'm new member of this mailing list an I'm looking for some information
>on UBOOT on ML403.
>
>stevea-mdi talk about a pacth from Ameet
>(http://www.linux2knowmore.com) but I did not succeed to find this
>pacth.
>The one attached to the mail
>(http://patchwork.ozlabs.org/linuxppc/patch?id=6502) seems to be for
>linux 2.6.17-4 and not for UBOOT.
>
>Is there something I'm doing wrong?
>
>Where can I found a pacth for UBOOT for ML403?
>
>Thank you in advance for any help
>
>Chris
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
^ permalink raw reply
* Re: Unable to boot linux on Xilinx ML403 board
From: Peter Ryser @ 2006-09-25 16:16 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <smtp_4517D0DE_85A0_0002.eml@>
>avail ram: 00770000 08000000
>
>
The ML403 only has 64 MB of RAM, ie. 0x04000000. For a start you can
change the amount of memory Linux thinks it has available by adding
mem=0x4000000
to the kernel command line like
Linux/PPC load: console=tty1 console=ttyS0,9600 ip=off root=/dev/ram
rw mem=0x4000000
Later, you want to change xparameters*.h in arch/ppc/platforms/xilinx_ocp
- Peter
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Matthew McClintock @ 2006-09-25 16:49 UTC (permalink / raw)
To: Fredrik Roubert; +Cc: linuxppc-embedded
In-Reply-To: <20060921160808.GB4828@igloo.df.lth.se>
On Thu, 2006-09-21 at 18:08 +0200, Fredrik Roubert wrote:
> chosen {
> name = "chosen";
> linux,platform = <00000600>;
> linux,stdout-path = "/soc8349@ff400000/serial@4500";
> bootargs = "root=/dev/nfs rw
> nfsroot=150.158.215.227:/home/rootfs/dev-ds
> ip=150.158.211.83:150.158.215.227:150.158.212.1:255.255.248.0:dev-ds:eth0:off console=ttyS0,115200 console=ttyS0,115200 rtc-x1205.force=0,0x6f";
> };
>
Fredrik,
It looks like you already have your chosen node in your DTS file. With
my u-boot patches the appropriate chosen node is added to the flat tree
based off the u-boot environment.
-Matthew
^ permalink raw reply
* RE: How to move from /ppc/ to /powerpc/
From: Joakim Tjernlund @ 2006-09-25 16:56 UTC (permalink / raw)
To: Fredrik Roubert, linuxppc-embedded
> I tried compiling it like this:
>=20
> $ dtc -f -I dts -O dtb mpc8349emds.dts > devices.dtb
> DTC: dts->dtb on file "mpc8349emds.dts"
> Warning: No cpu has "linux,boot-cpu" property
> ERROR: Missing /chosen node
> Input tree has errors
You need to add -V 0x10 to dtc as well.
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Fredrik Roubert @ 2006-09-25 17:17 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-embedded
In-Reply-To: <1159202991.5485.0.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
On Mon 25 Sep 18:49 CEST 2006, Matthew McClintock wrote:
> It looks like you already have your chosen node in your DTS file. With
> my u-boot patches the appropriate chosen node is added to the flat tree
> based off the u-boot environment.
Ah, that's true, in ft_setup(), I didn't see that. Thanks! (I'd been
thinking about how the command line should be passed from U-Boot, but
decided to postpone that investigation until I solved the serial console
problem.)
However, the code in ft_setup() doesn't assign "linux,stdout-path", so
if I remove the chosen node from my DTS, then I get no print-out on the
serial console at all. (But the rest of the system appears to run fine
and I can log in using SSH.) Can this be a clue to someone as to what
could be the problem with my serial console?
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
[-- Attachment #2: Type: application/pgp-signature, Size: 303 bytes --]
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Matthew McClintock @ 2006-09-25 17:20 UTC (permalink / raw)
To: Fredrik Roubert; +Cc: linuxppc-embedded
In-Reply-To: <20060925171754.GB21204@igloo.df.lth.se>
On Mon, 2006-09-25 at 19:17 +0200, Fredrik Roubert wrote:
> On Mon 25 Sep 18:49 CEST 2006, Matthew McClintock wrote:
>
> > It looks like you already have your chosen node in your DTS file. With
> > my u-boot patches the appropriate chosen node is added to the flat tree
> > based off the u-boot environment.
>
> Ah, that's true, in ft_setup(), I didn't see that. Thanks! (I'd been
> thinking about how the command line should be passed from U-Boot, but
> decided to postpone that investigation until I solved the serial console
> problem.)
>
> However, the code in ft_setup() doesn't assign "linux,stdout-path", so
> if I remove the chosen node from my DTS, then I get no print-out on the
> serial console at all. (But the rest of the system appears to run fine
> and I can log in using SSH.) Can this be a clue to someone as to what
> could be the problem with my serial console?
>
>From u-boot/common/ft_build.c:
#ifdef OF_STDOUT_PATH
ft_prop_str(&cxt, "linux,stdout-path", OF_STDOUT_PATH);
#endif
There is a define for adding that to the /chosen node. Add this to your
u-boot include file and the console should show up.
Good Luck.
-Matthew
^ permalink raw reply
* RE: ML403 patch for UBOOT
From: Ming Liu @ 2006-09-25 17:36 UTC (permalink / raw)
To: christophe.alayrac; +Cc: Linuxppc-embedded
In-Reply-To: <1159189359.4848.6.camel@Serge-Linux>
Hi,
>So I wonder if the pacth is for UBOOT or Linux 2.6.17-4 kernel source?
>From the structure of the directory, you can see that obviously it is for
the linux kernel.
>I should precise that I'm a beginner with Uboot and linux 2.6 (already
port linux 2.4 on ML403 using BYU instructions)
>I must miss something basic...
No problem. I am also a beginner. :)
Regards
Ming
_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Fredrik Roubert @ 2006-09-25 17:41 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-embedded
In-Reply-To: <1159204851.5485.6.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 680 bytes --]
On Mon 25 Sep 19:20 CEST 2006, Matthew McClintock wrote:
> #ifdef OF_STDOUT_PATH
> ft_prop_str(&cxt, "linux,stdout-path", OF_STDOUT_PATH);
> #endif
Great! I had missed those lines (while manually applying your patches to
my own modified U-Boot 1.1.4 sources) ...
Now I'm back to the state of last Thursday (except for getting rid of
the unnecessary chosen node and getting bootargs passed nicely), which
means that the serial console initially works, but stops working after
the call to console_init() in start_kernel().
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
[-- Attachment #2: Type: application/pgp-signature, Size: 303 bytes --]
^ permalink raw reply
* Re: linux-2.6 system ACE driver - need help
From: agnel juni @ 2006-09-25 18:47 UTC (permalink / raw)
To: Ameet Patil; +Cc: linuxppc-embedded
In-Reply-To: <45179FF7.3000400@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7621 bytes --]
Hi Ameet,
Thanks so much for your reply.
ISSUE Details :
We are currently debugging System driver in 2.6.16-2 kernel in interrupt mode, for AMCC440SPe based custom board.
We got the kernel and applied patch for Xilinx System ACE driver.
We are using powerpc-eabi- toolachain to compile the kernel and NOT EDK.
We have done changes in the driver in regard to –
System ACE Controller register configuration - BASE address is 64-bit and hence done ioremap64(SYSTEMACE_BASEADRESS).- adapter.c
Endianess (Xsysace_l.c)
IRQ - xsysace_intr.c; arch/ppc/platforms/4xx/xparameters/xparameters_ml300.h ; arch/ppc/syslib/ppc4xx_pic.c;
Kernel configuration to support FAT file system
Format the Compact Flash with FAT16 filesystem using ‘mkdosfs’, since System ACE supports only FAT16
With all these changes, we are able to communicate with the system ACE controller, register the interrupt, create block device using the driver, format and partition the Compact Flash.
But we see issues while mounting the compact flash – Meaning, mounting shows inconsistent results.
When we are able to mount the CF successfully, we are able to read/write to the compact flash. And when it fails, it throws a kernel Oops sometimes or complains that it’s a ‘bogus’ filesystem. Please see the screen-dump for success and failure cases:
We are looking for inputs to attack this issue. Please advice.
Note : we have worked on System ACE driver on 2.4 kernel on a different platform and were successful.
Thanks very much
Junita
SCREEN DUMP:
CASE 1 : Success:
BusyBox v(null) ((null)) Built-in shell (msh)
Enter 'help' for a list of built-in commands.
# ### Application running ...
#
# cat /proc/interrupts
CPU0
33: 0 UIC1 Level MAL SERR
34: 0 UIC1 Level MAL TX DE
35: 0 UIC1 Level MAL RX DE
38: 0 UIC1 Level MAL TX EOB
39: 0 UIC1 Level MAL RX EOB
89: 0 UIC2 Level System ACE
BAD: 0
# mknod /dev/xsysace b 254 0
# mkdir /mnt
# mkdir /mnt/sysace
# mount -t msdos /dev/xsysace /mnt/sysace/
# ls
bin etc home linuxrc proc sbin usr
dev ftp lib mnt root tmp var
# ls /mnt/sysace/
rev0.ace
# cp /sbin/ifconfig /mnt/sysace/
# ls /mnt/sysace/
ifconfig rev0.ace
#
CASE : 2 – Failure – Kernel Oops.
# mount -t msdos /dev/xsysace /root/cf # cd /root/
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: C00556B8 LR: C00557E4 CTR: 00000000
> REGS: dfeb1e08 TRAP: 0300 Not tainted (2.6.16.2)
> MSR: 00021000 <ME> CR: 227A8728 XER: 00000000
> DAR: 00000000, DSISR: 00800000
> TASK = dff6c030[4] 'events/0' THREAD: dfeb0000
> GPR00: 00100100 DFEB1EB8 DFF6C030 C025AC60 DFF7BE10 00000018
DFD96000
> C0258D60
> GPR08: 00000000 00200200 DFD96154 00000000 227A8788 800823E2
1FFB9600
> 00000000
> GPR16: 00000001 FFFFFFFF 00000000 007FFF00 1FFB3540 1FF63920
1FFCEE78
> C01F0000
> GPR24: C0240000 00100100 C0240000 00000000 DFF7BE10 00000018
00000000
> C025AC60
> NIP [C00556B8] free_block+0xa8/0x148 LR [C00557E4]
> drain_array_locked+0x8c/0xd8 Call Trace:
> [DFEB1EB8] [DFED53F0] 0xdfed53f0 (unreliable) [DFEB1ED8] [C00557E4]
> drain_array_locked+0x8c/0xd8 [DFEB1EF0] [C0056F80]
> cache_reap+0x74/0x18c [DFEB1F28] [C002B578] run_workqueue+0x9c/0x110
> [DFEB1F48] [C002B6E4] worker_thread+0xf8/0x13c [DFEB1FC0] [C002F6F0]
> kthread+0xf4/0x130 [DFEB1FF0] [C000413C] kernel_thread+0x44/0x60
> Instruction dump:
> 7cfbfa14 3c000010 80e70014 3d2a4000 60000100 5529c9f4 7d295a14
80c9001c
> 3d200020 61290200 81060004 81660000 <91680000> 910b0004 3966001c
90060000
> BUG: events/0/4, lock held at task exit time!
> [c01f5d60] {cache_chain_mutex}
> .. held by: events/0: 4 [dff6c030, 110]
> ... acquired at: cache_reap+0x1c/0x18c
>
Ameet Patil <ammubhai@gmail.com> wrote:
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
>
> Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8.
> Get it NOW
>
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
---------------------------------
Find out what India is talking about on - Yahoo! Answers India
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW
[-- Attachment #2: Type: text/html, Size: 29299 bytes --]
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Matthew McClintock @ 2006-09-25 18:59 UTC (permalink / raw)
To: Fredrik Roubert; +Cc: linuxppc-embedded
In-Reply-To: <20060925174101.GC21204@igloo.df.lth.se>
On Mon, 2006-09-25 at 19:41 +0200, Fredrik Roubert wrote:
> Now I'm back to the state of last Thursday (except for getting rid of
> the unnecessary chosen node and getting bootargs passed nicely), which
> means that the serial console initially works, but stops working after
> the call to console_init() in start_kernel().
Do you have all the other OF related defines in your u-boot config
file?
#define OF_CPU "PowerPC,8540@0"
#define OF_SOC "soc8540@e0000000"
#define OF_TBCLK (bd->bi_busfreq / 8)
#define OF_STDOUT_PATH "/soc8540@e0000000/serial@4500"
Maybe you are not properly setting up entries in the flat device tree
passed to the kernel. So when the kernel takes over and re-initializes
the serial port the speed is all messed up.
Can you verify the flat device tree passed to the kernel is correct?
Specifically these properties:
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
-Matthew
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Mark A. Greer @ 2006-09-25 17:53 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Paul Mackerras, Matt Porter, linuxppc-dev
In-Reply-To: <D47FC822-2AB1-459A-B2EC-50A99552DC9A@kernel.crashing.org>
On Sat, Sep 23, 2006 at 12:15:19PM +0200, Segher Boessenkool wrote:
> >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.
Okay, fair enough. I think you understand what I was trying to say,
right? If so, do you have any objections to it?
> The situation is even worse with "package", let's not go there :-)
Heh. :)
Mark
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox