* Re: [PATCH] Add modalias for pmac network drivers
From: Benjamin Herrenschmidt @ 2005-10-10 22:16 UTC (permalink / raw)
To: Olaf Hering; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20051010201117.GB14317@suse.de>
On Mon, 2005-10-10 at 22:11 +0200, Olaf Hering wrote:
> mesh, mac53c94 and airport already have an entry.
> Add the network drivers for pmac.
>
> Signed-off-by: Olaf Hering <olh@suse.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> drivers/net/bmac.c | 1 +
> drivers/net/mace.c | 1 +
>
> Index: linux-2.6.12/drivers/net/bmac.c
> ===================================================================
> --- linux-2.6.12.orig/drivers/net/bmac.c
> +++ linux-2.6.12/drivers/net/bmac.c
> @@ -1658,6 +1658,7 @@ static struct of_device_id bmac_match[]
> },
> {},
> };
> +MODULE_DEVICE_TABLE (of, bmac_match);
>
> static struct macio_driver bmac_driver =
> {
> Index: linux-2.6.12/drivers/net/mace.c
> ===================================================================
> --- linux-2.6.12.orig/drivers/net/mace.c
> +++ linux-2.6.12/drivers/net/mace.c
> @@ -1016,6 +1016,7 @@ static struct of_device_id mace_match[]
> },
> {},
> };
> +MODULE_DEVICE_TABLE (of, mace_match);
>
> static struct macio_driver mace_driver =
> {
>
^ permalink raw reply
* Re: [PATCH] Add modalias to macio sysfs attributes
From: Benjamin Herrenschmidt @ 2005-10-10 22:17 UTC (permalink / raw)
To: Olaf Hering; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20051010200739.GA14317@suse.de>
On Mon, 2005-10-10 at 22:07 +0200, Olaf Hering wrote:
> Provide a "compatible" entry in /sys/bus/macio/devices/*/
> This can be used to load drivers via the modules.alias file.
>
> Author: <schab@suse.de>
> Signed-off-by: Olaf Hering <olh@suse.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> --- linux-2.6.13-rc7/drivers/macintosh/macio_sysfs.c.~1~ 2005-08-26 16:32:13.000000000 +0200
> +++ linux-2.6.13-rc7/drivers/macintosh/macio_sysfs.c 2005-08-27 11:58:47.000000000 +0200
> @@ -39,6 +39,31 @@ compatible_show (struct device *dev, str
> return length;
> }
>
> +static ssize_t modalias_show (struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct of_device *of;
> + char *compat;
> + int cplen;
> + int length;
> +
> + of = &to_macio_device (dev)->ofdev;
> + compat = (char *) get_property (of->node, "compatible", &cplen);
> + if (!compat) compat = "", cplen = 1;
> + length = sprintf (buf, "of:N%sT%s", of->node->name, of->node->type);
> + buf += length;
> + while (cplen > 0) {
> + int l;
> + length += sprintf (buf, "C%s", compat);
> + buf += length;
> + l = strlen (compat) + 1;
> + compat += l;
> + cplen -= l;
> + }
> +
> + return length;
> +}
> +
> macio_config_of_attr (name, "%s\n");
> macio_config_of_attr (type, "%s\n");
>
> @@ -46,5 +71,6 @@ struct device_attribute macio_dev_attrs[
> __ATTR_RO(name),
> __ATTR_RO(type),
> __ATTR_RO(compatible),
> + __ATTR_RO(modalias),
> __ATTR_NULL
> };
^ permalink raw reply
* boot-time partitions and bootargs for 2.6.14
From: Dmytro Bablinyuk @ 2005-10-10 23:05 UTC (permalink / raw)
To: linuxppc-embedded
I have 2.6.14 kernel and the following partitions (defined in U-Boot 1.1.4)
mtdparts=0:1024k(Linux),4096k(root),2048k(Unused),512k(U-Boot),512()
And I tried different bootargs
bootargs=console=ttyCPM0,115200 root=/dev/mtdblock1 rw rootfstype=jffs2
And I tried
bootargs console=ttyCPM0,115200 root=31:01 rw rootfstype=jffs2
I still have
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(31,1)
I tried different minor numbers but result the same. Does anybody know
what type of root param I should use for 2.6.14 - mtdblock1 or 31:01?
Can anybody suggest me what I missed? One of the reasons I see that I
may have a corrupted root.
Thank you
Dimitry
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Wolfgang Denk @ 2005-10-10 23:46 UTC (permalink / raw)
To: Dmytro Bablinyuk; +Cc: linuxppc-embedded
In-Reply-To: <434AF39D.8050709@rftechnology.com.au>
In message <434AF39D.8050709@rftechnology.com.au> you wrote:
> I have 2.6.14 kernel and the following partitions (defined in U-Boot 1.1.4)
> mtdparts=0:1024k(Linux),4096k(root),2048k(Unused),512k(U-Boot),512()
Are you sure that your flash device name in Linux is just "0" ? Which
board is this?
> And I tried different bootargs
> bootargs=console=ttyCPM0,115200 root=/dev/mtdblock1 rw rootfstype=jffs2
...
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(31,1)
>
> I tried different minor numbers but result the same. Does anybody know
> what type of root param I should use for 2.6.14 - mtdblock1 or 31:01?
> Can anybody suggest me what I missed? One of the reasons I see that I
> may have a corrupted root.
The kernel boot messages contain a section about MTD partitions
found, something like this:
...
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 4 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
PPC 4xx OCP EMAC driver, version 3.53
mal0: initialized, 4 TX channels, 2 RX channels
eth0: emac0, MAC 00:50:c2:1e:af:fe
eth0: found Generic MII PHY (0x00)
eth1: emac1, MAC 00:50:c2:1e:af:fd
eth1: found Generic MII PHY (0x01)
PPChameleon: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
PPChameleon: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
===> Creating 3 MTD partitions on "PPChameleon":
===> 0x00000000-0x00180000 : "linux"
===> 0x00180000-0x003c0000 : "user"
===> 0x003c0000-0x00400000 : "u-boot"
...
Can you see these messages on your system? Is the flash name really
"0"? Are the partitions correct?
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
Technology is dominated by those who manage what they do not under-
stand.
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Dmytro Bablinyuk @ 2005-10-11 0:04 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20051010234614.1FE2A353D84@atlas.denx.de>
> ===> Creating 3 MTD partitions on "PPChameleon":
> ===> 0x00000000-0x00180000 : "linux"
> ===> 0x00180000-0x003c0000 : "user"
> ===> 0x003c0000-0x00400000 : "u-boot"
> ...
>
> Can you see these messages on your system? Is the flash name really
> "0"? Are the partitions correct?
Yes, these partitions are correct (well, I think)
Bank # 1: Sharp 28F016SC (16 Mbit, 32 x 64K)
Size: 8 MB in 32 Sectors
Sector Start Addresses:
FF800000 FF840000 FF880000 FF8C0000 FF900000
FF940000 FF980000 FF9C0000 FFA00000 FFA40000
FFA80000 FFAC0000 FFB00000 FFB40000 FFB80000
FFBC0000 FFC00000 FFC40000 FFC80000 FFCC0000
FFD00000 FFD40000 FFD80000 FFDC0000 FFE00000
FFE40000 FFE80000 FFEC0000 FFF00000 (RO) FFF40000 (RO)
FFF80000 FFFC0000
FF800000 - FF8C0000 - Linux (4 sect, 1024k)
FF900000 - FFCC0000 - Root (16 sect, 4096k)
FFD00000 - FFEC0000 - Unused (8 sect, 2048k)
FFF00000 - FFF40000 - U-boot (2 sect, 512k)
FFF80000 - FFFC0000 - Rest (2 sect, 512k)
No, I cannot see these messages. Here what I see
...
Kernel command line: console=ttyCPM0,115200 root=31:01 rw rootfstype=jffs2
PID hash table entries: 512 (order: 9, 8192 bytes)
Warning: real time clock seems stuck!
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 62848k available (1568k kernel code, 396k data, 88k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
JFFS2: default compression mode: priority
fuse init (API version 7.2)
Initializing Cryptographic API
Generic RTC Driver v1.07
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xf0011a00 (irq = 40) is a CPM UART
ttyCPM1 at MMIO 0xf0011a20 (irq = 41) is a CPM UART
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
...
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(31,1)
<0>Rebooting in 180 seconds..
I am trying to debug right now using gdb and BDI and I found out that
error occurs when I try to
(gdb) c
Continuing.
Breakpoint 1, do_mount (dev_name=0xc03c1000 "/dev/root",
dir_name=0xc03c0000 "/root", type_page=0xc03bf000 "jffs2", flags=0x8000,
data_page=0x0) at fs/namespace.c:1022
long do_mount(char * dev_name, char * dir_name, char *type_page,
unsigned long flags, void *data_page)
{
struct nameidata nd;
int retval = 0;
int mnt_flags = 0;
/* Discard magic */
if ((flags & MS_MGC_MSK) == MS_MGC_VAL)
flags &= ~MS_MGC_MSK;
/* Basic sanity checks */
if (!dir_name || !*dir_name || !memchr(dir_name, 0, PAGE_SIZE))
return -EINVAL;
if (dev_name && !memchr(dev_name, 0, PAGE_SIZE))
return -EINVAL; <---- ERROR
^^^^^^^^^^^^^^^^
Do you know what this might be?
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Dmytro Bablinyuk @ 2005-10-11 0:13 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20051010234614.1FE2A353D84@atlas.denx.de>
> Are you sure that your flash device name in Linux is just "0" ?
I think you are right. I missed the point.
=> flinfo
Bank # 1: Sharp 28F016SC (16 Mbit, 32 x 64K)
Size: 8 MB in 32 Sectors
Sector Start Addresses:
FF800000 FF840000 FF880000 FF8C0000 FF900000
FF940000 FF980000 FF9C0000 FFA00000 FFA40000
FFA80000 FFAC0000 FFB00000 FFB40000 FFB80000
FFBC0000 FFC00000 FFC40000 FFC80000 FFCC0000
FFD00000 FFD40000 FFD80000 FFDC0000 FFE00000
FFE40000 FFE80000 FFEC0000 FFF00000 (RO) FFF40000 (RO)
FFF80000 FFFC0000
So I have
mtdparts=1:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
But problem remains...
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(31,1)
^ permalink raw reply
* Posting delays
From: Stephen Rothwell @ 2005-10-11 0:53 UTC (permalink / raw)
To: ppc64-dev; +Cc: linuxppc-dev, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
Hi all,
Just a note to let you all know that I have changed the list manager
configuration so that posts from email addresses that are not subscribed
to the list will be held until looked at by one of the admins. This may
cause some delay in peoples postings, sorry. If people are happy with
some (hopefully short) delay, then nothing needs to change - whenever what
looks like a reasonable post is held, I am adding the senders address to
those whom will not be held again.
--
Cheers,
Stephen Rothwell sfr@ozlabs.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Dmytro Bablinyuk @ 2005-10-11 1:02 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20051010234614.1FE2A353D84@atlas.denx.de>
Sorry for 3d email. The failed line I sent was incorrect - the problem
is that debugger jumps from line to line on every step.
I have added -fno-schedule-insns -fno-schedule-insns2 into kernel Makefile:
CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
-ffreestanding \
-fno-schedule-insns -fno-schedule-insns2
But it still jumping. What options shall I add in order to prevent
debugger jumping while debugging kernel?
Sorry, for slight off-topic.
Thank you
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Robin Gilks @ 2005-10-11 1:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <434B03A2.8060608@rftechnology.com.au>
Dmytro Bablinyuk wrote:
>> Are you sure that your flash device name in Linux is just "0" ?
>
> I think you are right. I missed the point.
>
> => flinfo
>
> Bank # 1: Sharp 28F016SC (16 Mbit, 32 x 64K)
> Size: 8 MB in 32 Sectors
> Sector Start Addresses:
> FF800000 FF840000 FF880000 FF8C0000 FF900000
> FF940000 FF980000 FF9C0000 FFA00000 FFA40000
> FFA80000 FFAC0000 FFB00000 FFB40000 FFB80000
> FFBC0000 FFC00000 FFC40000 FFC80000 FFCC0000
> FFD00000 FFD40000 FFD80000 FFDC0000 FFE00000
> FFE40000 FFE80000 FFEC0000 FFF00000 (RO) FFF40000 (RO)
> FFF80000 FFFC0000
>
> So I have
> mtdparts=1:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
>
> But problem remains...
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(31,1)
Are you using physmap as the means of creating the mtd devices? If so
there is a bug in many variants of the kernel that defines the map
structure as follows:
struct map_info physmap_map = {
.name = "Physically mapped flash",
.size = WINDOW_SIZE,
.buswidth = BUSWIDTH,
.phys = WINDOW_ADDR,
};
Note that the name has embedded spaces - something I've never managed to
get U-Boot to pass across on the kernel command line (I'm sure Wolfgang
will correct me if I'm wrong here!!). The '1' in your
"mtdparts=1:1024k(Linux)" should match the name of this map. In this
case the code needs to be changed to NOT have spaces in it (and perhaps
a more user friendly name) and the kernel config values for WINDOW_SIZE,
BUSWIDTH and WINDOW_ADDR set correctly. That way you'd end up with
something like:
struct map_info physmap_map = {
.name = "fred",
.size = WINDOW_SIZE,
.buswidth = BUSWIDTH,
.phys = WINDOW_ADDR,
};
and a command line something like:
mtdparts=fred:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
I'd also suggest that you mount a known good fs using NFS (if you have
ethernet on your target) and then try manually mounting the flash fs -
that will check out its structure (endian-ness?) and the jffs2 drivers
on your target.
--
Robin Gilks
Senior Design Engineer Phone: (+64)(3) 357 1569
Tait Electronics Fax : (+64)(3) 359 4632
PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz
New Zealand
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Dmytro Bablinyuk @ 2005-10-11 3:10 UTC (permalink / raw)
To: Robin Gilks; +Cc: linuxppc-embedded
In-Reply-To: <434B12C5.2050809@tait.co.nz>
> struct map_info physmap_map = {
> .name = "fred",
> .size = WINDOW_SIZE,
> .buswidth = BUSWIDTH,
> .phys = WINDOW_ADDR,
> };
> and a command line something like:
> mtdparts=fred:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
Thank you Robin,
Yes, I have 'working' jffs2.img (original from board).
I checked for spaces - it looks ok. It has 'physically_mapped_flash'.
What I think is the problem with no discovering the flash - it should
call 'add_mtd_partitions' in 'mtdpart.c' after finding the chip but it
is not calling it and looks like because it's not finding the flash
(8272ADS, Sharp 28F016SC).
I have:
...
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
$Id: ftl.c,v 1.55 2005/01/17 13:47:21 hvr Exp $
physmap flash device: 800000 at ff800000
eth0: FCC ENET Version 0.3, 00:04:9f:91:22:33
...
And probably I should expect something like this:
...
PPChameleon: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
PPChameleon: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
===> Creating 3 MTD partitions on "PPChameleon":
===> 0x00000000-0x00180000 : "linux"
===> 0x00180000-0x003c0000 : "user"
===> 0x003c0000-0x00400000 : "u-boot"
I may be missing something, from my understanding it should find the
chip before mounting root. And it looks like it couldn't find the chip.
Again, I may be wrong and very likely I missed something.
But I will really appreciate if somebody can help me with this.
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Robin Gilks @ 2005-10-11 3:24 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <434B2D23.2020208@rftechnology.com.au>
Dmytro Bablinyuk wrote:
>> struct map_info physmap_map = {
>> .name = "fred",
>> .size = WINDOW_SIZE,
>> .buswidth = BUSWIDTH,
>> .phys = WINDOW_ADDR,
>> };
>> and a command line something like:
>> mtdparts=fred:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
>
>
> Thank you Robin,
>
> Yes, I have 'working' jffs2.img (original from board).
> I checked for spaces - it looks ok. It has 'physically_mapped_flash'.
[snip]
In that case you should have a u-boot line of
mtdparts=physically_mapped_flash:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
not of
mtdparts=1:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
The name is significant (I think!!)
--
Robin Gilks
Senior Design Engineer Phone: (+64)(3) 357 1569
Tait Electronics Fax : (+64)(3) 359 4632
PO Box 1645 Christchurch Email : robin.gilks@tait.co.nz
New Zealand
=======================================================================
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================
^ permalink raw reply
* What can I do to port JVM on MPC
From: 이준석\(peter\) @ 2005-10-11 3:07 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 239 bytes --]
Hi everyone,
I'm running linux 2.4.22 on my MPC8272ADS board using Metrowerks BSP
and I need JVM on it to go further in my project.
But it's very hard to find any clue for porting it.
Any advice or starting point?
Thanks.
peter
[-- Attachment #2: Type: text/html, Size: 874 bytes --]
^ permalink raw reply
* Re: Problem Regarding Ping in Linux kernel version 2.4.24
From: apoorv sangal @ 2005-10-11 6:27 UTC (permalink / raw)
To: Mark Chambers, Linuxppc-embedded
Cc: sibi_mathew, vikrant_basotra, apoorv sangal
In-Reply-To: <003d01c5cd97$34404470$0301a8c0@chuck2>
[-- Attachment #1: Type: text/plain, Size: 6390 bytes --]
Hi,
I am sending the output from the console of the boot sequence and ifconfig
command as following.
Please check the same and let me know where i am going wrong.
*******************************************************************************************************
## Total Size = 0x00088c6d = 560237 Bytes
## Start Addr = 0x02000000
=> bootm 02000000 ## Booting image at 02000000 ...
Image Name: 2.4.24 10thOCT3
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 560173 Bytes = 547 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 (satyam@pmcserver) (gcc version 3.2.2 20030217
(Yellow Dog Linux 3.0 3.2.2-2a_1)) #17 Mon Oct 10 15:41:43 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: 128148k available (948k kernel code, 368k 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: 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.
Inside Chr_dev_init
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
Pty initialisation is complete
eth0: FCC2 ENET Version 0.4, 00:10:EC:40:30:8C
Inside rd_init
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
pmc8260 flash map (size->0x2000000 mem->0xFC000000)
map->buswidth : 2
cfi_cmdset_0001: Erase suspend on write enabled
Using buffer write method
Creating 1 MTD partitions on "pmc8260 flash memory":
0x008c0000-0x00bc0000 : "JFFS2 partition"
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.
*****
VFS:test name = /dev/root
VFS:fs_name = jffs2
VFS:root name = 1f:00
****
jffs2_scan_inode_node(): Data CRC failed on node at 0x0003b1a8: Read
0xcd593a55, calculated 0x95474c25
jffs2_scan_inode_node(): CRC failed on node at 0x002aafc0: Read 0x00000001,
calculated 0x8ea9f6b8
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x002aafc8:
0x10e4 instead
Eep. Child "issue" (ino #127) of dir ino #4 doesn't exist!
VFS:tried fs_name = jffs2 err = 0
VFS: Mounted root (jffs2 filesystem) readonly.
Freeing unused kernel memory: 56k init 4k prep
init started: BusyBox v0.60.5 (2004.11.09-16:07+0000) multi-call
binarymount: Mounting /dev/ram0 on /tmp failed: Invalid argument
Starting networking: done.
Starting udhcp Client: Jan 1 00:00:02 insmod: insmod: net-pf-17: no module
by that name found done.
Starting thttpd: done.
Starting OpenSSH: done.
Starting SNMP Agent: done.
jffs2_read_inode() on nonexistent ino 127
(none) login: root
Password:
Jan 1 00:00:09 login[61]: root login on `ttyS0'
BusyBox v0.60.5 (2004.11.09-16:07+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
# ifconfig eth0 down
# ifconfig eth0 172.19.56.218 <http://172.19.56.218>
# ifconfig eth0 up
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:EC:40:30:8C
inet addr:172.19.56.218 <http://172.19.56.218>
Bcast:172.19.255.255<http://172.19.255.255>Mask:
255.255.0.0 <http://255.255.0.0>
UP BROADCAST RUNNING MULTICAST MTU:1500 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:1000
RX bytes:0 (0.0 iB) TX bytes:0 (0.0 iB)
Base address:0x8500
lo Link encap:Local Loopback
inet addr:127.0.0.1 <http://127.0.0.1> Mask:255.0.0.0 <http://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 127.0.0.1 <http://127.0.0.1>
PING 127.0.0.1 <http://127.0.0.1> (127.0.0.1 <http://127.0.0.1>): 56 data
bytes
64 bytes from 127.0.0.1 <http://127.0.0.1>: icmp_seq=0 ttl=64 time=0.6 ms
64 bytes from 127.0.0.1 <http://127.0.0.1>: icmp_seq=1 ttl=64 time=0.2 ms
64 bytes from 127.0.0.1 <http://127.0.0.1>: icmp_seq=2 ttl=64 time=0.2 ms
64 bytes from 127.0.0.1 <http://127.0.0.1>: icmp_seq=3 ttl=64 time=0.2 ms
64 bytes from 127.0.0.1 <http://127.0.0.1>: icmp_seq=4 ttl=64 time=0.2 ms
--- 127.0.0.1 <http://127.0.0.1> ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.6 ms
#
# ping 172.19.59.101 <http://172.19.59.101>
PING 172.19.59.101 <http://172.19.59.101>
(172.19.59.101<http://172.19.59.101>):
56 data bytes
--- 172.19.59.101 <http://172.19.59.101> ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss
*******************************************************************************************************
Regards,
Apoorv Sangal.
On 10/10/05, Mark Chambers <markc@mail.com> wrote:
>
> Hi
> Thanks for the inputs... As per your suggestion I commented
> { mk_mii_write(MII_REG_CR, 0x1200), NULL }, /* autonegotiate */
> but it doesn't make any diffrence, still the ping doesn't worked.
> At Boot loader level (u-boot) Ping works fine,
> I think you need to provide more information, because there are many
> things
> that could be wrong. Attach the output of your console from the boot
> sequence,
> and include the output of an ifconfig command if you can.
> Mark Chambers
>
>
[-- Attachment #2: Type: text/html, Size: 8497 bytes --]
^ permalink raw reply
* RE: MPC5200,PSC in uart mode, receiving problem
From: Tomasz Prochownik @ 2005-10-11 6:41 UTC (permalink / raw)
To: achim.machura; +Cc: Linuxppc-Embedded (E-Mail)
Thanks Achim - your driver works fine.
t.
^ permalink raw reply
* Re: What Can I do to port JVM on MPC?
From: Mike Rapoport @ 2005-10-11 6:38 UTC (permalink / raw)
To: JunSeok Lee; +Cc: linuxppc-embedded
In-Reply-To: <003501c5cda1$4d52ade0$1801a8c0@PETER>
JunSeok Lee wrote:
> Hi everyone,
> I'm running linux 2.4.22 on my MPC8272ADS board using Metrowerks BSP
> and I need JVM on it to go further in my project.
> But it's very hard to find any clue for porting it.
> Any advice or starting point?
Take a look at http://www.blackdown.org/
--
Sincerely yours,
Mike Rapoport
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Dmytro Bablinyuk @ 2005-10-11 7:01 UTC (permalink / raw)
To: Robin Gilks; +Cc: linuxppc-embedded
In-Reply-To: <434B3072.1090008@tait.co.nz>
> In that case you should have a u-boot line of
>
> mtdparts=physically_mapped_flash:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
Yep, I set
mtdparts=phys_mapped_flash:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
I got flash discovery working and I set 'CONFIG_MTD_CMDLINE_PARTS=y' but
kernel is not even attempting to parse 'mtdparts'. It's not calling
'parse_cmdline_partitions' function. Even if I got wrong 'mtd-id', it
still should attempt to parse 'mtdparts' (well, at least I think so).
Here is output:
Kernel command line: console=ttyCPM0,115200 root=31:01 rw rootfstype=jffs2
PID hash table entries: 512 (order: 9, 8192 bytes)
Warning: real time clock seems stuck!
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 62720k available (1572k kernel code, 408k data, 96k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
JFFS2: default compression mode: priority
fuse init (API version 7.2)
Initializing Cryptographic API
Generic RTC Driver v1.07
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xf0011a00 (irq = 40) is a CPM UART
ttyCPM1 at MMIO 0xf0011a20 (irq = 41) is a CPM UART
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
loop: loaded (max 8 devices)
physmap flash device: 800000 at ff800000
Found: Intel I28F016S3
phys_mapped_flash: Found 4 x8 devices at 0x0 in 32-bit bank
RedBoot partition parsing not available
eth0: FCC ENET Version 0.3, 00:04:9f:91:22:33
mii_reg: 600eb881
eth0: Phy @ 0x0, type Davicom DM9161E (0x0181b881)
eth1: FCC ENET Version 0.3, 00:04:9f:51:22:33
mii_reg: 618eb881
eth1: Phy @ 0x3, type Davicom DM9161E (0x0181b881)
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Does anybody has any idea of why parsing of 'mtdparts' is not even started?
I have enabled debug macro:
/* debug macro */
#if 1
#define dbg(x) do { printk("DEBUG-CMDLINE-PART: "); printk x; } while(0)
#else
#define dbg(x)
#endif
Thank you
^ permalink raw reply
* RE: MPC5200,PSC in uart mode, receiving problem
From: Derycke, Johan @ 2005-10-11 6:55 UTC (permalink / raw)
To: achim.machura; +Cc: Linuxppc-Embedded (E-Mail)
[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]
Hi Achim,
I also have the problem with uart blocking.
Could you please send me your changes to the driver so I can see if it works
for me.
Best regards,
Johan
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Achim Machura
Sent: maandag 10 oktober 2005 15:14
To: 'Tomasz Prochownik'
Cc: Linuxppc-Embedded (E-Mail)
Subject: AW: MPC5200,PSC in uart mode, receiving problem
Hello Tomasz
> blocks (there is no response in the console).
perhaps we have the same problem a few times ago.
When we connect devices on ttySx which have wrong level on the lines the
uart stay in break mode.
I have made some fixes on the psc-driver. With these fixes the uart works,
but i don't know how efficient.
(clear breakmode and clear buffer)
If you want, i can send the code
best regards
achim
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
- - - - - - - DISCLAIMER- - - - - - - -
Unless indicated otherwise, the information contained in this message is
privileged and confidential, and is intended only for the use of the
addressee(s) named above and others who have been specifically authorized to
receive it. If you are not the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this message and/or
attachments is strictly prohibited. The company accepts no liability for any
damage caused by any virus transmitted by this email. Furthermore, the
company does not warrant a proper and complete transmission of this
information, nor does it accept liability for any delays. If you have
received this message in error, please contact the sender and delete the
message. Thank you.
[-- Attachment #2: Type: text/html, Size: 3044 bytes --]
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Wolfgang Denk @ 2005-10-11 7:14 UTC (permalink / raw)
To: Robin Gilks; +Cc: linuxppc-embedded
In-Reply-To: <434B12C5.2050809@tait.co.nz>
In message <434B12C5.2050809@tait.co.nz> you wrote:
>
> struct map_info physmap_map = {
> .name = "Physically mapped flash",
...
> Note that the name has embedded spaces - something I've never managed to
> get U-Boot to pass across on the kernel command line (I'm sure Wolfgang
> will correct me if I'm wrong here!!). The '1' in your
You are 100% correct. When using command line partitioning, the .name
entry must not contain spaces (no matter which boot loader you use -
this is a problem with the Linux kernel's argument parsing).
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
Quote from a recent meeting: "We are going to continue having these
meetings everyday until I find out why no work is getting done."
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Wolfgang Denk @ 2005-10-11 7:17 UTC (permalink / raw)
To: Dmytro Bablinyuk; +Cc: linuxppc-embedded
In-Reply-To: <434B635D.1000509@rftechnology.com.au>
In message <434B635D.1000509@rftechnology.com.au> you wrote:
>
> > mtdparts=physically_mapped_flash:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
>
> Yep, I set
> mtdparts=phys_mapped_flash:1024k(Linux),4096k(FS),2048k(Unused),512k(U-Boot),512()
You may set it, but do you pass it as part of the boot arguments?
> Here is output:
>
> Kernel command line: console=ttyCPM0,115200 root=31:01 rw rootfstype=jffs2
> PID hash table entries: 512 (order: 9, 8192 bytes)
No, you don't. [Do you understand now why complete information is
essential? If you had provided the boot log with the first posting we
would not have wasted our time looking for the wrong things.]
Make sure to add the mtdparts=... stuff to your bootargs!
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
Even if you can deceive people about a product through misleading
statements, sooner or later the product will speak for itself.
- Hajime Karatsu
^ permalink raw reply
* Re: MPC5200,PSC in uart mode, receiving problem
From: Wolfgang Denk @ 2005-10-11 7:18 UTC (permalink / raw)
To: achim.machura, Linuxppc-Embedded (E-Mail)
In-Reply-To: <81A66F72DCACD511B0600002A551BFCB08EE8AD4@kuumex05.barco.com>
In message <81A66F72DCACD511B0600002A551BFCB08EE8AD4@kuumex05.barco.com> you wrote:
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
Even better, post a patch here on the list so we all can benefit.
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 only time the world beats a path to your door is when you are in
the bathroom.
^ permalink raw reply
* Re: boot-time partitions and bootargs for 2.6.14
From: Dmytro Bablinyuk @ 2005-10-11 7:33 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20051011071754.8F73D353ADC@atlas.denx.de>
>
> Make sure to add the mtdparts=... stuff to your bootargs!
>
Yep, thank you all. Indeed I missed it.
I will be more careful next time.
Thank you again!
^ permalink raw reply
* Re: [PATCH] powerpc: zero out BSS for all platforms
From: Benjamin Herrenschmidt @ 2005-10-11 7:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <Pine.LNX.4.61.0510101449420.1572@nylon.am.freescale.net>
On Mon, 2005-10-10 at 14:51 -0500, Kumar Gala wrote:
> We need to ensure that the BSS is zeroed out for all platforms.
> Currently only prom_init.c was clearlying out the BSS which only works
> for PPC_OF platforms.
>
> Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
You need to make absolutely certain that we have not written anything to
the bss yet though... Is that the case ? I usually prefer doing the
zero'ing in assembly :)
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: zero out BSS for all platforms
From: Geert Uytterhoeven @ 2005-10-11 7:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linux/PPC Development, linuxppc64-dev
In-Reply-To: <Pine.LNX.4.61.0510101449420.1572@nylon.am.freescale.net>
On Mon, 10 Oct 2005, Kumar Gala wrote:
> We need to ensure that the BSS is zeroed out for all platforms.
> Currently only prom_init.c was clearlying out the BSS which only works
> for PPC_OF platforms.
>
> Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
>
> ---
> commit 56381a9f0765ba3ffa5f21a4cdcb93ac0279eeea
> tree 9f0f353b0776129626082a46b578d637fb79dad1
> parent dfc32a358c961c3fbfa94942ecb06da2e895ffe7
> author Kumar K. Gala <kumar.gala@freescale.com> Mon, 10 Oct 2005 14:48:36 -0500
> committer Kumar K. Gala <kumar.gala@freescale.com> Mon, 10 Oct 2005 14:48:36 -0500
>
> arch/powerpc/kernel/setup.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/setup.c b/arch/powerpc/kernel/setup.c
> --- a/arch/powerpc/kernel/setup.c
> +++ b/arch/powerpc/kernel/setup.c
> @@ -293,6 +293,10 @@ unsigned long __init early_init(unsigned
>
> reloc_got2(offset);
>
> + /* First zero the BSS -- use memset, some arches don't have
^^^^^^
> + * caches on yet */
> + memset_io(PTRRELOC(&__bss_start), 0, _end - __bss_start);
^^^^^^^^^
The comment is not in sync with the code.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: MPC8xx slave USB driver
From: Alexey Dyatchkov @ 2005-10-11 7:48 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
In-Reply-To: <20051010183502.DC809353CD8@atlas.denx.de>
I believe, it was taken from the development tree. Actually, I joined =
this
project already after the linux was tuned for the board, it was about 3 =
or 4
years ago.
Alexey
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]=20
Sent: Monday, October 10, 2005 8:35 PM
To: Alexey Dyatchkov
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: MPC8xx slave USB driver=20
In message <003101c5cd7a$e479aa10$0100000a@Omerxp> you wrote:
>=20
> We are using slightly modified Denx linux 2.4.12 on our board =
(modified
> RPXLITE)
We never released such a kernel version.
Best regards,
Wolfgang Denk
--=20
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Often it is fatal to live too long. - Racine
^ permalink raw reply
* AW: MPC5200,PSC in uart mode, receiving problem
From: Achim Machura @ 2005-10-11 8:10 UTC (permalink / raw)
To: 'Wolfgang Denk'; +Cc: Linuxppc-Embedded (E-Mail)
In-Reply-To: <20051011071841.6C0FE353ADC@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 108 bytes --]
Here the patch
> Even better, post a patch here on the list so we all can benefit.
Best regards,
Achim
[-- Attachment #2: patch_linuxppc_2_4_develLABEL_2004_04_30_1320_psc --]
[-- Type: application/octet-stream, Size: 7506 bytes --]
Index: psc.c
===================================================================
--- psc.c (.../kernel/linux/arch/ppc/5xxx_io/psc.c) (Revision 777)
+++ psc.c (.../firmware/kernel/linux/arch/ppc/5xxx_io/psc.c) (Arbeitskopie)
@@ -29,6 +29,7 @@
#include <linux/serial.h>
#include <linux/serialP.h>
#include <linux/generic_serial.h>
+#include <linux/proc_fs.h>
#ifdef CONFIG_UBOOT
#include <asm/ppcboot.h>
#endif
@@ -37,7 +38,7 @@
* This driver can spew a whole lot of debugging output at you. If you
* need maximum performance, you should disable the DEBUG define.
*/
-#undef MPC5xxx_PSC_DEBUG
+#undef MPC5xxx_PSC_DEBUG
#ifdef MPC5xxx_PSC_DEBUG
#define MPC5xxx_PSC_DEBUG_OPEN 0x00000001
@@ -55,6 +56,7 @@
#define MPC5xxx_PSC_DEBUG_FIRMWARE 0x00001000
#define MPC5xxx_PSC_DEBUG_MEMTEST 0x00002000
#define MPC5xxx_PSC_DEBUG_THROTTLE 0x00004000
+#define MPC5xxx_PSC_DEBUG_CLEARERR 0x00008000
#define MPC5xxx_PSC_DEBUG_ALL 0xffffffff
int rs_debug = MPC5xxx_PSC_DEBUG_ALL & ~MPC5xxx_PSC_DEBUG_TRANSMIT;
@@ -150,13 +152,23 @@
int rs_refcount;
int rs_initialized = 0;
+
/*
+ * proc stuff
+ */
+static int sio_read_info(char * buf, char ** start, off_t offset, int count, int *eof, void * data );
+static int sio_clear_err(struct file *file, const char *buffer, unsigned long count, void *data);
+static struct proc_dir_entry *pProcEntry = NULL;
+
+
+void clear_err(struct mpc5xxx_psc * psc);
+/*
* ----------------------------------------------------------------------
*
* Here starts the interrupt handling routines. All of the following
* subroutines are declared as inline and are folded into
* rs_interrupt(). They were separated out for readability's sake.
- *
+ *MPC5xxx_PSC_DEBUG_RECEIVE
* Note: rs_interrupt() is a "fast" interrupt, which means that it
* runs with interrupts turned off. People who may want to modify
* rs_interrupt() should try to keep the interrupt handler as fast as
@@ -294,19 +306,36 @@
static void rs_interrupt(int irq, void *dev_id, struct pt_regs * regs)
{
- struct rs_port * port;
+ struct rs_port * port = (struct rs_port *)dev_id;
+ struct mpc5xxx_psc *psc = port->psc;
unsigned long flags;
+ u16 status;
spin_lock_irqsave(&mpc5xxx_serial_lock, flags);
- port = (struct rs_port *)dev_id;
+
rs_dprintk(MPC5xxx_PSC_DEBUG_INTERRUPTS,
"rs_interrupt (port %p)...", port);
+ if (!port || !port->gs.tty) {
+ printk( KERN_DEBUG"%s(%d): port=%p tty=%p\n", __FUNCTION__, __LINE__,
+ port, port?port->gs.tty:NULL );
+ goto out;
+ }
+
+ status = in_be16(&psc->mpc5xxx_psc_status);
+ /* RB-Bit is set ? */
+ if(status & MPC5xxx_PSC_SR_RB)
+ {
+ clear_err(psc);
+ rs_dprintk(MPC5xxx_PSC_DEBUG_INTERRUPTS, "clear err in isr nach status %d.\n", status);
+ goto out;
+ }
+
receive_char(port);
transmit_char(port);
-
+out:
spin_unlock_irqrestore(&mpc5xxx_serial_lock, flags);
rs_dprintk(MPC5xxx_PSC_DEBUG_INTERRUPTS, "end.\n");
@@ -318,7 +347,7 @@
* interface with the generic_serial driver *
************************************************************************
*/
-static void rs_disable_tx_interrupts(void * ptr)
+static void rs_disable_tx_interrupts(void * ptr)
{
struct rs_port *port = ptr;
struct mpc5xxx_psc *psc = port->psc;
@@ -360,7 +389,7 @@
port->imr &= ~MPC5xxx_PSC_IMR_RXRDY;
out_be16(&psc->mpc5xxx_psc_imr, port->imr);
-
+ rs_dprintk(MPC5xxx_PSC_DEBUG_RECEIVE,"disable RxInt\n");
spin_unlock_irqrestore(&mpc5xxx_serial_lock, flags);
}
@@ -382,7 +411,7 @@
* while (in_be16(&psc->mpc5xxx_psc_status) & MPC5xxx_PSC_SR_RXRDY)
* in_8(&psc->mpc5xxx_psc_buffer_8);
*/
-
+ rs_dprintk(MPC5xxx_PSC_DEBUG_RECEIVE,"enable RxInt\n");
spin_unlock_irqrestore(&mpc5xxx_serial_lock, flags);
}
@@ -442,9 +471,15 @@
val32 |= (MPC5xxx_GPIO_PSC_CONFIG_UART_WITHOUT_CD << (4*line));
out_be32(&gpio->port_config, val32);
/* reset and enable PSC */
- out_8(&psc->command, MPC5xxx_PSC_RST_TX
- | MPC5xxx_PSC_RX_DISABLE | MPC5xxx_PSC_TX_ENABLE);
- out_8(&psc->command, MPC5xxx_PSC_RST_RX);
+// out_8(&psc->command, MPC5xxx_PSC_RST_TX
+// | MPC5xxx_PSC_RX_DISABLE | MPC5xxx_PSC_TX_ENABLE);
+// out_8(&psc->command, MPC5xxx_PSC_RST_RX);
+
+ /* neu */
+ /* reset and enable PSC */
+ out_8(&psc->command, MPC5xxx_PSC_RST_TX | MPC5xxx_PSC_TX_ENABLE);
+ //out_8(&psc->command, MPC5xxx_PSC_RST_RX);
+ /* ende neu*/
/* Set PSC operation mode as 'UART, DCD ignored' */
out_be32(&psc->sicr, 0x0);
/* Set clocking */
@@ -539,7 +574,7 @@
line = minor(tty->device) - tty->driver.minor_start;
rs_dprintk(MPC5xxx_PSC_DEBUG_OPEN,
- "%d: opening line %d. tty=%p ctty=%p)\n",
+ "%d: opening line %d. tty=%p ctty=%p)\n",
(int) current->pid, line, tty, current->tty);
if ((line < 0) || (line >= RS_TABLE_SIZE))
@@ -813,6 +848,7 @@
#endif
rs_dprintk(MPC5xxx_PSC_DEBUG_INIT, "psc base 0x%08lx\n",
(unsigned long)port->psc);
+ clear_err(port->psc);
port++;
}
@@ -878,6 +914,11 @@
return 1;
}
+ //pProcEntry = create_proc_read_entry("driver/sio0",0444,NULL,sio_read_info,NULL);
+ pProcEntry = create_proc_entry("driver/sio0",0444,NULL);
+ pProcEntry->read_proc = sio_read_info;
+ pProcEntry->write_proc = sio_clear_err;
+ pProcEntry->owner = THIS_MODULE;
func_exit();
return 0;
}
@@ -1094,3 +1135,61 @@
}
#endif
+static int sio_read_info(char * buf, char ** start, off_t offset, int count, int *eof, void * data )
+{
+
+ int len = 0;
+ struct mpc5xxx_psc *psc = (struct mpc5xxx_psc *) MPC5xxx_PSC1;
+ u16 nStat;
+
+ *eof = 1;
+ *buf = 0;
+ nStat = in_be16(&psc->mpc5xxx_psc_status);
+ if(count > len + 120)
+ {
+ len += sprintf(buf+len, "\n Status PSC 1: %d",nStat);
+ len += sprintf(buf+len, "\n RB: %d",(nStat & MPC5xxx_PSC_SR_RB) ? 1 : 0);
+ len += sprintf(buf+len, "\n FE: %d",(nStat & MPC5xxx_PSC_SR_FE) ? 1 : 0);
+ len += sprintf(buf+len, "\n PE: %d",(nStat & MPC5xxx_PSC_SR_PE) ? 1 : 0);
+ len += sprintf(buf+len, "\n OR: %d",(nStat & MPC5xxx_PSC_SR_OE) ? 1 : 0);
+ len += sprintf(buf+len, "\n TxEMP: %d",(nStat & MPC5xxx_PSC_SR_TXEMP) ? 1 : 0);
+ len += sprintf(buf+len, "\n TxRDY: %d",(nStat & MPC5xxx_PSC_SR_TXRDY) ? 1 : 0);
+ len += sprintf(buf+len, "\n RXFULL: %d",(nStat & MPC5xxx_PSC_SR_RXFULL) ? 1 : 0);
+ len += sprintf(buf+len, "\n RxRDY: %d",(nStat & MPC5xxx_PSC_SR_RXRDY) ? 1 : 0);
+ len += sprintf(buf+len, "\n CDE: %d\n",(nStat & MPC5xxx_PSC_SR_CDE) ? 1 : 0);
+
+ }
+ return len;
+
+}
+static int sio_clear_err(struct file *file, const char *buffer, unsigned long count, void *data)
+{
+
+ struct mpc5xxx_psc *psc = (struct mpc5xxx_psc *) MPC5xxx_PSC1;
+
+ clear_err(psc);
+ return (int)count;
+}
+
+void clear_err(struct mpc5xxx_psc * psc)
+{
+ u8 byCmd;
+ u16 i;
+ unsigned int status, nBytes;
+
+ nBytes = in_be16(&psc->rfnum) & MPC5xxx_PSC_RFNUM_MASK;
+ for(i=0; i< nBytes;i++)
+ {
+ byCmd = in_8(&psc->mpc5xxx_psc_buffer_8);
+ rs_dprintk(MPC5xxx_PSC_DEBUG_CLEARERR,"loesche Byte %d von %d Bytes\n",i+1,nBytes);
+ }
+ status = in_be16(&psc->mpc5xxx_psc_status);
+ rs_dprintk(MPC5xxx_PSC_DEBUG_CLEARERR,"status Start %d\n",status);
+ byCmd = (u8) MPC5xxx_PSC_RST_ERR_STAT;
+ out_8(&psc->command, byCmd);
+ wmb();
+ status = in_be16(&psc->mpc5xxx_psc_status);
+ rmb();
+ rs_dprintk(MPC5xxx_PSC_DEBUG_CLEARERR,"status clear %d\n",status);
+}
+
^ 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