* Re: OLS 2005
From: Kumar Gala @ 2005-07-06 18:20 UTC (permalink / raw)
To: Grant Likely; +Cc: David Ho, linuxppc-embedded
In-Reply-To: <528646bc0507061049739157cf@mail.gmail.com>
We should try to see if we can find GregKH to discuss what changes
would need to be made to the driver core to allow this.
- kumar
On Jul 6, 2005, at 12:49 PM, Grant Likely wrote:
> On 4/27/05, Kumar Gala <kumar.gala@freescale.com> wrote:
>
>> I wondering if we can get a PPC BoF together, however not sure
>> exactly
>> what we would talk about. Any ideas?
>>
>> - kumar
>>
> I'd like to discuss the platform bus a bit. As was discussed a month
> or so ago, there is no clean way of matching multiple device drivers
> to a single device type, like with PSCs on the MPC5200.
>
> g.
>
> --
> "Why do musicians compose symphonies and poets write poems? They do it
> because life wouldn't have any meaning for them if they didn't.
> That's why I draw cartoons. It's my life."
>
> -- Charles Shultz
>
^ permalink raw reply
* Re: 2.6.12-rc2 netconsole problem
From: Wolfgang Denk @ 2005-07-06 20:09 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20050706163029.GC8358@smtp.west.cox.net>
In message <20050706163029.GC8358@smtp.west.cox.net> you wrote:
>
> That's quite cool. Any chance that could be ported back to Linux (I
> know netpoll supports it, kgdboe works in the kernel).
Chances yes, if somebody volunteers or pays for the effort. Sorry,
the old problem: too few hours per day.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The price one pays for pursuing any profession, or calling, is an
intimate knowledge of its ugly side. - James Baldwin
^ permalink raw reply
* Porting Linux On MPC8266 custom board
From: apoorv sangal @ 2005-07-07 4:18 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: vikrant_basotra, nishant_galange, apoorv sangal
Hi All,
=09=09I am porting Linux on MPC8266 custom board, after getting in to
Linux the system seems to be struck at a point.
Saved Environment variable:-
bootargs console=3DttyS0,11520 root=3D1f00 and downloaded the Kernel
image at address 0x02000000 in the RAM.
>From the u-boot prompt the bootm command is invoked as:-=20
=09bootm 0x02000000
After that what I get on the terminal is pasted below for your reference.
I couldn't make out any thing from the output, can any body tell me
where I am doing wrong, and also I don't have any idea about the
bootargs argument "root". Can any body give the precise description of
this argument?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
+
=3D> bootm 02000000 ## Booting image at 02000000...
Image Name: 2.4.24 MPC8260ADS
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 725838 Bytes =3D 708.8 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory BAT mapping: BAT2=3D128Mb, BAT3=3D0Mb, residual: 0Mb
Linux version 2.4.24-pre2 (root@pmcserver) (gcc version 3.3.4) #2 Tue
Jul 5 15:05:10 IST 2005
On node 0 totalpages: 32768
zone(0): 32768 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=3DttyS0,115200 root=3D1f00
Warning: real time clock seems stuck!
Calibrating delay loop... 131.89 BogoMIPS
Memory: 127812k available (1232k kernel code, 412k data, 64k init, 0k highm=
em)
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: 512 (order: 0, 4096 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
Starting kswapd
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications =
AB.
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
CPM UART driver version 0.01
ttyS0 on SMC1 at 0x0000, BRG7
ttyS1 on SMC2 at 0x0040, BRG8
ttyS2 on SCC1 at 0x8000, BRG1
ttyS3 on SCC2 at 0x8100, BRG2
pty: 256 Unix98 ptys configured
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
=09
Waiting eagerly,
Regards,
VB
^ permalink raw reply
* Re: OLS 2005
From: Grant Likely @ 2005-07-07 6:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Ho, linuxppc-embedded
In-Reply-To: <18C1CAA6-F980-4F8C-8FDD-E5D676D084ED@freescale.com>
On 7/6/05, Kumar Gala <kumar.gala@freescale.com> wrote:
> We should try to see if we can find GregKH to discuss what changes
> would need to be made to the driver core to allow this.
Good call. I fired an email off to the LKML, but I guess it wasn't
flashy enough to grab his attention. :-)
Cheers,
g.
^ permalink raw reply
* Re: Porting Linux On MPC8266 custom board
From: Alex Zeffertt @ 2005-07-07 9:12 UTC (permalink / raw)
To: apoorv sangal
Cc: vikrant_basotra, nishant_galange, apoorv_sangal,
linuxppc-embedded
In-Reply-To: <a796693605070621187c9394d5@mail.gmail.com>
Apoorv,
You need to look in two places:
1. linux/init/main.c
(which contains the following code
#endif
#ifdef CONFIG_MTD
{ "mtdblock", 0x1f00 },
#endif
{ NULL, 0 }
};
)
and
2. http://www.denx.de/twiki/bin/view/DULG/LinuxKernelArgs
It looks to me that you're trying to use an mtdblock device for your root
filesystem. For this to work you need CONFIG_MTD defined and - obviously - a
root file system image in the appropriate place in your flash.
It also appears that you are losing output shortly after the ttyS0 drivers are
created. Maybe the problem is that your serial console program (e.g. minicom)
is not configured for 11520 .. or for some reason the driver is selecting
another rate. Strangely, on my 82xx board I don't need the console argument on
the kernel command line, it just automatically uses ttyS0@9600. Probably this
is because it detects u-boot is also using this, but I don't know.
Alex
On Thu, 7 Jul 2005 09:48:53 +0530
apoorv sangal <apoorvsangal@gmail.com> wrote:
> Hi All,
> I am porting Linux on MPC8266 custom board, after getting in to
> Linux the system seems to be struck at a point.
> Saved Environment variable:-
> bootargs console=ttyS0,11520 root=1f00 and downloaded the Kernel
> image at address 0x02000000 in the RAM.
> From the u-boot prompt the bootm command is invoked as:-
> bootm 0x02000000
>
> After that what I get on the terminal is pasted below for your reference.
> I couldn't make out any thing from the output, can any body tell me
> where I am doing wrong, and also I don't have any idea about the
> bootargs argument "root". Can any body give the precise description of
> this argument?
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> => bootm 02000000 ## Booting image at 02000000...
> Image Name: 2.4.24 MPC8260ADS
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 725838 Bytes = 708.8 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Memory BAT mapping: BAT2=128Mb, BAT3=0Mb, residual: 0Mb
>
> Linux version 2.4.24-pre2 (root@pmcserver) (gcc version 3.3.4) #2 Tue
> Jul 5 15:05:10 IST 2005
>
> On node 0 totalpages: 32768
>
> zone(0): 32768 pages.
>
> zone(1): 0 pages.
>
> zone(2): 0 pages.
>
> Kernel command line: console=ttyS0,115200 root=1f00
>
> Warning: real time clock seems stuck!
>
> Calibrating delay loop... 131.89 BogoMIPS
>
> Memory: 127812k available (1232k kernel code, 412k data, 64k 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: 512 (order: 0, 4096 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
>
> Starting kswapd
>
> JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
>
> i2c-core.o: i2c core module version 2.6.1 (20010830)
>
> i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
>
> CPM UART driver version 0.01
>
> ttyS0 on SMC1 at 0x0000, BRG7
>
> ttyS1 on SMC2 at 0x0040, BRG8
>
> ttyS2 on SCC1 at 0x8000, BRG1
>
> ttyS3 on SCC2 at 0x8100, BRG2
>
> pty: 256 Unix98 ptys configured
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Waiting eagerly,
> Regards,
> VB
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* PPC440GX IBM EMAC2/3 RGMII mode selection
From: David Grab @ 2005-07-07 14:28 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
i have some problems to configure emac2, emac3 support of my ibm ppc440gx
for linux kernel 2.6.11.6. I have two RGMII Phy´s connected to the ppc an no
other PHY´s are connected. PPC Strapping is selected for Group4 (SMII, SMII,
RGMII/RTBI, RGMII/RTBI). I only want to configure the RGMII support of emac2
and emac3. But it seems like the PHY´s are used for eth0 (emac1) and eth1
(emac2) which are configured as SMII. Could someone tell me, what i have to
configure to select only emac2 and emac3 in RGMII mode?
Thx for help,
David
console output:
=> bootd
## Booting image at ff000000 ...
Image Name: Linux-2.6.11.6
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 890881 Bytes = 870 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x1FF9D898 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF25
bd address = 0x1FF9DF54
memstart = 0x00000000
memsize = 0x20000000
flashstart = 0xFF000000
flashsize = 0x01000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0xC01D2D00
intfreq = 500 MHz
busfreq = 166.666 MHz
ethaddr = 00:04:AC:E3:28:8A
eth1addr = 00:04:AC:E3:28:8B
eth2addr = 00:04:AC:E3:28:8C
eth3addr = 00:04:AC:E3:28:8D
IP addr = 192.168.0.116
baudrate = 115200 bps
## Loading RAMDisk Image at ff800000 ...
Image Name: Test Ramdisk
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1629365 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## initrd at 0xFF800040 ... 0xFF98DCF4 (len=1629365=0x18DCB5)
Loading Ramdisk to 1fe0f000, end 1ff9ccb5 ... OK
Linux version 2.6.11.6 (david@FedoraDG) (gcc-Version 3.3.3 (DENX ELDK 3.1
3.3.3-8)) #2 Thu Jul 7 01:33:11 CEST 2005
IBM
Built 1 zonelists
Kernel command line: console=ttyS1,115200 root=/dev/ram rw
PID hash table entries: 4096 (order: 12, 65536 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 515712k available (1372k kernel code, 464k data, 108k init, 0k
highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 1591k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: bridge rsrc 0..ffff (100), parent c0195018
PCI: bridge rsrc 80000000..ffffefff (200), parent c0195034
SCSI subsystem initialized
Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
mal0: Initialized, 4 tx channels, 4 rx channels
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt <benh@kernel.crashing.org>
zmii0: input 0 in SMII mode
eth0: IBM emac, MAC 00:04:ac:e3:28:8a
eth0: Found Generic MII PHY (0x05)
zmii0: input 1 in SMII mode
eth1: IBM emac, MAC 00:04:ac:e3:28:8b
eth1: Found Generic MII PHY (0x06)
zmii0: input 2 in SMII mode
rgmii0: input 0 in RGMII mode
emac2: Can't find PHY.
zmii0: input 3 in SMII mode
rgmii0: input 1 in RGMII mode
emac3: Can't find PHY.
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
RAMDISK: incomplete write (-28 != 1024) 4194304
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 108k init
eth0: Link is Up
eth0: Cannot reset EMAC
### Application running ...
BusyBox v0.60.5 (2004.11.10-15:02+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.
^ permalink raw reply
* Re: PPC440GX IBM EMAC2/3 RGMII mode selection
From: Eugene Surovegin @ 2005-07-07 15:28 UTC (permalink / raw)
To: David Grab; +Cc: linuxppc-embedded
In-Reply-To: <001401c58300$3643f870$f201a8c0@SN7606>
On Thu, Jul 07, 2005 at 04:28:57PM +0200, David Grab wrote:
> i have some problems to configure emac2, emac3 support of my ibm ppc440gx
> for linux kernel 2.6.11.6. I have two RGMII Phy?s connected to the ppc an no
> other PHY?s are connected. PPC Strapping is selected for Group4 (SMII, SMII,
> RGMII/RTBI, RGMII/RTBI). I only want to configure the RGMII support of emac2
> and emac3. But it seems like the PHY?s are used for eth0 (emac1) and eth1
> (emac2) which are configured as SMII. Could someone tell me, what i have to
> configure to select only emac2 and emac3 in RGMII mode?
Quick hack would be commenting out EMAC0 and EMAC1 ocp_def in
arch/ppc/platforms/4xx/ibm440gx.c.
Let me know if it works, and I'll think about more clean way to do
this.
--
Eugene
^ permalink raw reply
* Re: PPC440GX IBM EMAC2/3 RGMII mode selection
From: Eugene Surovegin @ 2005-07-07 15:41 UTC (permalink / raw)
To: Scott Coulter; +Cc: linuxppc-embedded
In-Reply-To: <43EB80E07C42E1408726E4905FB96B044404A6@CYBORG3.cyclone.com>
On Thu, Jul 07, 2005 at 11:36:55AM -0400, Scott Coulter wrote:
> What about:
>
> ocp_remove_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
> ocp_remove_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 1);
>
> dropped in xxx_setup_arch()?
>
Of course, too early in the morning for me, I guess. I forgot I asked
Matt to add this function :)
--
Eugene
^ permalink raw reply
* Fw: Montavista Patch for ml403
From: mcnernbm @ 2005-07-07 17:01 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 652 bytes --]
Contained with in the reference design for the xilinx ml403 board is a
patch for the montavista ml403 preview kit ot allow one to build the
kernel for the ml403 board. But I am having trouble applying the patch.
Does anyone know how to properly apply this patch. Also I tried to follow
the instrucions on coping the bsp files over but exactly where to place
them. Do I over write the folders with in the arch directory and the
drivers folder in the main kernel directory? Its not 100% clear what
files I need to over write.
Any help would be greatly appreciated.
Attached is the patch that come with the xilinx ml403 reference design
Brett
[-- Attachment #1.2: Type: text/html, Size: 848 bytes --]
[-- Attachment #2: patch_linux --]
[-- Type: application/octet-stream, Size: 1535 bytes --]
#!/bin/sh
if [ $# != 1 ] ; then
echo "Usage: $0 <Path to MontaVista Linux 3.1 Kernel for the ML300 board>"
echo
echo "$0 patches a MontaVista Linux 3.1 kernel for the"
echo "ML300 board (ML300 LSP) to make it useable with the ML403 board."
echo "Run this script AFTER you have generated the Linux board support package"
echo "with XPS. Provide the path to a COPY of the MontaVista Linux 3.1 kernel"
echo "as a parameter to $0."
exit 1
fi
# Check that the required tools and files are accessible
unzip=`which unzip 2> /dev/null`
[ ! -x "$unzip" ] && echo "Abort. Cannot find unzip in the search path." && exit 1
patch=`which patch 2> /dev/null`
[ ! -x "$patch" ] && echo "Abort. Cannot find patch in the search path." && exit 1
[ ! -r ml403.diff.zip ] && echo "Abort. Cannot read ml403.diff.zip." && exit 1
[ ! -r .config ] && echo "Abort. Cannot read .config." && exit 1
bspp=../ppc405_0/libsrc/linux_mvl31_v1_00_a/linux
[ ! -r "$bspp" ] && echo "Abort. Cannot read $bspp. Did you create the Linux BSP?" && exit 1
xp=arch/ppc/platforms/xilinx_ocp/xparameters_ml300.h
[ ! -r "$bspp/$xp" ] && echo "Abort. Cannot read $bspp/$xp. Did you create the Linux BSP?" && exit 1
lp=$1
[ ! -w "$lp" ] && echo "Abort. Cannot patch in $lp." && exit 1
# Ok, do it.
cp .config $lp
cp -Rp $bspp/* $lp
$unzip -p ml403.diff.zip | $patch -d $lp -p0 -F0
cat >> $lp/$xp <<EOF
#define XPAR_OPB_LCD_INTERFACE_0_BASEADDR XPAR_OPB_GPIO_CHAR_LCD_0_BASEADDR
#define XPAR_OPB_LCD_INTERFACE_0_HIGHADDR XPAR_OPB_GPIO_CHAR_LCD_0_HIGHADDR
EOF
^ permalink raw reply
* Re: Fw: Montavista Patch for ml403
From: Peter Ryser @ 2005-07-07 17:33 UTC (permalink / raw)
To: mcnernbm; +Cc: linuxppc-embedded
In-Reply-To: <OFEB66331D.10CE4400-ON85257037.005D805A-85257037.005D85D7@notes.udayton.edu>
The linux/patch_linux script has some information on how to apply the=20
patch. For the next release of the reference design we will include more=20
information and also have updated the patch. The new release will be=20
available within the next few days. Check=20
http://www.xilinx.com/products/boards/ml403/reference_designs.htm for=20
availability of the updates.
Further down find the updated instructions. I'll send you the updated=20
patch in a private email.
- Peter
Building the Linux BSP (PPC405 Systems Only)
The EDK design comes with MLD/TCL technology to generate a Linux BSP for=20
ML40x and a script to patch a MontaVista Linux kernel from the ML300 LSP=20
for use with this BSP.
To build a BSP for and to patch the Linux kernel, proceed as follows:
1. Start XPS and load the Linux XMP:
$ xps system_linux.xmp
2. Generate the Linux BSP with Tools->Generate Libraries and BSPs
The resulting Linux BSP is located in=20
ppc405_0/libsrc/linux_mvl31_v1_00_a/linux.
3. Quit XPS
4. Create a copy of the MontaVista Linux kernel for the ML300 board.
The Linux kernel and the tools to build the Linux kernel are available=20
from MontaVista (http://www.mvista.com). For further information about=20
using Linux with EDK, refer to XAPP765: Getting Started with EDK and=20
MontaVista Linux (http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf).
5. Patch the Linux kernel for use with the ML40x board
$ cd linux
$ ./patch_linux <path to the copy of the MontaVista Linux kernel>
This step copies the .config file from the linux directory to the Linux=20
kernel, patches the Linux kernel with necessary changes for the ML40x=20
board, and copies the Linux BSP into the Linux kernel.
Build the Linux kernel.
$ cd <path to the copy of the MontaVista Linux kernel>
$ make oldconfig dep bzImage
The resulting Linux kernel resides in arch/ppc/boot/images/zImage.elf
6. To build an ACE file consisting of the FPGA bitstream and the Linux=20
kernel, click Tools->Xygwin shell to run a shell, then type:
$ xmd =96tcl genace.tcl =96jprog =96hw implementation/download.bit =96elf=
<Linux=20
elf file> -ace implementation/system.ace
mcnernbm@notes.udayton.edu wrote:
>
> Contained with in the reference design for the xilinx ml403 board is a=20
> patch for the montavista ml403 preview kit ot allow one to build the=20
> kernel for the ml403 board. But I am having trouble applying the=20
> patch. Does anyone know how to properly apply this patch. Also I tried=20
> to follow the instrucions on coping the bsp files over but exactly=20
> where to place them. Do I over write the folders with in the arch=20
> directory and the drivers folder in the main kernel directory? Its not=20
> 100% clear what files I need to over write.
> Any help would be greatly appreciated.
> Attached is the patch that come with the xilinx ml403 reference design
>
> Brett
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* [patch 1/1] ppc/fcc_enet: replace schedule_timeout() with ssleep()
From: domen @ 2005-07-07 21:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, domen, Nishanth Aravamudan
From: Nishanth Aravamudan <nacc@us.ibm.com>
Use ssleep() instead of schedule_timeout() to guarantee the task delays
as expected.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Domen Puncer <domen@coderock.org>
---
fcc_enet.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
Index: quilt/arch/ppc/8260_io/fcc_enet.c
===================================================================
--- quilt.orig/arch/ppc/8260_io/fcc_enet.c
+++ quilt/arch/ppc/8260_io/fcc_enet.c
@@ -1305,12 +1305,11 @@ static void mii_parse_dm9161_scsr(uint m
static void mii_dm9161_wait(uint mii_reg, struct net_device *dev)
{
- int timeout = HZ;
+ int timeout_secs = 1;
/* Davicom takes a bit to come up after a reset,
* so wait here for a bit */
- set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(timeout);
+ ssleep(timeout_secs);
}
static phy_info_t phy_info_dm9161 = {
--
^ permalink raw reply
* remap_page_range not resolved
From: Bizhan Gholikhamseh (bgholikh) @ 2005-07-07 21:58 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
Hi All,
I am porting a Linux PCI driver originally developed for X86 platform to
MPC8540ADS reference board by Freescale running 2.6 Linux.
The "insmod" command fails when I am trying to load the module. The
failure is because the reference to a function name can not be resolved:
"remap_page_range"
Could someone help me please to find out what I am missing from my
kernel image?
Regards,
Bizhan
[-- Attachment #2: Type: text/html, Size: 1248 bytes --]
^ permalink raw reply
* Re: remap_page_range not resolved
From: David Woodhouse @ 2005-07-07 22:09 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA91127964151EC368@xmb-sjc-212.amer.cisco.com>
On Thu, 2005-07-07 at 14:58 -0700, Bizhan Gholikhamseh (bgholikh) wrote:
> I am porting a Linux PCI driver originally developed for X86 platform to
> MPC8540ADS reference board by Freescale running 2.6 Linux.
> The "insmod" command fails when I am trying to load the module. The
> failure is because the reference to a function name can not be resolved:
> "remap_page_range"
> Could someone help me please to find out what I am missing from my
> kernel image?
You forgot to include a reference to the source code of the driver
you're having trouble with.
Don't post HTML mail to public fora.
--
dwmw2
^ permalink raw reply
* Re: remap_page_range not resolved
From: Kumar Gala @ 2005-07-08 2:04 UTC (permalink / raw)
To: Bizhan Gholikhamseh \(bgholikh\); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA91127964151EC368@xmb-sjc-212.amer.cisco.com>
This is probably due to the change of remap_page_range to
remap_pfn_range. I forget the exact kernel version this was changed in.
- kumar
On Jul 7, 2005, at 4:58 PM, Bizhan Gholikhamseh \\((bgholikh\\)) wrote:
> Hi All,
> I am porting a Linux PCI driver originally developed for X86
> platform to
> MPC8540ADS reference board by Freescale running 2.6 Linux.
> The "insmod" command fails when I am trying to load the module. The
> failure is because the reference to a function name can not be
> resolved:
> "remap_page_range"
> Could someone help me please to find out what I am missing from my
> kernel image?
>
> Regards,
> Bizhan
>
> <ATT507020.txt>
>
^ permalink raw reply
* MPC8280 Support for Linux 2.4.25 and up?
From: Russell McGuire @ 2005-07-08 3:42 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050708020003.6BCF967BBC@ozlabs.org>
Everyone,
Are there any known issues with Linux 2.4.25 and supporting the MPC8280 CPU?
I have seen some posts in the past, and tried Google'ing for a patch for CPU
support, but have only seen tidbits... Seen some support issues for the 5200
as it also runs the G2_LE core.
So I guess, I am asking if there are patches, perhaps where?
Or should I consider moving up in kernel revisions, to get support for the
newer CPM_2 drivers.
Any help would be greatly appreciated.
Thanks,
Russell McGuire
^ permalink raw reply
* RE: CPM2 reports CRC errors in FCC2 for good packets
From: Bastos Fernandez Alexandre @ 2005-07-08 6:37 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Finally I got the problem solved. It was a hardware issue,
due mainly to my unknowledge.
For future archives searches ... the RX_ER line is reported
by CPM2 as a CRC error. And floating RX_ER is detected
as active.
Best regards,
Alex Bastos
> -----Original Message-----
> Hi guys,
>
> I am working with a MPC8248 custom board. On this, we have mixed
> interfaces, with Ethernet on FCC1 working in Full Duplex 100Mbps,
> and MII-generic on FCC2, working in Half-Duplex 100Mbps.
>
> On FCC2, CPM2 reports CRC error for each received packet, but
> ignoring it, packets arrive correctly. We have tested it with
> a known packet (ARP broadcast) through both interfaces, and this
> packet reports and CRC error on FCC2, but not in FCC1 ... but the
> received packet is the same in both cases !!! (taken from buffer
> pointed by RxBD):
>
> # FCC2 : Generic-mii Half Duplex
> # ARP Broadcast Packet received on board!!!
> FF FF FF FF FF FF 00 10 5A A7 8A F3 08 06 00 01 08 00 06 04 00 01
> 00 10 5A A7 8A F3 0A 00 00 03 00 00 00 00 00 00 0A 00 00 01 00 00
> 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 E7 E0 E9 46
> ... len: 64
> CBD_SC = 1C84 (crc_error)
>
>
> # FCC1 : ETHERNET Full Duplex
> # ARP Broadcast Packet received on board!!!
> FF FF FF FF FF FF 00 10 5A A7 8A F3 08 06 00 01 08 00 06 04 00 01
> 00 10 5A A7 8A F3 0A 00 00 03 00 00 00 00 00 00 0A 00 00 01 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E7 E0 E9 46
> ... len: 64
>
>
> So, packet is received ok, but CRC error is reported.
> Any idea? May it be a Hardware problem, even if packets are received
> OK by the driver?
>
>
> Thanks,
>
> Alexandre BASTOS
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: MPC8280 Support for Linux 2.4.25 and up?
From: Wolfgang Denk @ 2005-07-08 8:20 UTC (permalink / raw)
To: Russell McGuire; +Cc: linuxppc-embedded
In-Reply-To: <20050707234210.GA24326@mail19d.g19.rapidsite.net>
In message <20050707234210.GA24326@mail19d.g19.rapidsite.net> you wrote:
>
> Are there any known issues with Linux 2.4.25 and supporting the MPC8280 CPU?
No.
> I have seen some posts in the past, and tried Google'ing for a patch for CPU
> support, but have only seen tidbits... Seen some support issues for the 5200
> as it also runs the G2_LE core.
We also support the MPC8220 in our source tree (U-Boot and Linux)
which is the same family.
> So I guess, I am asking if there are patches, perhaps where?
On our CVS server?
> Or should I consider moving up in kernel revisions, to get support for the
> newer CPM_2 drivers.
What for?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A UNIX saleslady, Lenore,
Enjoys work, but she likes the beach more.
She found a good way
To combine work and play:
She sells C shells by the seashore.
^ permalink raw reply
* AW: PPC440GX IBM EMAC2/3 RGMII mode selection
From: David Grab @ 2005-07-08 11:14 UTC (permalink / raw)
To: linuxppc-embedded
I solved the PHY assertion with my board specific function. Thanks to Travis
B. Sawyer for this hint.
if (i < 2) {
emacdata->phy_map = 0xffffffff;
emacdata->phy_mode = PHY_MODE_NA;
}
else {
emacdata->phy_map = 0x00000001;
emacdata->phy_mode = PHY_MODE_RGMII;
}
But now i have a new problem. As you can see my PHY is detected and working
properly. It respond on link down and link up by (un)connecting ethernet
cable. Also i get RX Stuff from ethernet. But if i ping after setting
network, then it results in No response and even i can´t measure an TX
Enable or TX Clock signal from PPC440 to my PHY. I debugged a litte bit and
i think it´s becaus my ethernet is set up with zmii0: input 0 in SMII mode
and rgmii0: input 0 in RGMII mode. Is it possible that eth0 uses SMII mode
instead of RGMII so that no TX CLK / Enable is generated from PPC?
bootd
## Booting image at ff000000 ...
Image Name: Linux-2.6.11.6
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 891020 Bytes = 870.1 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x1FF9D898 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF25
bd address = 0x1FF9DF54
memstart = 0x00000000
memsize = 0x20000000
flashstart = 0xFF000000
flashsize = 0x01000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0xC01D2260
intfreq = 500 MHz
busfreq = 166.666 MHz
ethaddr = 00:04:AC:E3:28:8A
eth1addr = 00:04:AC:E3:28:8B
eth2addr = 00:04:AC:E3:28:8C
eth3addr = 00:04:AC:E3:28:8D
IP addr = 192.168.0.116
baudrate = 115200 bps
## Loading RAMDisk Image at ff800000 ...
Image Name: Test Ramdisk
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1629365 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## initrd at 0xFF800040 ... 0xFF98DCF4 (len=1629365=0x18DCB5)
Loading Ramdisk to 1fe0f000, end 1ff9ccb5 ... OK
## Transferring control to Linux (at address 00000000) ...
## Transferring control to Linux (at address 00000000) ...
Adresse: 7ffe50
Linux version 2.6.11.6 (david@FedoraDG) (gcc-Version 3.3.3 (DENX ELDK 3.1
3.3.3-8)) #12 Fri Jul 8 00:54:21 CEST 2005
IBM
Built 1 zonelists
Kernel command line: console=ttyS1,115200 root=/dev/ram rw
PID hash table entries: 4096 (order: 12, 65536 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 515712k available (1372k kernel code, 464k data, 108k init, 0k
highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 1591k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: bridge rsrc 0..ffff (100), parent c0195018
PCI: bridge rsrc 80000000..ffffefff (200), parent c0195034
SCSI subsystem initialized
Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
mal0: Initialized, 4 tx channels, 4 rx channels
emac: IBM EMAC Ethernet driver, version 2.0
Maintained by Benjamin Herrenschmidt <benh@kernel.crashing.org>
zmii0: input 0 in SMII mode
emac0: Can't find PHY.
zmii0: input 1 in SMII mode
emac1: Can't find PHY.
zmii0: input 2 in SMII mode
rgmii0: input 0 in RGMII mode
eth0: IBM emac, MAC 00:04:ac:e3:28:8c
eth0: Found Generic MII PHY (0x05)
zmii0: input 3 in SMII mode
rgmii0: input 1 in RGMII mode
eth1: IBM emac, MAC 00:04:ac:e3:28:8d
eth1: Found Generic MII PHY (0x06)
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
RAMDISK: incomplete write (-28 != 1024) 4194304
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 108k init
eth0: Link is Up
eth0: Speed: 100, Full duplex.
### Application running ...
BusyBox v0.60.5 (2004.11.10-15:02+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.
# ifconfig eth0 192.168.0.116 netmask 255.255.252.0
# eth0: Link is Up
eth0: Speed: 100, Full duplex.
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:04:AC:E3:28:8C
inet addr:192.168.0.116 Bcast:192.168.0.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:134 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9225 (9.0 kiB) TX bytes:0 (0.0 iB)
Interrupt:64
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 iB) TX bytes:0 (0.0 iB)
# ping 192.168.121
emac_start_xmit()
exitn
emac_start_xmit()
exitn
emac_start_xmit()
exitn
No response from 192.168.0.121
#
^ permalink raw reply
* ¢©¿ï¾Ü³ÌÀuªº¯Ó§÷«~½è¡ã¨ìªá¥P¤l·Ç¨S¿ù¢ª
From: ¦Lªí¾÷¯Ó§÷ Corona @ 2005-07-08 10:23 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 1911 bytes --]
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Marcelo Tosatti @ 2005-07-08 0:36 UTC (permalink / raw)
To: Yuli Barcohen; +Cc: Joakim Tjernlund, Jason McMullan, linux-ppc-embedded
In-Reply-To: <17096.61878.43282.752343@astp0002.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
Hi Yuli,
On Mon, Jul 04, 2005 at 11:22:14AM +0300, Yuli Barcohen wrote:
> >>>>> Jason McMullan writes:
>
> [...deleted...]
>
> Jason> Ha. Funny. The glibc powerpc maintainer doesn't want any
> Jason> embedded fixes in the mainline. Last I checked, that was for
> Jason> 'the tools vendors' to fix.
>
> Jason> "We won't work around processor bugs" is their philosophy.
>
> [...deleted...]
>
> I investigated the problem a bit when I had trouble with a self-compiled
> glibc a year or so ago. IIRC, I found bug in the memset code, not in the
> chip. The code was just wrong for cache line sizes not equal to 32. So
> memset.S is good for 60x series (PQII included) but for 8xx it fails.
I suppose you didnt actually use dcbz for userspace memset on 8xx?
> We use dcbX instructions in some kernel drivers and since we never had any
> problems with those drivers I'm a bit surprised to hear that all 8xx
> chips have got that bug.
The problem is that the DAR register is correctly unset (it comes as NULL IIRC)
on pagefaults for the dcbz instruction. The dcbz instructions you issue are probably
always works on kernel addresses whose pagetables are present?
Joakim has developed a workaround for the problem... although I promised him
several times to test it I never managed to get dcbz to work on the kernel
copying functions. :(
He has posted it here in the past... here it is attached anyway.
[-- Attachment #2: dcbx.patch5 --]
[-- Type: text/plain, Size: 8750 bytes --]
===== head_8xx.S 1.21 vs edited =====
--- 1.21/arch/ppc/kernel/head_8xx.S 2005-03-29 00:21:20 +02:00
+++ edited/head_8xx.S 2005-04-06 17:01:51 +02:00
@@ -32,6 +32,8 @@
#include <asm/ppc_asm.h>
#include <asm/offsets.h>
+#define CONFIG_8xx_DCBxFIXED
+
/* Macro to make the code more readable. */
#ifdef CONFIG_8xx_CPU6
#define DO_8xx_CPU6(val, reg) \
@@ -41,6 +43,20 @@
#else
#define DO_8xx_CPU6(val, reg)
#endif
+
+#ifdef CONFIG_8xx_DCBxFIXED
+/* These macros are used to tag DAR with a known value so that the
+ * DataTLBError can recognize a buggy dcbx instruction and workaround
+ * the problem.
+ */
+#define TAG_VAL 0x00f0 /* -1 may also be used */
+#define TAG_DAR_R10 \
+ li r10, TAG_VAL;\
+ mtspr SPRN_DAR, r10;
+#else
+#define TAG_DAR_R10
+#endif
+
.text
.globl _stext
_stext:
@@ -174,6 +190,7 @@
xfer(n, hdlr)
#define EXC_XFER_TEMPLATE(n, hdlr, trap, copyee, tfer, ret) \
+ TAG_DAR_R10; \
li r10,trap; \
stw r10,TRAP(r11); \
li r10,MSR_KERNEL; \
@@ -214,6 +231,7 @@
mfspr r5,SPRN_DSISR
stw r5,_DSISR(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
+ TAG_DAR_R10
EXC_XFER_STD(0x200, MachineCheckException)
/* Data access exception.
@@ -227,6 +245,7 @@
stw r10,_DSISR(r11)
mr r5,r10
mfspr r4,SPRN_DAR
+ TAG_DAR_R10
EXC_XFER_EE_LITE(0x300, handle_page_fault)
/* Instruction access exception.
@@ -252,6 +271,7 @@
mfspr r5,SPRN_DSISR
stw r5,_DSISR(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
+ TAG_DAR_R10
EXC_XFER_EE(0x600, AlignmentException)
/* Program check exception */
@@ -414,7 +434,13 @@
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
-
+#ifdef CONFIG_8xx_DCBxFIXED
+ #if TAG_VAL == 0x00f0 /* Save 1 instr. by reusing the val loaded in r11 above */
+ mtspr SPRN_DAR, r11
+ #else
+ TAG_DAR_R10
+ #endif
+#endif
mfspr r10, SPRN_M_TW /* Restore registers */
lwz r11, 0(r0)
mtcr r11
@@ -450,11 +476,20 @@
mfcr r10
stw r10, 0(r0)
stw r11, 4(r0)
+ mfspr r10, SPRN_DAR
+#ifdef CONFIG_8xx_DCBxFIXED
+ /* If DAR contains TAG_VAL implies a buggy dcbx instruction
+ * that did not set DAR.
+ */
+ cmpwi cr0, r10, TAG_VAL
+ beq- 100f /* Branch if TAG_VAL to dcbx workaround procedure */
+101: /* return from dcbx instruction bug workaround, r10 holds value of DAR */
+#endif
/* First, make sure this was a store operation.
*/
- mfspr r10, SPRN_DSISR
- andis. r11, r10, 0x0200 /* If set, indicates store op */
+ mfspr r11, SPRN_DSISR
+ andis. r11, r11, 0x0200 /* If set, indicates store op */
beq 2f
/* The EA of a data TLB miss is automatically stored in the MD_EPN
@@ -473,7 +508,7 @@
* are initialized in mapin_ram(). This will avoid the problem,
* assuming we only use the dcbi instruction on kernel addresses.
*/
- mfspr r10, SPRN_DAR
+ /* DAR is in r10 already */
rlwinm r11, r10, 0, 0, 19
ori r11, r11, MD_EVALID
mfspr r10, SPRN_M_CASID
@@ -523,7 +558,13 @@
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
-
+#ifdef CONFIG_8xx_DCBxFIXED
+ #if TAG_VAL == 0x00f0 /* Save 1 instr. by reusing the val loaded in r11 above */
+ mtspr SPRN_DAR, r11
+ #else
+ TAG_DAR_R10
+ #endif
+#endif
mfspr r10, SPRN_M_TW /* Restore registers */
lwz r11, 0(r0)
mtcr r11
@@ -561,6 +602,185 @@
. = 0x2000
+#ifdef CONFIG_8xx_DCBxFIXED
+/* This is the workaround procedure to calculate the data EA for buggy dcbx,dcbi instructions
+ * by decoding the registers used by the dcbx instruction and adding them.
+ * DAR is set to the calculated address and r10 also holds the EA on exit.
+ */
+//#define INSTR_CHECK /* define to verify if it is a dcbx instr. Should not be needed. */
+//#define NO_SELF_MODIFYING_CODE /* define if you don't want to use self modifying code */
+//#define DEBUG_DCBX_INSTRUCTIONS /* for debugging only. Needs INSTR_CHECK defined as well. */
+//#define KERNEL_SPACE_ONLY /* define if user space do NOT contain dcbx instructions. */
+
+#ifndef KERNEL_SPACE_ONLY
+ nop /* A few nops to make the modified_instr: space below cache line aligned */
+ nop
+139: /* fetch instruction from userspace memory */
+ DO_8xx_CPU6(0x3780, r3)
+ mtspr SPRN_MD_EPN, r10
+ mfspr r11, SPRN_M_TWB /* Get level 1 table entry address */
+ lwz r11, 0(r11) /* Get the level 1 entry */
+ DO_8xx_CPU6(0x3b80, r3)
+ mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
+ mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
+ lwz r11, 0(r11) /* Get the pte */
+ /* concat physical page address(r11) and page offset(r10) */
+ rlwimi r11, r10, 0, 20, 31
+ b 140f
+#endif
+100: /* Entry point for dcbx workaround. */
+ /* fetch instruction from memory. */
+ mfspr r10,SPRN_SRR0
+#ifndef KERNEL_SPACE_ONLY
+ andis. r11, r10, 0x8000
+ tophys (r11, r10)
+ beq- 139b /* Branch if user space address */
+#else
+ tophys (r11, r10)
+#endif
+140: lwz r11,0(r11)
+#ifdef INSTR_CHECK
+/* Check if it really is a dcbx instruction. This is not needed as far as I can tell */
+/* dcbt and dcbtst does not generate DTLB Misses/Errors, no need to include them here */
+ rlwinm r10, r11, 0, 21, 30
+ cmpwi cr0, r10, 2028 /* Is dcbz? */
+ beq+ 142f
+ cmpwi cr0, r10, 940 /* Is dcbi? */
+ beq+ 142f
+ cmpwi cr0, r10, 108 /* Is dcbst? */
+ beq+ 142f
+ cmpwi cr0, r10, 172 /* Is dcbf? */
+ beq+ 142f
+ cmpwi cr0, r10, 1964 /* Is icbi? */
+ beq+ 142f
+#ifdef DEBUG_DCBX_INSTRUCTIONS
+141: b 141b /* Stop here if no dcbx instruction */
+#endif
+ mfspr r10, SPRN_DAR /* r10 must hold DAR at exit */
+ b 101b /* None of the above, go back to normal TLB processing */
+142: /* continue, it was a dcbx instruction. */
+#endif
+#ifdef CONFIG_8xx_CPU6
+ lwz r3, 8(r0) /* restore r3 from memory */
+#endif
+#ifndef NO_SELF_MODIFYING_CODE
+ andis. r10,r11,0x1f /* test if reg RA is r0 */
+ li r10,modified_instr@l
+ dcbtst r0,r10 /* touch for store */
+ rlwinm r11,r11,0,0,20 /* Zero lower 10 bits */
+ oris r11,r11,640 /* Transform instr. to a "add r10,RA,RB" */
+ ori r11,r11,532
+ stw r11,0(r10) /* store add/and instruction */
+ dcbf 0,r10 /* flush new instr. to memory. */
+ icbi 0,r10 /* invalidate instr. cache line */
+ lwz r11, 4(r0) /* restore r11 from memory */
+ mfspr r10, SPRN_M_TW /* restore r10 from M_TW */
+ isync /* Wait until new instr is loaded from memory */
+modified_instr:
+ .space 4 /* this is where the add/and instr. is stored */
+#ifdef DEBUG_DCBX_INSTRUCTIONS
+ /* fill with some garbage */
+ li r11,0xffff
+ stw r11,0(r11)
+#endif
+ bne+ 143f
+ subf r10,r0,r10 /* r10=r10-r0, only if reg RA is r0 */
+143: mtdar r10 /* store faulting EA in DAR */
+ b 101b /* Go back to normal TLB handling */
+#else
+ mfctr r10
+ mtdar r10 /* save ctr reg in DAR */
+ rlwinm r10, r11, 24, 24, 28 /* offset into jump table for reg RB */
+ addi r10, r10, 150f@l /* add start of table */
+ mtctr r10 /* load ctr with jump address */
+ xor r10, r10, r10 /* sum starts at zero */
+ bctr /* jump into table */
+150:
+ add r10, r10, r0
+ b 151f
+ add r10, r10, r1
+ b 151f
+ add r10, r10, r2
+ b 151f
+ add r10, r10, r3
+ b 151f
+ add r10, r10, r4
+ b 151f
+ add r10, r10, r5
+ b 151f
+ add r10, r10, r6
+ b 151f
+ add r10, r10, r7
+ b 151f
+ add r10, r10, r8
+ b 151f
+ add r10, r10, r9
+ b 151f
+ mtctr r11 /* reg 10 needs special handling */
+ b 154f
+ mtctr r11 /* reg 11 needs special handling */
+ b 153f
+ add r10, r10, r12
+ b 151f
+ add r10, r10, r13
+ b 151f
+ add r10, r10, r14
+ b 151f
+ add r10, r10, r15
+ b 151f
+ add r10, r10, r16
+ b 151f
+ add r10, r10, r17
+ b 151f
+ add r10, r10, r18
+ b 151f
+ add r10, r10, r19
+ b 151f
+ add r10, r10, r20
+ b 151f
+ add r10, r10, r21
+ b 151f
+ add r10, r10, r22
+ b 151f
+ add r10, r10, r23
+ b 151f
+ add r10, r10, r24
+ b 151f
+ add r10, r10, r25
+ b 151f
+ add r10, r10, r25
+ b 151f
+ add r10, r10, r27
+ b 151f
+ add r10, r10, r28
+ b 151f
+ add r10, r10, r29
+ b 151f
+ add r10, r10, r30
+ b 151f
+ add r10, r10, r31
+151:
+ rlwinm. r11,r11,19,24,28 /* offset into jump table for reg RA */
+ beq 152f /* if reg RA is zero, don't add it */
+ addi r11, r11, 150b@l /* add start of table */
+ mtctr r11 /* load ctr with jump address */
+ rlwinm r11,r11,0,16,10 /* make sure we don't execute this more than once */
+ bctr /* jump into table */
+152:
+ mfdar r11
+ mtctr r11 /* restore ctr reg from DAR */
+ mtdar r10 /* save fault EA to DAR */
+ b 101b /* Go back to normal TLB handling */
+
+ /* special handling for r10,r11 since these are modified already */
+153: lwz r11, 4(r0) /* load r11 from memory */
+ b 155f
+154: mfspr r11, SPRN_M_TW /* load r10 from M_TW */
+155: add r10, r10, r11 /* add it */
+ mfctr r11 /* restore r11 */
+ b 151b
+#endif
+#endif
.globl giveup_fpu
giveup_fpu:
blr
^ permalink raw reply
* Re: PPC440GX IBM EMAC2/3 RGMII mode selection
From: Eugene Surovegin @ 2005-07-08 15:40 UTC (permalink / raw)
To: David Grab; +Cc: linuxppc-embedded
In-Reply-To: <001501c583ae$44cc3930$f201a8c0@SN7606>
On Fri, Jul 08, 2005 at 01:14:54PM +0200, David Grab wrote:
> I solved the PHY assertion with my board specific function. Thanks to Travis
> B. Sawyer for this hint.
>
> if (i < 2) {
> emacdata->phy_map = 0xffffffff;
> emacdata->phy_mode = PHY_MODE_NA;
> }
> else {
> emacdata->phy_map = 0x00000001;
> emacdata->phy_mode = PHY_MODE_RGMII;
> }
>
> But now i have a new problem. As you can see my PHY is detected and working
> properly. It respond on link down and link up by (un)connecting ethernet
> cable. Also i get RX Stuff from ethernet. But if i ping after setting
> network, then it results in No response and even i can?t measure an TX
> Enable or TX Clock signal from PPC440 to my PHY. I debugged a litte bit and
> i think it?s becaus my ethernet is set up with zmii0: input 0 in SMII mode
> and rgmii0: input 0 in RGMII mode. Is it possible that eth0 uses SMII mode
> instead of RGMII so that no TX CLK / Enable is generated from PPC?
[snip]
> mal0: Initialized, 4 tx channels, 4 rx channels
> emac: IBM EMAC Ethernet driver, version 2.0
> Maintained by Benjamin Herrenschmidt <benh@kernel.crashing.org>
> zmii0: input 0 in SMII mode
> emac0: Can't find PHY.
> zmii0: input 1 in SMII mode
> emac1: Can't find PHY.
> zmii0: input 2 in SMII mode
> rgmii0: input 0 in RGMII mode
> eth0: IBM emac, MAC 00:04:ac:e3:28:8c
> eth0: Found Generic MII PHY (0x05)
> zmii0: input 3 in SMII mode
> rgmii0: input 1 in RGMII mode
> eth1: IBM emac, MAC 00:04:ac:e3:28:8d
> eth1: Found Generic MII PHY (0x06)
Are you using gigabit connection or ordinary fast ethernet (100 Mbps)?
If gige, then you have to add your gig PHY definition. Generic MII PHY
in the current driver doesn't support GigE (my version supports it).
Another question, is ethernet on your board working in U-Boot?
There is alternative EMAC driver I wrote, which fixed numerous
problems with current driver version (http://kernel.ebshome.net). You
can try it and I can help you getting it working on your board,
unfortunately I cannot help you much with the current driver, because
it's known to be buggy and IMHO fighting it is a waste of time.
--
Eugene
^ permalink raw reply
* Re: remap_page_range not resolved
From: Ralph Siemsen @ 2005-07-08 17:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: Bizhan Gholikhamseh \(bgholikh\), linuxppc-embedded
In-Reply-To: <354AB8A8-1BE5-4BC0-8252-D51D1CEF6B51@freescale.com>
Kumar Gala wrote:
> This is probably due to the change of remap_page_range to
> remap_pfn_range. I forget the exact kernel version this was changed in.
It just happened in 2.6.12.
http://lwn.net/Articles/129480/
-R
^ permalink raw reply
* PATCH: Add memreserve to DTC
From: Jon Loeliger @ 2005-07-08 21:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt, David Gibson; +Cc: linuxppc-dev@ozlabs.org
David and Ben,
This patch adds support for memreserve to the DTC's notion
of the "source file". That is, you can now say this:
memreserve = <
0000 0001 0000 0002
0000 0003 0000 0004
>
/ {
model = "MPC8555CDS";
compatible = "MPC85xxCDS";
#address-cells = <2>;
#size-cells = <2>;
linux,phandle = <100>;
There is minor fiddling with the -R flag that needs to be
resolved at this point.
I've included read and writing for the source and blob formats,
but don't have a clue what to do with the /proc/devices format.
I've also tinkered the Makefile to do automatic dependency
file generation and inclusion. Yep, I got bit by out of
date dependencies during my development here. :-)
Please feel free to adjust my coding approach or argument
passing or whatever as needed. Hope this helps!
Enjoy,
jdl
PS -- Is this the right forum to continue to post the DTC patches?
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Index: Makefile
===================================================================
--- abbe76bc79348c0896908c8548d51bdfa5f76500/Makefile (mode:100644)
+++ uncommitted/Makefile (mode:100644)
@@ -6,29 +6,35 @@
OBJS = dtc.o livetree.o flattree.o data.o treesource.o fstree.o \
dtc-parser.tab.o lex.yy.o
-all: $(TARGETS)
+DEPFILES := $(OBJS:.o=.d)
+
+
+all: $(DEPFILES) $(TARGETS)
dtc: $(OBJS)
$(LINK.c) -o $@ $^
-$(OBJS): dtc.h
-
dtc-parser.tab.c dtc-parser.tab.h dtc-parser.output: dtc-parser.y
$(BISON) -d -v $<
lex.yy.c: dtc-lexer.l
$(LEX) $<
+dtc-lexer.l: dtc-parser.tab.h
lex.yy.o: lex.yy.c dtc-parser.tab.h
-livetree.o: flat_dt.h
check: all
cd tests && $(MAKE) check
clean:
+ rm -f ${DEPFILES}
rm -f *~ *.o a.out core $(TARGETS)
rm -f *.tab.[ch] lex.yy.c
rm -f *.i *.output vgcore.*
cd tests && $(MAKE) clean
+%.d : %.c
+ $(CC) -MM $< > $@
+
+-include ${DEPFILES}
Index: dtc-lexer.l
===================================================================
--- abbe76bc79348c0896908c8548d51bdfa5f76500/dtc-lexer.l (mode:100644)
+++ uncommitted/dtc-lexer.l (mode:100644)
@@ -87,6 +87,11 @@
return ']';
}
+memreserve {
+ DPRINT("Keyword: memreserve\n");
+ return DT_MEMRESERVE;
+ }
+
{PROPCHAR}+ {
DPRINT("PropName: %s\n", yytext);
yylval.str = strdup(yytext);
Index: dtc-parser.y
===================================================================
--- abbe76bc79348c0896908c8548d51bdfa5f76500/dtc-parser.y (mode:100644)
+++ uncommitted/dtc-parser.y (mode:100644)
@@ -41,6 +41,7 @@
int hexlen;
}
+%token DT_MEMRESERVE
%token <str> DT_PROPNAME
%token <str> DT_NODENAME
%token <cval> DT_CELL
@@ -66,6 +67,21 @@
%%
+sourcefile:
+ headersection
+ devicetree
+ {
+ }
+ ;
+
+headersection:
+ /* empty */
+ | DT_MEMRESERVE '=' '<' celllist '>'
+ {
+ build_mem_reserve($4);
+ }
+ ;
+
devicetree: {
assert(device_tree == NULL);
} '/' nodedef { device_tree = name_node($3, "", NULL); }
Index: dtc.c
===================================================================
--- abbe76bc79348c0896908c8548d51bdfa5f76500/dtc.c (mode:100644)
+++ uncommitted/dtc.c (mode:100644)
@@ -103,6 +103,7 @@
int main(int argc, char *argv[])
{
struct node *dt;
+ struct data mem_reserve_data = empty_data;
char *inform = "dts";
char *outform = "dts";
char *outname = "-";
@@ -151,12 +152,12 @@
if (streq(inform, "dts")) {
inf = dtc_open_file(arg);
- dt = dt_from_source(inf);
+ dt = dt_from_source(inf, &mem_reserve_data);
} else if (streq(inform, "fs")) {
- dt = dt_from_fs(arg);
+ dt = dt_from_fs(arg, &mem_reserve_data);
} else if(streq(inform, "dtb")) {
inf = dtc_open_file(arg);
- dt = dt_from_blob(inf);
+ dt = dt_from_blob(inf, &mem_reserve_data);
} else {
die("Unknown input format \"%s\"\n", inform);
}
@@ -183,11 +184,11 @@
}
if (streq(outform, "dts")) {
- write_tree_source(outf, dt, 0);
+ write_tree_source(outf, dt, &mem_reserve_data);
} else if (streq(outform, "dtb")) {
- write_dt_blob(outf, dt, outversion, reservenum);
+ write_dt_blob(outf, dt, outversion, &mem_reserve_data);
} else if (streq(outform, "asm")) {
- write_dt_asm(outf, dt, outversion, reservenum);
+ write_dt_asm(outf, dt, outversion, &mem_reserve_data);
} else if (streq(outform, "null")) {
/* do nothing */
} else {
Index: dtc.h
===================================================================
--- abbe76bc79348c0896908c8548d51bdfa5f76500/dtc.h (mode:100644)
+++ uncommitted/dtc.h (mode:100644)
@@ -117,6 +117,9 @@
int data_is_one_string(struct data d);
+void build_mem_reserve(struct data d);
+
+
/* DT constraints */
#define MAX_PROPNAME_LEN 31
@@ -174,20 +177,23 @@
FFMT_ASM,
};
-void write_dt_blob(FILE *f, struct node *tree, int version, int reservenum);
-void write_dt_asm(FILE *f, struct node *tree, int version, int reservenum);
+void write_dt_blob(FILE *f, struct node *tree, int version,
+ struct data *mem_reserve_data);
+void write_dt_asm(FILE *f, struct node *tree, int version,
+ struct data *mem_reserve_data);
-struct node *dt_from_blob(FILE *f);
+struct node *dt_from_blob(FILE *f, struct data *mem_reserve_data);
/* Tree source */
-void write_tree_source(FILE *f, struct node *tree, int level);
+void write_tree_source(FILE *f, struct node *tree,
+ struct data *mem_reserve_data);
-struct node *dt_from_source(FILE *f);
+struct node *dt_from_source(FILE *f, struct data *mem_reserve_data);
/* FS trees */
-struct node *dt_from_fs(char *dirname);
+struct node *dt_from_fs(char *dirname, struct data *mem_reserve_data);
/* misc */
Index: flattree.c
===================================================================
--- abbe76bc79348c0896908c8548d51bdfa5f76500/flattree.c (mode:100644)
+++ uncommitted/flattree.c (mode:100644)
@@ -288,10 +288,12 @@
static void make_bph(struct boot_param_header *bph,
struct version_info *vi,
- int reservenum,
+ struct data *mem_reserve_data,
int dtsize, int strsize)
{
- int reservesize = (reservenum+1) * sizeof(struct reserve_entry);
+ int reservenum = mem_reserve_data->len / sizeof(struct reserve_entry);
+ int reservesize = (reservenum + 1) * sizeof(struct reserve_entry);
+ int pad = sizeof(struct boot_param_header) % 8;
memset(bph, 0xff, sizeof(*bph));
@@ -299,11 +301,11 @@
bph->version = vi->version;
bph->last_comp_version = vi->last_comp_version;
- bph->off_mem_rsvmap = cpu_to_be32(vi->hdr_size);
- bph->off_dt_struct = cpu_to_be32(vi->hdr_size + reservesize);
- bph->off_dt_strings = cpu_to_be32(vi->hdr_size + reservesize
+ bph->off_mem_rsvmap = cpu_to_be32(vi->hdr_size + pad);
+ bph->off_dt_struct = cpu_to_be32(vi->hdr_size + pad + reservesize);
+ bph->off_dt_strings = cpu_to_be32(vi->hdr_size + pad + reservesize
+ dtsize);
- bph->totalsize = cpu_to_be32(vi->hdr_size + reservesize
+ bph->totalsize = cpu_to_be32(vi->hdr_size + pad + reservesize
+ dtsize + strsize);
if (vi->flags & FTF_BOOTCPUID)
@@ -312,7 +314,8 @@
bph->size_dt_strings = cpu_to_be32(strsize);
}
-void write_dt_blob(FILE *f, struct node *tree, int version, int reservenum)
+void write_dt_blob(FILE *f, struct node *tree, int version,
+ struct data *mem_reserve_data)
{
struct version_info *vi = NULL;
int i;
@@ -320,6 +323,8 @@
struct data strbuf = empty_data;
struct boot_param_header bph;
struct reserve_entry re = {.address = 0, .size = 0};
+ int pad;
+ int pad_buf = 0;
for (i = 0; i < ARRAY_SIZE(version_table); i++) {
if (version_table[i].version == version)
@@ -334,11 +339,30 @@
flatten_tree(tree, &bin_emitter, &dtbuf, &strbuf, vi);
bin_emit_cell(&dtbuf, OF_DT_END);
- make_bph(&bph, vi, reservenum, dtbuf.len, strbuf.len);
-
+ /*
+ * Make header.
+ */
+ make_bph(&bph, vi, mem_reserve_data, dtbuf.len, strbuf.len);
fwrite(&bph, vi->hdr_size, 1, f);
- for (i = 0; i < reservenum+1; i++)
- fwrite(&re, sizeof(re), 1, f);
+
+ /*
+ * Allow possible trailing alignment for mem reserve map.
+ */
+ if (((pad = sizeof(struct boot_param_header) % 8)) != 0) {
+ fwrite(&pad_buf, 1, pad, f);
+ }
+
+ /*
+ * Reserve map entries.
+ * Since the blob is relocatable, the address of the map is not
+ * determinable here, so no entry is made for the DT itself.
+ * Each entry is an (address, size) pair of u64 values.
+ * Always supply a zero-sized temination entry.
+ */
+ fwrite(mem_reserve_data->val, mem_reserve_data->len, 1, f);
+ re.address = 0;
+ re.size = 0;
+ fwrite(&re, sizeof(re), 1, f);
fwrite(dtbuf.val, dtbuf.len, 1, f);
fwrite(strbuf.val, strbuf.len, 1, f);
@@ -364,7 +388,8 @@
}
}
-void write_dt_asm(FILE *f, struct node *tree, int version, int reservenum)
+void write_dt_asm(FILE *f, struct node *tree, int version,
+ struct data *mem_reserve_data)
{
struct version_info *vi = NULL;
int i;
@@ -408,16 +433,27 @@
fprintf(f, "\t.long\t_%s_strings_end - _%s_strings_start\t/* size_dt_strings */\n",
symprefix, symprefix);
+ /*
+ * Reserve map entries.
+ * Each entry is an (address, size) pair of u64 values.
+ * Since the ASM file variant can relocate and compute the address
+ * and size of the the device tree itself, and an entry for it.
+ * Always supply a zero-sized temination entry.
+ */
+ asm_emit_align(f, 8);
emit_label(f, symprefix, "reserve_map");
- /* reserve map entry for the device tree itself */
fprintf(f, "\t.long\t0, _%s_blob_start\n", symprefix);
fprintf(f, "\t.long\t0, _%s_blob_end - _%s_blob_start\n",
symprefix, symprefix);
- for (i = 0; i < reservenum+1; i++) {
- fprintf(f, "\t.llong\t0\n");
- fprintf(f, "\t.llong\t0\n");
+
+ if (mem_reserve_data->len > 0) {
+ fprintf(f, "/* Memory reserve map from source file */\n");
+ asm_emit_data(f, *mem_reserve_data);
}
+ fprintf(f, "\t.llong\t0\n");
+ fprintf(f, "\t.llong\t0\n");
+
emit_label(f, symprefix, "struct_start");
flatten_tree(tree, &asm_emitter, f, &strbuf, vi);
fprintf(f, "\t.long\tOF_DT_END\n");
@@ -518,7 +554,8 @@
p = inb->base + offset;
while (1) {
if (p >= inb->limit)
- die("String offset %d overruns string table\n");
+ die("String offset %d overruns string table\n",
+ offset);
if (*p == '\0')
break;
@@ -549,6 +586,43 @@
return build_property(name, val, NULL);
}
+
+static struct data flat_read_mem_reserve(struct inbuf *inb)
+{
+ char *p;
+ int len = 0;
+ int done = 0;
+ cell_t cells[4];
+ struct data d;
+
+ d = empty_data;
+
+ /*
+ * Each entry is a pair of u64 (addr, size) values for 4 cell_t's.
+ * List terminates at an entry with size equal to zero.
+ *
+ * First pass, count entries.
+ */
+ p = inb->ptr;
+ do {
+ flat_read_chunk(inb, &cells[0], 4 * sizeof(cell_t));
+ if (cells[2] == 0 && cells[3] == 0) {
+ done = 1;
+ } else {
+ ++len;
+ }
+ } while (!done);
+
+ /*
+ * Back up for pass two, reading the whole data value.
+ */
+ inb->ptr = p;
+ d = flat_read_data(inb, len * 4 * sizeof(cell_t));
+
+ return d;
+}
+
+
static char *nodename_from_path(char *ppath, char *cpath)
{
char *lslash;
@@ -656,14 +730,17 @@
return node;
}
-struct node *dt_from_blob(FILE *f)
+
+struct node *dt_from_blob(FILE *f, struct data *mem_reserve_data)
{
- u32 magic, totalsize, off_dt, off_str, version, size_str;
+ u32 magic, totalsize, version, size_str;
+ u32 off_dt, off_str, off_mem_rsvmap;
int rc;
char *blob;
struct boot_param_header *bph;
char *p;
struct inbuf dtbuf, strbuf;
+ struct inbuf memresvbuf;
int sizeleft;
struct node *tree;
u32 val;
@@ -723,18 +800,21 @@
off_dt = be32_to_cpu(bph->off_dt_struct);
off_str = be32_to_cpu(bph->off_dt_strings);
+ off_mem_rsvmap = be32_to_cpu(bph->off_mem_rsvmap);
version = be32_to_cpu(bph->version);
fprintf(stderr, "\tmagic:\t\t\t0x%x\n", magic);
fprintf(stderr, "\ttotalsize:\t\t%d\n", totalsize);
fprintf(stderr, "\toff_dt_struct:\t\t0x%x\n", off_dt);
fprintf(stderr, "\toff_dt_strings:\t\t0x%x\n", off_str);
- fprintf(stderr, "\toff_mem_rsvmap:\t\t0x%x\n",
- be32_to_cpu(bph->off_mem_rsvmap));
+ fprintf(stderr, "\toff_mem_rsvmap:\t\t0x%x\n", off_mem_rsvmap);
fprintf(stderr, "\tversion:\t\t0x%x\n", version );
fprintf(stderr, "\tlast_comp_version:\t0x%x\n",
be32_to_cpu(bph->last_comp_version));
+ if (off_mem_rsvmap >= totalsize)
+ die("Mem Reserve structure offset exceeds total size\n");
+
if (off_dt >= totalsize)
die("DT structure offset exceeds total size\n");
@@ -756,12 +836,16 @@
flags |= FTF_FULLPATH | FTF_NAMEPROPS | FTF_VARALIGN;
}
+ inbuf_init(&memresvbuf,
+ blob + off_mem_rsvmap, blob + totalsize);
inbuf_init(&dtbuf, blob + off_dt, blob + totalsize);
inbuf_init(&strbuf, blob + off_str, blob + totalsize);
if (version >= 3)
strbuf.limit = strbuf.base + size_str;
+ *mem_reserve_data = flat_read_mem_reserve(&memresvbuf);
+
val = flat_read_word(&dtbuf);
if (val != OF_DT_BEGIN_NODE)
Index: fstree.c
===================================================================
--- abbe76bc79348c0896908c8548d51bdfa5f76500/fstree.c (mode:100644)
+++ uncommitted/fstree.c (mode:100644)
@@ -80,7 +80,7 @@
return tree;
}
-struct node *dt_from_fs(char *dirname)
+struct node *dt_from_fs(char *dirname, struct data *mem_reserve_data)
{
struct node *tree;
Index: treesource.c
===================================================================
--- abbe76bc79348c0896908c8548d51bdfa5f76500/treesource.c (mode:100644)
+++ uncommitted/treesource.c (mode:100644)
@@ -20,13 +20,30 @@
#include "dtc.h"
-struct node *device_tree;
-
extern FILE *yyin;
extern int yyparse(void);
+extern void yyerror(char const *);
+
+struct node *device_tree;
+struct data *mem_reserve_data_ptr;
-struct node *dt_from_source(FILE *f)
+
+void build_mem_reserve(struct data d)
{
+ /*
+ * FIXME: Should reconcile the -R parameter here now?
+ */
+ *mem_reserve_data_ptr = d;
+ if (d.len % 16 != 0) {
+ yyerror("Memory Reserve entries are <u64 addr, u64 size>\n");
+ }
+}
+
+
+struct node *dt_from_source(FILE *f, struct data *mem_reserve_data)
+{
+ mem_reserve_data_ptr = mem_reserve_data;
+
yyin = f;
if (yyparse() != 0)
return NULL;
@@ -75,7 +92,8 @@
}
-void write_tree_source(FILE *f, struct node *tree, int level)
+
+void write_tree_source_node(FILE *f, struct node *tree, int level)
{
struct property *prop;
struct node *child;
@@ -133,8 +151,40 @@
}
for_each_child(tree, child) {
fprintf(f, "\n");
- write_tree_source(f, child, level+1);
+ write_tree_source_node(f, child, level+1);
}
write_prefix(f, level);
fprintf(f, "};\n");
}
+
+
+void write_tree_source(FILE *f, struct node *tree,
+ struct data *mem_reserve_data)
+{
+ int i;
+ int ncells;
+ cell_t *cp;
+
+ if (mem_reserve_data->len > 0) {
+ fprintf(f, "memreserve =\t<\n");
+ cp = (cell_t *)mem_reserve_data->val;
+ ncells = mem_reserve_data->len / sizeof(cell_t);
+ for (i = 0; i < ncells; i++) {
+ if (i % 4 == 0) {
+ fprintf(f, "\t\t\t");
+ }
+ fprintf(f, "%x", be32_to_cpu(*cp++));
+ if (i % 4 == 1) {
+ fprintf(f, " ");
+ } else if (i % 4 == 3) {
+ fprintf(f, "\n");
+ } else {
+ fprintf(f, " ");
+ }
+ }
+ fprintf(f, "\t\t>\n\n");
+ }
+
+ write_tree_source_node(f, tree, 0);
+}
+
^ permalink raw reply
* Re: mpc8xx and ld.so problem
From: Yuli Barcohen @ 2005-07-10 7:31 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Joakim Tjernlund, Jason McMullan, linux-ppc-embedded
In-Reply-To: <20050708003639.GA5174@dmt.cnet>
>>>>> Marcelo Tosatti writes:
Yuli> [...deleted...]
Jason> Ha. Funny. The glibc powerpc maintainer doesn't want any
Jason> embedded fixes in the mainline. Last I checked, that was for
Jason> 'the tools vendors' to fix.
Jason> "We won't work around processor bugs" is their philosophy.
Yuli> [...deleted...]
Yuli> I investigated the problem a bit when I had trouble with a
Yuli> self-compiled glibc a year or so ago. IIRC, I found bug in the
Yuli> memset code, not in the chip. The code was just wrong for
Yuli> cache line sizes not equal to 32. So memset.S is good for 60x
Yuli> series (PQII included) but for 8xx it fails.
Marcelo> I suppose you didnt actually use dcbz for userspace memset
Marcelo> on 8xx?
Standard glibc did. After the fix, it doesn't do it any more on our
systems.
Yuli> We use dcbX instructions in some kernel drivers and since we
Yuli> never had any problems with those drivers I'm a bit surprised
Yuli> to hear that all 8xx chips have got that bug.
Marcelo> The problem is that the DAR register is correctly unset (it
Marcelo> comes as NULL IIRC) on pagefaults for the dcbz
Marcelo> instruction. The dcbz instructions you issue are probably
Marcelo> always works on kernel addresses whose pagetables are
Marcelo> present?
It's not dcbz, it's dcbi/dcbf. And yes, they work on kernel addresses. I
never investigated if the page tables are present or not because there
were no problems.
Marcelo> Joakim has developed a workaround for the
Marcelo> problem... although I promised him several times to test it
Marcelo> I never managed to get dcbz to work on the kernel copying
Marcelo> functions. :(
[...patch deleted...]
Well, if I manage to find time, I'll try it. No timetables though. I'm
not sure if using dcbz in user-space memset is such a great
optimisation. It well can be an example of over-engineering.
--
========================================================================
Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader
yuli@arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel
========================================================================
^ permalink raw reply
* [PATCH 6/82] remove linux/version.h include from arch/ppc
From: Olaf Hering @ 2005-07-10 19:35 UTC (permalink / raw)
To: Andrew Morton, linux-kernel; +Cc: linuxppc-dev
In-Reply-To: <20050710193508.0.PmFpst2252.2247.olh@nectarine.suse.de>
changing CONFIG_LOCALVERSION rebuilds too much, for no appearent reason.
use system_utsname for CONFIG_BOOTX_TEXT welcome message
Signed-off-by: Olaf Hering <olh@suse.de>
arch/ppc/syslib/btext.c | 6 ++++--
arch/ppc/syslib/prom.c | 1 -
arch/ppc/syslib/prom_init.c | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.13-rc2-mm1/arch/ppc/syslib/btext.c
===================================================================
--- linux-2.6.13-rc2-mm1.orig/arch/ppc/syslib/btext.c
+++ linux-2.6.13-rc2-mm1/arch/ppc/syslib/btext.c
@@ -7,7 +7,7 @@
#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/init.h>
-#include <linux/version.h>
+#include <linux/utsname.h>
#include <asm/sections.h>
#include <asm/bootx.h>
@@ -81,7 +81,9 @@ btext_welcome(void)
unsigned long pvr;
boot_infos_t* bi = &disp_bi;
- btext_drawstring("Welcome to Linux, kernel " UTS_RELEASE "n");
+ btext_drawstring("Welcome to Linux, kernel ");
+ btext_drawstring(system_utsname.version);
+ btext_drawstring("n");
btext_drawstring("nlinked at : 0x");
btext_drawhex(KERNELBASE);
btext_drawstring("nframe buffer at : 0x");
Index: linux-2.6.13-rc2-mm1/arch/ppc/syslib/prom.c
===================================================================
--- linux-2.6.13-rc2-mm1.orig/arch/ppc/syslib/prom.c
+++ linux-2.6.13-rc2-mm1/arch/ppc/syslib/prom.c
@@ -13,7 +13,6 @@
#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/init.h>
-#include <linux/version.h>
#include <linux/threads.h>
#include <linux/spinlock.h>
#include <linux/ioport.h>
Index: linux-2.6.13-rc2-mm1/arch/ppc/syslib/prom_init.c
===================================================================
--- linux-2.6.13-rc2-mm1.orig/arch/ppc/syslib/prom_init.c
+++ linux-2.6.13-rc2-mm1/arch/ppc/syslib/prom_init.c
@@ -9,7 +9,6 @@
#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/init.h>
-#include <linux/version.h>
#include <linux/threads.h>
#include <linux/spinlock.h>
#include <linux/ioport.h>
^ 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