* RE: Mounta Vista Linux prompt on serial console
From: srinivas.surabhi @ 2005-02-16 3:18 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
>> Do not ignore this error. How big is your cramfs image? How much
RAM
>> do you have?
cramfs is 2.7MB where as the RAM size is 32MB. While building ofcourse
the RAMDISK size was told as 8MB. This I mentioned in the devrocket
kernel configuration.
Just FYI. Kernel Image was 640KB.
Here I have one doubt while building the uBoot image using mkImage with
multi option where was the FileSystem image getting downloaded ? and how
the downloaded location was known to the kernel Image for pointing out
the File System image location. The options -a and -e are applicable
only for first image, isn't it? First image I mean the kernel Image. I
was giving -a 0x0 and -e 0x0 since while building the kernel the kernel
base address was mentioned 0.
...
>> Is there any chance that you built your cramfs image on a x08 (or any
>> other little-endian) system and forgot to give the "-r" (reverse
>> endian-ness of filesystem) option to mkcramfs??
YES. You are right I am building the image on x86 (Windows platform).
But I checked the build log it used the -r option. The default build was
cpio format and after that using fstool converting to CRAMS and the
option -r was present .I believe that devrocket of MountaVista has
makefiles specific to OS i.e for Windows, because while installation it
asks for what type of OS do you want to have the Image Development
environment.
Thanks & Regards
Surabhi Srinivas
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]=0D
Sent: Wednesday, February 16, 2005 1:30 AM
To: Srinivas Surabhi (WT01 - EMBEDDED & PRODUCT ENGINEERING SOLUTIONS)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Mounta Vista Linux prompt on serial console=0D
In message
<EF9B29C78F41FA488927FCBC7750AF0E011DA5CB@hyd-mdp-msg.wipro.com> you
wrote:
>=0D
> My replies in blue tagged with surabhi
Don't do this. Email is a plain text medium only.
Read the netiquette, and quote properly.
> [surabhi --- start] could you please guide me how to provide a working
> file system on SDRAM before decompressing the Linux Image on SDRAM. Is
> it really related to init process failed.
It is obviously related -there was a clear error message that the
uncompressing of the cramfs filesystem failed.
> Is the below doesn't mean that the mounted one is working one ?
> "VFS: Mounted root (cramfs filesystem) readonly.
> Mounted devfs on /dev "
No, not at all. You can for example mount an empty filesystem - it
will mount perfectly fine, but it still doesn't work.
You should also read my message until the end; I asked:
>> Do not ignore this error. How big is your cramfs iage? How much RAM
>> do you have?
cramfs is 2.7MB where as the RAM size is 32MB. While building ofcourse
the RAMDISK size was told as 8MB. This I mentioned in the devrocket
kernel configuration.
...
>> Is there any chance that you built your cramfs image on a x08 (or any
>> other little-endian) system and forgot to give the "-r" (reverse
>> endian-ness of filesystem) option to mkcramfs??
YES. You are right I am building the image on x86 (Windows platform).
But I checked the build log it used the -r option. The default build was
cpio format and after that using fstool converting to CRAMS and the
option -r was present .I believe that devrocket of MountaVista has
makefiles specific to OS i.e for Windows, because while installation it
asks for what type of OS do you want to have the Image Development
environment.
Thanks & Regards
Surabhi Srinivas
=0D
Best regards,
Wolfgang Denk
--=0D
See us @ Embedded World, Nuremberg, Feb 22 - 24, Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Looks clean and obviously correct to me, but then _everything_ I
write always looks obviously correct to me. - Linus Torvalds in
<Pine.LNX.4.10.10012090054360.791-100000@penguin.transmeta.com>
Confidentiality Notice=0D
The information contained in this electronic message and any attachments to=
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or=
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or=
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
^ permalink raw reply
* Re: Incomplete network configuration information when booting from NFS root on Ebony
From: Eugene Surovegin @ 2005-02-16 2:59 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b05021518037b1758cc@mail.gmail.com>
On Tue, Feb 15, 2005 at 06:03:12PM -0800, Shawn Jin wrote:
> Is anybody using linux-2.6.10 from kernel.org for testing IBM Ebony board?
Yes, with stock boot loader and great success (bootp + NFS root). I
just use "ip=on root=/dev/nfs" and let my bootp server tell the kernel
about all other parameters.
[snip]
> However a new problem
> occurs. When the kernel tries to mount a NFS root filesystem, it
> complains incomplete network configuration information. See the
> following message dump. Any hints to solve the problem? Thanks a lot.
[snip]
> Kernel command line: root=/dev/nfs rw
> nfsroot=192.68.0.47:/opt/eldk3.1/ppc_4xx
> ip=192.168.0.245:192.168.0.47:::::off
[snip]
> IP-Config: Incomplete network configuration information.
Did you try looking at net/ipv4/ipconfig.c? This is file responsible
for this message.
I think there is relevant comment in ip_auto_config() function:
/*
* If the config information is insufficient (e.g., our IP address or
* IP address of the boot server is missing or we have multiple network
* interfaces and no default was set), use BOOTP or RARP to get the
* missing values.
*/
Probably your case - multiple ethernet devices (440GX has 4) and
you haven't specified which device should be assigned IP.
--
Eugene
^ permalink raw reply
* Incomplete network configuration information when booting from NFS root on Ebony
From: Shawn Jin @ 2005-02-16 2:03 UTC (permalink / raw)
To: ppcembed
Hi,
Is anybody using linux-2.6.10 from kernel.org for testing IBM Ebony board?
I found that 2.6.10 is not aware of U-Boot. That is, it neither
understands U-Boot's bd_info nor parses U-Boot's bootargs. So even if
the ethernet MAC address is set for EMAC0 on uboot, the kernel doesn't
get the value from it. Instead it reads MAC address from Ebony VPD,
which results in FF:FF:FF:FF:FF:FF. Isn't it strange that mac address
isn't set in its VPD?
After some hacks in arch/ppc/platforms/4xx/ebony.c, the kernel now can
get MAC address and boot arguments from uboot. However a new problem
occurs. When the kernel tries to mount a NFS root filesystem, it
complains incomplete network configuration information. See the
following message dump. Any hints to solve the problem? Thanks a lot.
## Transferring control to Linux (at address 00000000) ...
Linux version 2.6.10 (xjin@swl001.scs.agilent.com) (gcc version 3.3.3
(DENX ELDK 3.1 3.3.3-8)) #11 T
ue Feb 15 16:41:47 PST 2005
IBM Ebony port (MontaVista Software, Inc. (source@mvista.com))
Built 1 zonelists
Kernel command line: root=/dev/nfs rw
nfsroot=192.68.0.47:/opt/eldk3.1/ppc_4xx
ip=192.168.0.245:192.168.0.47:::::off
<snipped>
mal0: Initialized, 4 tx channels, 2 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:1b:bb
eth0: Found Generic MII PHY (0x08)
zmii0: input 1 in RMII mode
eth1: IBM emac, MAC FF:FF:FF:FF:FF:FF
eth1: Found Generic MII PHY (0x09)
<--- only eth0's mac address is set on uboot -->
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
eth0: Link is Up
eth0: Speed: 100, Full duplex.
IP-Config: Incomplete network configuration information.
????
Looking up port of RPC 100003/2 on 130.27.84.47
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 130.27.84.47
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default
RPC: sendmsg returned error 101
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting /opt/eldk3.1/ppc_4xx
VFS: Unable to mount root fs via NFS, trying floppy.
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
<0>Rebooting in 180 seconds..<6>eth0: Link is Up
eth0: Speed: 100, Full duplex.
-Shawn.
^ permalink raw reply
* Re: How to set a custom baud rate using 2.6 linux distro on MPC5200 based board?
From: Eric N. Johnson (ACD) @ 2005-02-15 23:55 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <712A2DEC228C7448978CBD7A7AD5B090592CE2@fever.wardrobe.irob ot.com>
>I'm trying to set a custom baud rate (500KBaud, in case anyone cares) on
>one of the PSCs on a MPC5200 board.
[snip]
> serial_info.flags = ASYNC_SPD_CUST | ASYNC_LOW_LATENCY;
> serial_info.custom_divisor = 48; // clock on FTDI chip / 48 == 500KB
>
> if ( ioctl(tty_fd, TIOCSSERIAL, &serial_info ) < 0) {
> perror("config_serial_port: ioctl TIOCSSERIAL");
> return(-1);
> }
>
>This compiled fine under the ppc cross-dev tools we have but it fails with
>an "invalid argument" error when run on the ppc board.
It looks like this code was written for an FTDI serial port. The FTDI is a
USB to Serial converter that handles baud rate generation very differently
from a standard UART.
Eric
^ permalink raw reply
* Lite5200 full duplex support
From: Grant Likely @ 2005-02-15 23:48 UTC (permalink / raw)
To: Sylvain Munaut, linuxppc-embedded
I'm using Sylvain's http://bkbits.246tnt.com:14690/linux-2.5-mpc52xx
bk tree on a lite5200 evb. I noticed that the FEC driver is hard
coded to only support half duplex 10/100 auto-negotiation. Is that
intentional? Are there any known problems with running full duplex?
I modified the code to allow full duplex and I haven't observed any
problems yet. (w/ nfsroot and compiling apps on the target natively)
Cheers,
g.
BTW, here's what I changed:
drivers/net/fec_mpc52xx/fec_phy.c line 294 (phy_info_lxt971)
from:
{ mk_mii_write(MII_REG_ANAR, 0x0A1), NULL }, /* 10/100, HD */
to:
{ mk_mii_write(MII_REG_ANAR, 0x1E1), NULL }, /* 10/100, HD */
^ permalink raw reply
* [PATCH][PPC32] Artesyn Katana platform update
From: Mark A. Greer @ 2005-02-15 22:29 UTC (permalink / raw)
To: akpm; +Cc: Embedded PPC Linux list
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
Hi Andrew.
This patch:
- Adds MTD support for the soldered FLASH
- Adds cmdline parsing
- Turns on the Blue LED when the system is halted
- Moves some of the device window left by the firmware to proper alignments
- Handles possibility of different frequencies for TCLK & SysCLK in 64460
- Misc. code clean up
Please apply.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
[-- Attachment #2: katana_3.patch --]
[-- Type: text/plain, Size: 20138 bytes --]
diff -Nru a/arch/ppc/configs/katana_defconfig b/arch/ppc/configs/katana_defconfig
--- a/arch/ppc/configs/katana_defconfig 2005-02-15 15:11:59 -07:00
+++ b/arch/ppc/configs/katana_defconfig 2005-02-15 15:11:59 -07:00
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.11-rc2
-# Tue Jan 25 16:31:13 2005
+# Linux kernel version: 2.6.11-rc4
+# Tue Feb 15 14:27:12 2005
#
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
@@ -152,8 +152,8 @@
CONFIG_TASK_SIZE=0x80000000
CONFIG_CONSISTENT_START_BOOL=y
CONFIG_CONSISTENT_START=0xf0000000
-# CONFIG_CONSISTENT_SIZE_BOOL is not set
-CONFIG_CONSISTENT_SIZE=0x00200000
+CONFIG_CONSISTENT_SIZE_BOOL=y
+CONFIG_CONSISTENT_SIZE=0x00400000
# CONFIG_BOOT_LOAD_BOOL is not set
CONFIG_BOOT_LOAD=0x00800000
@@ -171,7 +171,82 @@
#
# Memory Technology Devices (MTD)
#
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+CONFIG_MTD_PARTITIONS=y
+CONFIG_MTD_CONCAT=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+# CONFIG_MTD_CMDLINE_PARTS is not set
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLOCK=y
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+CONFIG_MTD_CFI_ADV_OPTIONS=y
+CONFIG_MTD_CFI_NOSWAP=y
+# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
+# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
+CONFIG_MTD_CFI_GEOMETRY=y
+# CONFIG_MTD_MAP_BANK_WIDTH_1 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_2 is not set
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+# CONFIG_MTD_CFI_I1 is not set
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+CONFIG_MTD_CFI_INTELEXT=y
+# CONFIG_MTD_CFI_AMDSTD is not set
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+# CONFIG_MTD_XIP is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+CONFIG_MTD_PHYSMAP=y
+CONFIG_MTD_PHYSMAP_START=0xe0000000
+CONFIG_MTD_PHYSMAP_LEN=0x0
+CONFIG_MTD_PHYSMAP_BANKWIDTH=4
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+CONFIG_MTD_PHRAM=y
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLKMTD is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+
+#
+# NAND Flash Device Drivers
+#
+# CONFIG_MTD_NAND is not set
#
# Parallel port support
@@ -531,7 +606,6 @@
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
-# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Sound
@@ -573,6 +647,10 @@
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
+
+#
+# XFS support
+#
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
@@ -619,6 +697,8 @@
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
+# CONFIG_JFFS_FS is not set
+# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
@@ -637,7 +717,6 @@
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
-# CONFIG_EXPORTFS is not set
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
diff -Nru a/arch/ppc/platforms/katana.c b/arch/ppc/platforms/katana.c
--- a/arch/ppc/platforms/katana.c 2005-02-15 15:11:59 -07:00
+++ b/arch/ppc/platforms/katana.c 2005-02-15 15:11:59 -07:00
@@ -1,9 +1,10 @@
/*
* arch/ppc/platforms/katana.c
*
- * Board setup routines for the Artesyn Katana 750 based boards.
+ * Board setup routines for the Artesyn Katana cPCI boards.
*
- * Tim Montgomery <timm@artesyncp.com>
+ * Athor: Tim Montgomery <timm@artesyncp.com>
+ * Maintained by: Mark A. Greer <mgreer@mvista.com>
*
* Based on code done by Rabeeh Khoury - rabeeh@galileo.co.il
* Based on code done by - Mark A. Greer <mgreer@mvista.com>
@@ -26,7 +27,8 @@
#include <linux/root_dev.h>
#include <linux/delay.h>
#include <linux/seq_file.h>
-#include <linux/smp.h>
+#include <linux/bootmem.h>
+#include <linux/mtd/physmap.h>
#include <linux/mv643xx.h>
#ifdef CONFIG_BOOTIMG
#include <linux/bootimg.h>
@@ -36,13 +38,19 @@
#include <asm/smp.h>
#include <asm/todc.h>
#include <asm/bootinfo.h>
+#include <asm/ppcboot.h>
#include <asm/mv64x60.h>
#include <platforms/katana.h>
static struct mv64x60_handle bh;
static katana_id_t katana_id;
-static u32 cpld_base;
-static u32 sram_base;
+static void __iomem *cpld_base;
+static void __iomem *sram_base;
+
+static u32 katana_flash_size_0;
+static u32 katana_flash_size_1;
+
+unsigned char __res[sizeof(bd_t)];
/* PCI Interrupt routing */
static int __init
@@ -105,7 +113,7 @@
void __init
katana_get_board_id(void)
{
- switch (in_8((volatile char *)(cpld_base + KATANA_CPLD_PRODUCT_ID))) {
+ switch (in_8(cpld_base + KATANA_CPLD_PRODUCT_ID)) {
case KATANA_PRODUCT_ID_3750:
katana_id = KATANA_ID_3750;
break;
@@ -170,7 +178,7 @@
static inline int
katana_is_monarch(void)
{
- return in_8((volatile char *)(cpld_base + KATANA_CPLD_BD_CFG_3)) &
+ return in_8(cpld_base + KATANA_CPLD_BD_CFG_3) &
KATANA_CPLD_BD_CFG_3_MONARCH;
}
@@ -180,18 +188,17 @@
u8 reset_out;
/* Enable access to IPMI ctlr by clearing IPMI PORTSEL bit in CPLD */
- reset_out = in_8((volatile char *)(cpld_base + KATANA_CPLD_RESET_OUT));
+ reset_out = in_8(cpld_base + KATANA_CPLD_RESET_OUT);
reset_out &= ~KATANA_CPLD_RESET_OUT_PORTSEL;
- out_8((volatile void *)(cpld_base + KATANA_CPLD_RESET_OUT), reset_out);
- return;
+ out_8(cpld_base + KATANA_CPLD_RESET_OUT, reset_out);
}
-static unsigned long
+static u32
katana_bus_freq(void)
{
u8 bd_cfg_0;
- bd_cfg_0 = in_8((volatile char *)(cpld_base + KATANA_CPLD_BD_CFG_0));
+ bd_cfg_0 = in_8(cpld_base + KATANA_CPLD_BD_CFG_0);
switch (bd_cfg_0 & KATANA_CPLD_BD_CFG_0_SYSCLK_MASK) {
case KATANA_CPLD_BD_CFG_0_SYSCLK_200:
@@ -263,13 +270,12 @@
* BIT25 summarizes GPP interrupts 8-15
*/
mv64x60_set_bits(&bh, MV64360_IC_CPU0_INTR_MASK_HI, (1<<25));
- return;
}
void __init
katana_setup_peripherals(void)
{
- u32 base, size_0, size_1;
+ u32 base;
/* Set up windows for boot CS, soldered & socketed flash, and CPLD */
mv64x60_set_32bit_window(&bh, MV64x60_CPU2BOOT_WIN,
@@ -277,19 +283,22 @@
bh.ci->enable_window_32bit(&bh, MV64x60_CPU2BOOT_WIN);
/* Assume firmware set up window sizes correctly for dev 0 & 1 */
- mv64x60_get_32bit_window(&bh, MV64x60_CPU2DEV_0_WIN, &base, &size_0);
+ mv64x60_get_32bit_window(&bh, MV64x60_CPU2DEV_0_WIN, &base,
+ &katana_flash_size_0);
- if (size_0 > 0) {
+ if (katana_flash_size_0 > 0) {
mv64x60_set_32bit_window(&bh, MV64x60_CPU2DEV_0_WIN,
- KATANA_SOLDERED_FLASH_BASE, size_0, 0);
+ KATANA_SOLDERED_FLASH_BASE, katana_flash_size_0, 0);
bh.ci->enable_window_32bit(&bh, MV64x60_CPU2DEV_0_WIN);
}
- mv64x60_get_32bit_window(&bh, MV64x60_CPU2DEV_1_WIN, &base, &size_1);
+ mv64x60_get_32bit_window(&bh, MV64x60_CPU2DEV_1_WIN, &base,
+ &katana_flash_size_1);
- if (size_1 > 0) {
+ if (katana_flash_size_1 > 0) {
mv64x60_set_32bit_window(&bh, MV64x60_CPU2DEV_1_WIN,
- (KATANA_SOLDERED_FLASH_BASE + size_0), size_1, 0);
+ (KATANA_SOLDERED_FLASH_BASE + katana_flash_size_0),
+ katana_flash_size_1, 0);
bh.ci->enable_window_32bit(&bh, MV64x60_CPU2DEV_1_WIN);
}
@@ -300,12 +309,12 @@
mv64x60_set_32bit_window(&bh, MV64x60_CPU2DEV_3_WIN,
KATANA_CPLD_BASE, KATANA_CPLD_SIZE, 0);
bh.ci->enable_window_32bit(&bh, MV64x60_CPU2DEV_3_WIN);
- cpld_base = (u32)ioremap(KATANA_CPLD_BASE, KATANA_CPLD_SIZE);
+ cpld_base = ioremap(KATANA_CPLD_BASE, KATANA_CPLD_SIZE);
mv64x60_set_32bit_window(&bh, MV64x60_CPU2SRAM_WIN,
KATANA_INTERNAL_SRAM_BASE, MV64360_SRAM_SIZE, 0);
bh.ci->enable_window_32bit(&bh, MV64x60_CPU2SRAM_WIN);
- sram_base = (u32)ioremap(KATANA_INTERNAL_SRAM_BASE, MV64360_SRAM_SIZE);
+ sram_base = ioremap(KATANA_INTERNAL_SRAM_BASE, MV64360_SRAM_SIZE);
/* Set up Enet->SRAM window */
mv64x60_set_32bit_window(&bh, MV64x60_ENET2MEM_4_WIN,
@@ -339,13 +348,11 @@
* internal data path in SRAM since it's first time accessing it
* while after reset it's not configured.
*/
- memset((void *)sram_base, 0, MV64360_SRAM_SIZE);
+ memset(sram_base, 0, MV64360_SRAM_SIZE);
/* Only processor zero [on 3750] is an PCI interrupt controller */
if (katana_get_proc_num() == 0)
katana_intr_setup();
-
- return;
}
static void __init
@@ -356,7 +363,7 @@
memset(&si, 0, sizeof(si));
- si.phys_reg_base = KATANA_BRIDGE_REG_BASE;
+ si.phys_reg_base = CONFIG_MV64X60_NEW_BASE;
si.pci_1.enable_bus = 1;
si.pci_1.pci_io.cpu_base = KATANA_PCI1_IO_START_PROC_ADDR;
@@ -410,10 +417,77 @@
mv64x60_set_bus(&bh, 1, 0);
bh.hose_b->first_busno = 0;
bh.hose_b->last_busno = 0xff;
+}
- return;
+#ifdef CONFIG_MTD_PHYSMAP
+
+#ifndef MB
+#define MB (1 << 20)
+#endif
+
+/*
+ * MTD Layout depends on amount of soldered FLASH in system. Sizes in MB.
+ *
+ * FLASH Amount: 128 64 32 16
+ * ------------- --- -- -- --
+ * Monitor: 1 1 1 1
+ * Primary Kernel: 1.5 1.5 1.5 1.5
+ * Primary fs: 30 30 <end> <end>
+ * Secondary Kernel: 1.5 1.5 N/A N/A
+ * Secondary fs: <end> <end> N/A N/A
+ * User: <overlays entire FLASH except for "Monitor" section>
+ */
+static int __init
+katana_setup_mtd(void)
+{
+ u32 size;
+ int ptbl_entries;
+ static struct mtd_partition *ptbl;
+
+ size = katana_flash_size_0 + katana_flash_size_1;
+ if (!size)
+ return -ENOMEM;
+
+ ptbl_entries = (size >= (64*MB)) ? 6 : 4;
+
+ if ((ptbl = kmalloc(ptbl_entries * sizeof(struct mtd_partition),
+ GFP_KERNEL)) == NULL) {
+
+ printk(KERN_WARNING "Can't alloc MTD partition table\n");
+ return -ENOMEM;
+ }
+ memset(ptbl, 0, ptbl_entries * sizeof(struct mtd_partition));
+
+ ptbl[0].name = "Monitor";
+ ptbl[0].size = KATANA_MTD_MONITOR_SIZE;
+ ptbl[1].name = "Primary Kernel";
+ ptbl[1].offset = MTDPART_OFS_NXTBLK;
+ ptbl[1].size = 0x00180000; /* 1.5 MB */
+ ptbl[2].name = "Primary Filesystem";
+ ptbl[2].offset = MTDPART_OFS_APPEND;
+ ptbl[2].size = MTDPART_SIZ_FULL; /* Correct for 16 & 32 MB */
+ ptbl[ptbl_entries-1].name = "User FLASH";
+ ptbl[ptbl_entries-1].offset = KATANA_MTD_MONITOR_SIZE;
+ ptbl[ptbl_entries-1].size = MTDPART_SIZ_FULL;
+
+ if (size >= (64*MB)) {
+ ptbl[2].size = 30*MB;
+ ptbl[3].name = "Secondary Kernel";
+ ptbl[3].offset = MTDPART_OFS_NXTBLK;
+ ptbl[3].size = 0x00180000; /* 1.5 MB */
+ ptbl[4].name = "Secondary Filesystem";
+ ptbl[4].offset = MTDPART_OFS_APPEND;
+ ptbl[4].size = MTDPART_SIZ_FULL;
+ }
+
+ physmap_map.size = size;
+ physmap_set_partitions(ptbl, ptbl_entries);
+ return 0;
}
+arch_initcall(katana_setup_mtd);
+#endif
+
static void __init
katana_setup_arch(void)
{
@@ -444,8 +518,7 @@
printk(KERN_INFO "DD2.0 detected. Setting L2 cache"
"to Writethrough mode\n");
_set_L2CR(L2CR_L2E | L2CR_L2PE | L2CR_L2WT);
- }
- else
+ } else
_set_L2CR(L2CR_L2E | L2CR_L2PE);
if (ppc_md.progress)
@@ -458,7 +531,6 @@
printk(KERN_INFO "Artesyn Communication Products, LLC - Katana(TM)\n");
if (ppc_md.progress)
ppc_md.progress("katana_setup_arch: exit", 0);
- return;
}
/* Platform device data fixup routines. */
@@ -473,9 +545,12 @@
pdata->max_idle = 40;
pdata->default_baud = KATANA_DEFAULT_BAUD;
pdata->brg_clk_src = KATANA_MPSC_CLK_SRC;
- pdata->brg_clk_freq = KATANA_MPSC_CLK_FREQ;
-
- return;
+ /*
+ * TCLK (not SysCLk) is routed to BRG, then to the MPSC. On most parts,
+ * TCLK == SysCLK but on 64460, they are separate pins.
+ * SysCLK can go up to 200 MHz but TCLK can only go up to 133 MHz.
+ */
+ pdata->brg_clk_freq = min(katana_bus_freq(), MV64x60_TCLK_FREQ_MAX);
}
#endif
@@ -548,11 +623,10 @@
static void
katana_restart(char *cmd)
{
- volatile ulong i = 10000000;
+ ulong i = 10000000;
/* issue hard reset to the reset command register */
- out_8((volatile char *)(cpld_base + KATANA_CPLD_RST_CMD),
- KATANA_CPLD_RST_CMD_HR);
+ out_8(cpld_base + KATANA_CPLD_RST_CMD, KATANA_CPLD_RST_CMD_HR);
while (i-- > 0) ;
panic("restart failed\n");
@@ -561,6 +635,14 @@
static void
katana_halt(void)
{
+ u8 v;
+
+ if (katana_id == KATANA_ID_752I) {
+ v = in_8(cpld_base + HSL_PLD_BASE + HSL_PLD_HOT_SWAP_OFF);
+ v |= HSL_PLD_HOT_SWAP_LED_BIT;
+ out_8(cpld_base + HSL_PLD_BASE + HSL_PLD_HOT_SWAP_OFF, v);
+ }
+
while (1) ;
/* NOTREACHED */
}
@@ -598,12 +680,13 @@
}
seq_printf(m, "product ID\t: 0x%x\n",
- in_8((volatile char *)(cpld_base + KATANA_CPLD_PRODUCT_ID)));
+ in_8(cpld_base + KATANA_CPLD_PRODUCT_ID));
seq_printf(m, "hardware rev\t: 0x%x\n",
- in_8((volatile char *)(cpld_base+KATANA_CPLD_HARDWARE_VER)));
+ in_8(cpld_base+KATANA_CPLD_HARDWARE_VER));
seq_printf(m, "PLD rev\t\t: 0x%x\n",
- in_8((volatile char *)(cpld_base + KATANA_CPLD_PLD_VER)));
- seq_printf(m, "PLB freq\t: %ldMhz\n", katana_bus_freq() / 1000000);
+ in_8(cpld_base + KATANA_CPLD_PLD_VER));
+ seq_printf(m, "PLB freq\t: %ldMhz\n",
+ (long)katana_bus_freq() / 1000000);
seq_printf(m, "PCI\t\t: %sMonarch\n", katana_is_monarch()? "" : "Non-");
return 0;
@@ -612,23 +695,21 @@
static void __init
katana_calibrate_decr(void)
{
- ulong freq;
+ u32 freq;
freq = katana_bus_freq() / 4;
printk(KERN_INFO "time_init: decrementer frequency = %lu.%.6lu MHz\n",
- freq / 1000000, freq % 1000000);
+ (long)freq / 1000000, (long)freq % 1000000);
tb_ticks_per_jiffy = freq / HZ;
tb_to_us = mulhwu_scale_factor(freq, 1000000);
-
- return;
}
unsigned long __init
katana_find_end_of_memory(void)
{
- return mv64x60_get_mem_size(KATANA_BRIDGE_REG_BASE,
+ return mv64x60_get_mem_size(CONFIG_MV64X60_NEW_BASE,
MV64x60_TYPE_MV64360);
}
@@ -639,8 +720,6 @@
mtspr(DBAT2U, 0xf0001ffe);
mtspr(DBAT2L, 0xf000002a);
mb();
-
- return;
}
#if defined(CONFIG_SERIAL_TEXT_DEBUG) && defined(CONFIG_SERIAL_MPSC_CONSOLE)
@@ -657,6 +736,23 @@
{
parse_bootinfo(find_bootinfo());
+ /* ASSUMPTION: If both r3 (bd_t pointer) and r6 (cmdline pointer)
+ * are non-zero, then we should use the board info from the bd_t
+ * structure and the cmdline pointed to by r6 instead of the
+ * information from birecs, if any. Otherwise, use the information
+ * from birecs as discovered by the preceeding call to
+ * parse_bootinfo(). This rule should work with both PPCBoot, which
+ * uses a bd_t board info structure, and the kernel boot wrapper,
+ * which uses birecs.
+ */
+ if (r3 && r6) {
+ /* copy board info structure */
+ memcpy( (void *)__res,(void *)(r3+KERNELBASE), sizeof(bd_t) );
+ /* copy command line */
+ *(char *)(r7+KERNELBASE) = 0;
+ strcpy(cmd_line, (char *)(r6+KERNELBASE));
+ }
+
isa_mem_base = 0;
ppc_md.setup_arch = katana_setup_arch;
@@ -672,7 +768,7 @@
#if defined(CONFIG_SERIAL_TEXT_DEBUG) && defined(CONFIG_SERIAL_MPSC_CONSOLE)
ppc_md.setup_io_mappings = katana_map_io;
ppc_md.progress = mv64x60_mpsc_progress;
- mv64x60_progress_init(KATANA_BRIDGE_REG_BASE);
+ mv64x60_progress_init(CONFIG_MV64X60_NEW_BASE);
#endif
#if defined(CONFIG_SERIAL_MPSC) || defined(CONFIG_MV643XX_ETH)
@@ -680,5 +776,4 @@
#endif
katana_set_bat(); /* Need for katana_find_end_of_memory and progress */
- return;
}
diff -Nru a/arch/ppc/platforms/katana.h b/arch/ppc/platforms/katana.h
--- a/arch/ppc/platforms/katana.h 2005-02-15 15:11:59 -07:00
+++ b/arch/ppc/platforms/katana.h 2005-02-15 15:11:59 -07:00
@@ -19,18 +19,17 @@
* PCI I/O space and 4 windows from the CPU bus to PCI MEM space.
* We'll only use one PCI MEM window on each PCI bus.
*
- * This is the CPU physical memory map (windows must be at least 1MB and start
+ * This is the CPU physical memory map (windows must be at least 64 KB and start
* on a boundary that is a multiple of the window size):
*
* 0xff800000-0xffffffff - Boot window
* 0xf8400000-0xf85fffff - Internal SRAM
- * 0xf8200000-0xf823ffff - CPLD
- * 0xf8100000-0xf810ffff - MV64360 Registers
- * 0xf8000000-0xf80fffff - PLCC socket
- * 0xf0000000-0xf01fffff - Consistent memory pool
- * 0xe8000000-0xefffffff - soldered flash
- * 0xc0000000-0xc0ffffff - PCI I/O
- * 0x80000000-0xbfffffff - PCI MEM
+ * 0xf8200000-0xf83fffff - CPLD
+ * 0xf8100000-0xf810ffff - MV64360 Registers (CONFIG_MV64X60_NEW_BASE)
+ * 0xf8000000-0xf80fffff - Socketed FLASH
+ * 0xe0000000-0xefffffff - Soldered FLASH
+ * 0xc0000000-0xc3ffffff - PCI I/O (second hose)
+ * 0x80000000-0xbfffffff - PCI MEM (second hose)
*/
#ifndef __PPC_PLATFORMS_KATANA_H
@@ -38,33 +37,22 @@
/* CPU Physical Memory Map setup. */
#define KATANA_BOOT_WINDOW_BASE 0xff800000
+#define KATANA_BOOT_WINDOW_SIZE 0x00800000 /* 8 MB */
#define KATANA_INTERNAL_SRAM_BASE 0xf8400000
#define KATANA_CPLD_BASE 0xf8200000
-#define KATANA_BRIDGE_REG_BASE 0xf8100000
+#define KATANA_CPLD_SIZE 0x00200000 /* 2 MB */
#define KATANA_SOCKET_BASE 0xf8000000
-#define KATANA_SOLDERED_FLASH_BASE 0xe8000000
-
-#define KATANA_BOOT_WINDOW_SIZE_ACTUAL 0x00800000 /* 8MB */
-#define KATANA_CPLD_SIZE_ACTUAL 0x00020000 /* 128KB */
-#define KATANA_SOCKETED_FLASH_SIZE_ACTUAL 0x00080000 /* 512KB */
-#define KATANA_SOLDERED_FLASH_SIZE_ACTUAL 0x02000000 /* 32MB */
-
-#define KATANA_BOOT_WINDOW_SIZE max(MV64360_WINDOW_SIZE_MIN, \
- KATANA_BOOT_WINDOW_SIZE_ACTUAL)
-#define KATANA_CPLD_SIZE max(MV64360_WINDOW_SIZE_MIN, \
- KATANA_CPLD_SIZE_ACTUAL)
-#define KATANA_SOCKETED_FLASH_SIZE max(MV64360_WINDOW_SIZE_MIN, \
- KATANA_SOCKETED_FLASH_SIZE_ACTUAL)
-#define KATANA_SOLDERED_FLASH_SIZE max(MV64360_WINDOW_SIZE_MIN, \
- KATANA_SOLDERED_FLASH_SIZE_ACTUAL)
+#define KATANA_SOCKETED_FLASH_SIZE 0x00100000 /* 1 MB */
+#define KATANA_SOLDERED_FLASH_BASE 0xe0000000
+#define KATANA_SOLDERED_FLASH_SIZE 0x10000000 /* 256 MB */
#define KATANA_PCI1_MEM_START_PROC_ADDR 0x80000000
#define KATANA_PCI1_MEM_START_PCI_HI_ADDR 0x00000000
#define KATANA_PCI1_MEM_START_PCI_LO_ADDR 0x80000000
-#define KATANA_PCI1_MEM_SIZE 0x40000000
+#define KATANA_PCI1_MEM_SIZE 0x40000000 /* 1 GB */
#define KATANA_PCI1_IO_START_PROC_ADDR 0xc0000000
#define KATANA_PCI1_IO_START_PCI_ADDR 0x00000000
-#define KATANA_PCI1_IO_SIZE 0x01000000
+#define KATANA_PCI1_IO_SIZE 0x04000000 /* 64 MB */
/* Board-specific IRQ info */
#define KATANA_PCI_INTA_IRQ_3750 64+8
@@ -138,6 +126,8 @@
#define HSL_PLD_J4SGA_REG_OFF 0
#define HSL_PLD_J4GA_REG_OFF 1
#define HSL_PLD_J2GA_REG_OFF 2
+#define HSL_PLD_HOT_SWAP_OFF 6
+#define HSL_PLD_HOT_SWAP_LED_BIT 0x1
#define GA_MASK 0x1f
#define HSL_PLD_SIZE 0x1000
#define K3750_GPP_GEO_ADDR_PINS 0xf8000000
@@ -162,7 +152,8 @@
#define KATANA_DEFAULT_BAUD 9600
#define KATANA_MPSC_CLK_SRC 8 /* TCLK */
-#define KATANA_MPSC_CLK_FREQ 133333333 /* 133.3333... MHz */
+
+#define KATANA_MTD_MONITOR_SIZE (1 << 20) /* 1 MB */
#define KATANA_ETH0_PHY_ADDR 12
#define KATANA_ETH1_PHY_ADDR 11
diff -Nru a/include/asm-ppc/mv64x60_defs.h b/include/asm-ppc/mv64x60_defs.h
--- a/include/asm-ppc/mv64x60_defs.h 2005-02-15 15:11:59 -07:00
+++ b/include/asm-ppc/mv64x60_defs.h 2005-02-15 15:11:59 -07:00
@@ -36,6 +36,8 @@
#define GT64260_WINDOW_SIZE_MIN 0x00100000
#define MV64360_WINDOW_SIZE_MIN 0x00010000
+#define MV64x60_TCLK_FREQ_MAX 133333333U
+
/* IRQ's for embedded controllers */
#define MV64x60_IRQ_DEV 1
#define MV64x60_IRQ_CPU_ERR 3
@@ -303,7 +305,7 @@
#define MV64360_SRAM_ERR_DATA_HI 0x03a0
#define MV64360_SRAM_ERR_PARITY 0x03a8
-#define MV64360_SRAM_SIZE 0x00040000 /* 256 KB of SRAM */
+#define MV64360_SRAM_SIZE 0x00200000 /* 2 MB of SRAM */
/*
*****************************************************************************
^ permalink raw reply
* RE: 8266 SMC uart corruption
From: Rune Torgersen @ 2005-02-15 22:13 UTC (permalink / raw)
To: linuxppc-embedded
Rm91bmQgbW9yZSBpbmZvOg0KDQpUaGUgY29ycnVwdGlvbiBoYXBwZW5zIHdoZW4gY3BtX3VhcnRf
c2V0X3Rlcm1pb3MoKSBpcyBjYWxsZWQuDQpJIGhhdmUgbm8gaWRlYSBob3cgdG8gZml4IGl0LCBl
eGNlcHQgZm9yIHB1dHRpbmcgaW4gYSB1ZGVsYXkoMTAwMDApIHJpZ2h0IGJlZm9yZSB0aGUgc21j
IG1vZGUgcmVnaXN0ZXIgZ2V0cyByZXdyaXR0ZW4uDQogDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCj4gRnJvbTogUnVuZSBUb3JnZXJzZW4gDQo+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1
YXJ5IDA4LCAyMDA1IDExOjQ2DQo+IFRvOiBsaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnDQo+
IFN1YmplY3Q6IFJFOiA4MjY2IFNNQyB1YXJ0IGNvcnJ1cHRpb24NCj4gDQo+IE1vcmUgSW5mbzoN
Cj4gVGhpcyBzZWVtcyB0byBiZSByZWxhdGVkIHRvIGNwbV91YXJ0X3N0b3BfdHgoKQ0KPiBUaGVy
ZSBzZWVtcyB0byBiZSBhbiBleGNlc3NpdmUgYW1vdW50IG9mIHN0b3BzIGFuZCBzdGFydHMgZ29p
bmcgb24NCj4gSW4gdGhlIGZvbGxvd2luZywgSSBwcmludCBhbiBcIGZvciBlYWNoIHRpbWUgc3Rv
cF90eCBpcyANCj4gY2FsbGVkLCBhbmQgYSAvIGZvciBzdGFydF90eA0KPiANCj4gLS0tLS0tLS0t
DQo+IEVYVDMtZnM6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLg0K
PiBWRlM6IE1vdW50ZWQgcm9vdCAoZXh0MyBmaWxlc3lzdGVtKS4NCj4gRnJlZWluZyB1bnVzZWQg
a2VybmVsIG1lbW9yeTogMjg4ayBpbml0DQo+IFwvSVwvVFwvwrdcL3ZlcnNcL2lcL29uIDJcLy5c
Lzg1IGJcL29cL290aW5cL8KgLw0KPiBcL0FjdGlcL3ZcL2F0aW5cL2dcLyBhbGxcLyBcL3N3YXBc
LyANCj4gXC9maWxlXC9zXC8vcGFyXC90XC9pdGlvXC9uXC9zLi4uXDw2PkFkZGluZyAxMDI4MTUy
ayBzd2FwIG9uIA0KPiAvZGV2L2hkYTIuICBQcmlvcml0eToxIGV4dGVudHM6MQ0KPiAvICAgICAg
IFwvWyAgXC9PS1wvICBdXC8NCj4gXC9Nb3VuXC90XC9pbmcgXC9wXC9yb2MgXC9mXC9pbGUgXC9z
XC95c3RlXC9tXC8uLi5cLyAgICBcL1sgIA0KPiBcL09LXC8gIF1cLw0KPiBcL01vdW5cL3RcL2lu
ZyBcL3JcL29vdCBcL2ZcL2lsZSBcL3NcL3lzdGVcL21cLyBpbiANCj4gXC9yXC9lYWQtXC9vXC9u
bHkgXC9tXC9vZGUuXC8uXC8uXC8NCj4gDQo+IC0tLS0tLS0tLS0NCj4gQW5kIHNvIG9uLg0KPiAN
Cj4gSWYgSSBwdXQgaW4gYSB1ZGVsYXkoMTAwMDApIGF0IHRoZSBlbmQgb2YgY3BtX3VhcnRfc3Rv
cF90eCwgDQo+IGFsbCBvdXRwdXQgcHJpbnRzIE9LLCBidXQgc2xvdy4NCj4gDQo+IDIuNi43IGFu
ZCBwcmlvciBkb2VzIG5vdCB1c2UgdGhlIHN0b3AgYXQgYWxsIGZvcm0gd2hhdCBJIGNhbiBzZWUu
DQo+ICANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBSdW5l
IFRvcmdlcnNlbiANCj4gPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwMSwgMjAwNSAwODo0Mg0K
PiA+IFRvOiBsaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnDQo+ID4gU3ViamVjdDogODI2NiBT
TUMgdWFydCBjb3JydXB0aW9uDQo+ID4gDQo+ID4gSGkNCj4gPiANCj4gPiBIYXMgYW55Ym9yZHkg
ZWxzZSBzZWVuIGNvcnJ1cHRpb24gb2YgdGhlIG91dHB1dCBmcm9tIFNNQzEgDQo+ID4gd2hlbiB1
c2VkIGFzIHNlcmlhbCBjb25zb2xlPw0KPiA+IFRoaXMgb25seSBvY2N1cnMgaW4gaW4gMi42Ljgg
YW5kIGxhdGVyICh3aGVuIHRoZSBDUE0gc2VyaWFsIA0KPiA+IGRyaXZlcnMgZ290IG1vdmVkKQ0K
PiA+IEFuZCBpdCBvbmx5IG9jY3VycyB3aGVuIGluaXQgaXMgd3JpdGluZyB0byBzY3JlZW4uIDIu
Ni43IGFuZCANCj4gPiBlYXJsaWVyIHdvcmtzIHBlcmZlY3RseS4NCj4gPiBJdCBoYXBwZW5zIGF0
IGFsbCBiYXVkcmF0ZXMgdGVzdGVkICg5NjAwIGFuZCAxMTUyMDApDQo+ID4gDQo+ID4gQW55Ym9k
eSBzZWVuIHNvbWV0aGluZyBzaW1pbGFyIGFuZC9vciBoYXZlIGEgY2x1ZSB3aGVyZSB0byANCj4g
PiBzdGFydCBsb29raW5nIGZvciB0aGlzPw0KPiA+IEkgaGF2ZSBsb29rZWQgYXQgdGhlIHNlcmlh
bCBkcml2ZXJzLCBhbmQgY2Fubm90IGZpbmQgYW55IA0KPiA+IGRpZmZlcmVuY2VzIGxhcmdlIGRp
ZmZlcmVuY2VzIGZyb20gd2hlbnRoZXkgc3RpbGwgd2VyZSBpbiANCj4gPiBhcmNoL3BwYy84MjYw
X2lvIHRvIHRoZSBvbmVzIGluIGRyaXZlcnMvc2VyaWFsL2NwbV91YXJ0DQo+ID4gDQo+ID4gQ2Fw
dHVyZToNCj4gPiANCj4gPiBGcmVlaW5nIHVudXNlZCBrZXJuZWwgbWVtb3J5OiAyODhrIGnOtXQN
Cj4gPiBJ4pagVDogdmVyc2lvbiAyLjg1IGJvb3TiiJlnDQo+ID4gLi4uDQo+ID4gSeKWoFTCoEVu
dGVyaW5nIHJ1bmxldmVsOiAzDQo+ID4gDQo+ID4gDQo+ID4gVGhlc2UgbGluZXMgYXJlIHRoZSBv
bmx5IG9uZXMgdGhhdCBnZXQgY29ycnVwdGVkLiBBbGwgb3RoZXIgDQo+ID4gb3V0cHV0IChrZXJu
ZWwgcHJpbnRvdXRzLCBjb25zb2xlIGFuZCBzdGFydHVwIHNjcmlwdHMpIGFyZSBub3JtYWwuDQo+
IA0K
^ permalink raw reply
* How to set a custom baud rate using 2.6 linux distro on MPC5200 based board?
From: Caruso, Nick @ 2005-02-15 21:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 897 bytes --]
I'm trying to set a custom baud rate (500KBaud, in case anyone cares) on one of the PSCs on a MPC5200 board.
The PSC is configured as a serial port and is visible and usable under the 2.6 kernel we're using.
I used to use the following code under 2.4 on an x86 board:
serial_info.flags = ASYNC_SPD_CUST | ASYNC_LOW_LATENCY;
serial_info.custom_divisor = 48; // clock on FTDI chip / 48 == 500KB
if ( ioctl(tty_fd, TIOCSSERIAL, &serial_info ) < 0) {
perror("config_serial_port: ioctl TIOCSSERIAL");
return(-1);
}
This compiled fine under the ppc cross-dev tools we have but it fails with an "invalid argument" error when run on the ppc board.
I'm busy reading the driver sources but thought someone on the list might be able to help me out.
thanks!
--nick caruso
irobot corporation
intelligent vehicles
r-gator project
[-- Attachment #2: Type: text/html, Size: 1628 bytes --]
^ permalink raw reply
* Re: [PATCH][PPC32] Adds mcc cpm commands
From: Tom Rini @ 2005-02-15 20:45 UTC (permalink / raw)
To: morten.banzon; +Cc: linuxppc-embedded
In-Reply-To: <OFBD33500D.E8DD3F33-ONC1256FA9.006C5F4F-C1256FA9.006CFE15@axxessit.no>
On Tue, Feb 15, 2005 at 08:50:11PM +0100, morten.banzon@axxessit.no wrote:
> Tom Rini <trini@kernel.crashing.org>
> 15.02.2005 20:23
>
>
> To: morten.banzon@axxessit.no
> cc: linuxppc-embedded@ozlabs.org
> Subject: Re: [PATCH][PPC32] Adds mcc cpm commands
>
>
> On Mon, Feb 14, 2005 at 01:56:07PM +0100, morten.banzon@axxessit.no wrote:
>
> >> This patch adds mcc cpm commands to the cpm2.h file in the 2.6.10
> kernel
> >>
> >> Signed-off-by: Morten Banzon <morten.banzon at axxessit.no>
>
> > What is this used for / needed by? Thanks.
>
>
> > --
> > Tom Rini
> > http://gate.crashing.org/~trini/
>
> This is needed for a MPC82xx MCC driver. Curently no MCC driver is in the
> kernel.
OK. I'd recommend holding off until 2.6.12 open then. Thanks, and
queued.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: Mounta Vista Linux prompt on serial console
From: Wolfgang Denk @ 2005-02-15 19:59 UTC (permalink / raw)
To: srinivas.surabhi; +Cc: linuxppc-embedded
In-Reply-To: <EF9B29C78F41FA488927FCBC7750AF0E011DA5CB@hyd-mdp-msg.wipro.com>
In message <EF9B29C78F41FA488927FCBC7750AF0E011DA5CB@hyd-mdp-msg.wipro.com> you wrote:
>
> My replies in blue tagged with surabhi
Don't do this. Email is a plain text medium only.
Read the netiquette, and quote properly.
> [surabhi --- start] could you please guide me how to provide a working
> file system on SDRAM before decompressing the Linux Image on SDRAM. Is
> it really related to init process failed.
It is obviously related -there was a clear error message that the
uncompressing of the cramfs filesystem failed.
> Is the below doesn't mean that the mounted one is working one ?
> "VFS: Mounted root (cramfs filesystem) readonly.
> Mounted devfs on /dev "
No, not at all. You can for example mount an empty filesystem - it
will mount perfectly fine, but it still doesn't work.
You should also read my message until the end; I asked:
>> Do not ignore this error. How big is your cramfs iage? How much RAM
>> do you have?
...
>> Is there any chance that you built your cramfs image on a x08 (or any
>> other little-endian) system and forgot to give the "-r" (reverse
>> endian-ness of filesystem) option to mkcramfs??
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 22 - 24, Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Looks clean and obviously correct to me, but then _everything_ I
write always looks obviously correct to me. - Linus Torvalds in
<Pine.LNX.4.10.10012090054360.791-100000@penguin.transmeta.com>
^ permalink raw reply
* Re: [PATCH][PPC32] Adds mcc cpm commands
From: morten.banzon @ 2005-02-15 19:50 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
Tom Rini <trini@kernel.crashing.org>
15.02.2005 20:23
To: morten.banzon@axxessit.no
cc: linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH][PPC32] Adds mcc cpm commands
On Mon, Feb 14, 2005 at 01:56:07PM +0100, morten.banzon@axxessit.no wrote:
>> This patch adds mcc cpm commands to the cpm2.h file in the 2.6.10
kernel
>>
>> Signed-off-by: Morten Banzon <morten.banzon at axxessit.no>
> What is this used for / needed by? Thanks.
> --
> Tom Rini
> http://gate.crashing.org/~trini/
This is needed for a MPC82xx MCC driver. Curently no MCC driver is in the
kernel.
My intention is to supply more patches with definitions for MCC interrupts
and buffer descriptors, if there is acceptance for such.
Even if no MCC driver is currently in the kernel these patches could go
in. They do not break anything, only easy the job for those who need a MCC
driver, like me :-)
-- Morten
^ permalink raw reply
* Re: [PATCH][PPC32] Adds mcc cpm commands
From: Tom Rini @ 2005-02-15 19:23 UTC (permalink / raw)
To: morten.banzon; +Cc: linuxppc-embedded
In-Reply-To: <OFAFAEBEE5.967C7189-ONC1256FA8.0046506F-C1256FA8.00471593@axxessit.no>
On Mon, Feb 14, 2005 at 01:56:07PM +0100, morten.banzon@axxessit.no wrote:
> This patch adds mcc cpm commands to the cpm2.h file in the 2.6.10 kernel
>
> Signed-off-by: Morten Banzon <morten.banzon at axxessit.no>
What is this used for / needed by? Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: Mounta Vista Linux prompt on serial console
From: srinivas.surabhi @ 2005-02-15 13:34 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]
My replies in blue tagged with surabhi
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: Tuesday, February 15, 2005 5:24 PM
To: Srinivas Surabhi (WT01 - EMBEDDED & PRODUCT ENGINEERING SOLUTIONS)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Mounta Vista Linux prompt on serial console
In message
<EF9B29C78F41FA488927FCBC7750AF0E011DA5C5@hyd-mdp-msg.wipro.com> you
wrote:
>
> Today somehow after removing many options I build the kernel and able
to
> succeed till the VFS: "Mounted root (cramfs filesystem) readonly." But
> then I am seeming "kernel panic". Actually what option has to be given
> for init. We have given init=/bin/sh but no luck.
You have to provide a working root filesystem in the first place.
[surabhi --- start] could you please guide me how to provide a working
file system on SDRAM before decompressing the Linux Image on SDRAM. Is
it really related to init process failed.
Is the below doesn't mean that the mounted one is working one ?
"VFS: Mounted root (cramfs filesystem) readonly.
Mounted devfs on /dev "
[surabhi --- end]
> One more observation is that the U-boot bootargs are overwriting the
> Kernel boot arguments given at the time of build. Even though using
This is normal. If you use U-boot there is no need to have any
pre-compiled boot arguments; more: there is no need to use the whole
bootstrap loader which supplied these precompiled bootargs.
> setenv I removed the bootargs but still the kernel arguments given at
> the time of build using devrocket are not still active.
Just define the required bootargs in U-Boot.
> VFS: Mounted root (cramfs filesystem) readonly.
> Mounted devfs on /dev
> Freeing unused kernel memory: 60k init
> Warning: unable to open an initial console.
> Error -3 while decompressing!
Do not ignore this error. How big is your cramfs iage? How much RAM
do you have?
> 0015fd20(1928974736)->00141000(4096)
Is there any chance that you built your cramfs image on a x08 (or any
other little-endian) system and forgot to give the "-r" (reverse
endian-ness of filesystem) option to mkcramfs??
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 22 - 24, Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
In the strict scientific sense we all feed on death -- even
vegetarians.
-- Spock, "Wolf in the Fold", stardate 3615.4
Confidentiality Notice
The information contained in this electronic message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
[-- Attachment #2: Type: text/html, Size: 11678 bytes --]
^ permalink raw reply
* Re: Mounta Vista Linux prompt on serial console
From: Wolfgang Denk @ 2005-02-15 11:53 UTC (permalink / raw)
To: srinivas.surabhi; +Cc: linuxppc-embedded
In-Reply-To: <EF9B29C78F41FA488927FCBC7750AF0E011DA5C5@hyd-mdp-msg.wipro.com>
In message <EF9B29C78F41FA488927FCBC7750AF0E011DA5C5@hyd-mdp-msg.wipro.com> you wrote:
>
> Today somehow after removing many options I build the kernel and able to
> succeed till the VFS: "Mounted root (cramfs filesystem) readonly." But
> then I am seeming "kernel panic". Actually what option has to be given
> for init. We have given init=/bin/sh but no luck.
You have to provide a working root filesystem in the first place.
> One more observation is that the U-boot bootargs are overwriting the
> Kernel boot arguments given at the time of build. Even though using
This is normal. If you use U-boot there is no need to have any
pre-compiled boot arguments; more: there is no need to use the whole
bootstrap loader which supplied these precompiled bootargs.
> setenv I removed the bootargs but still the kernel arguments given at
> the time of build using devrocket are not still active.
Just define the required bootargs in U-Boot.
> VFS: Mounted root (cramfs filesystem) readonly.
> Mounted devfs on /dev
> Freeing unused kernel memory: 60k init
> Warning: unable to open an initial console.
> Error -3 while decompressing!
Do not ignore this error. How big is your cramfs iage? How much RAM
do you have?
> 0015fd20(1928974736)->00141000(4096)
Is there any chance that you built your cramfs image on a x08 (or any
other little-endian) system and forgot to give the "-r" (reverse
endian-ness of filesystem) option to mkcramfs??
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 22 - 24, Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
In the strict scientific sense we all feed on death -- even
vegetarians.
-- Spock, "Wolf in the Fold", stardate 3615.4
^ permalink raw reply
* RE: Mounta Vista Linux prompt on serial console
From: srinivas.surabhi @ 2005-02-15 10:32 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
Hi,
Today somehow after removing many options I build the kernel and able to
succeed till the VFS: "Mounted root (cramfs filesystem) readonly." But
then I am seeming "kernel panic". Actually what option has to be given
for init. We have given init=3D/bin/sh but no luck.
Please pull me out.
One more observation is that the U-boot bootargs are overwriting the
Kernel boot arguments given at the time of build. Even though using
setenv I removed the bootargs but still the kernel arguments given at
the time of build using devrocket are not still active.
The end part on the hyperterminal is given below
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 2640k freed
VFS: Mounted root (cramfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 60k init
Warning: unable to open an initial console.
Error -3 while decompressing!
0015fd20(1928974736)->00141000(4096)
Kernel panic: No init found. Try passing init=3D option to kernel.
<0>Rebooting in 180 seconds..
Thanks & Regards
Surabhi Srinivas
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]=0D
Sent: Tuesday, February 15, 2005 3:20 AM
To: Srinivas Surabhi (WT01 - EMBEDDED & PRODUCT ENGINEERING SOLUTIONS)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Mounta Vista Linux prompt on serial console=0D
In message
<EF9B29C78F41FA488927FCBC7750AF0E011DA5A1@hyd-mdp-msg.wipro.com> you
wrote:
>=0D
> Our target is somewhat like this. It has PPC8270, Flash and SDRAM. We
> are using the uboot for booting. Successfully built the linux kernel
and
> Ramdisk images using devrocket. The problem is that the kernel and
Are you sure that your Linux kernel is configured to be booted by
U-Boot?
> Ramdisk images although getting extracted successfully to 0M location
of
> SDRAM from Flash with the help of uboot, the serial console says
nothing
> except "uboot ist nicht tot..."
Funny. This message is neiter part of the standard U-Boot code nor of
the standard Linux kernel. Try to find out where this code is coming
from.
> 1. How do I know that the control was given to linux kernel?
Set a breakpoint at a low address like 0x000C. If the debugger stops
there you are executing Linux kernel code.
Alternatively, enable DEBUG when building your U-Boot image (at least
when compiling file "common/cmd_bootm.c").
> 2. Is it that the linux kernel got the control but unable to put the
> prompt on the serial line? FYI. I modified the inittab to reflect the
> console to come on the serial line.
Inittab has nothing to do with the kernel's startup messages. Is your
kernel configured correctly for using a serial console?
> 3. Is there any documentation which gives the detailed debugging of
the
> linux kernel from the loading of kernel?
This is partially covered in the DULG, see
http://www.denx.de/twiki/bin/view/DULG/Manual
Best regards,
Wolfgang Denk
--=0D
See us @ Embedded World, Nuremberg, Feb 22 - 24, Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Cogito cogito ergo cogito sum - "I think that I think, therefore I
think that I am." - Ambrose Bierce, "The Devil's Dictionary"
Confidentiality Notice=0D
The information contained in this electronic message and any attachments to=
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or=
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or=
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
^ permalink raw reply
* Stuck in booting 2.6.10-ac11 on Memec Design FF1152...
From: Jakob Viketoft @ 2005-02-15 10:19 UTC (permalink / raw)
To: Linux PPC Embedded list
Hello everyone!
I seem to be promptly stuck at a place in booting (and has been for a
while now) so I figured I'd ask the list and see if anyone of you has
any ideas. This is all on a Memec Design FF1152 Rev. 3 Evaluation board
containing a XC2VP20 Virtex-II pro chip (two ppc 405GP processors).
Since the excellent Xilinx tools crash on ELF files, the only option is
to download a binary and debug using the serial port.
After enabling SERIAL_DEBUG_IO_BASE to the serial port, the last
printout is "MMU:exit()". Checking the PC and the System.map, I seem to
halt in the function __delay() which I believe is the function in
arch/ppc/kernel/misc.S since it's global. Now, I have two problems:
1. How does it get to (and get stuck in) __delay()? Can it be triggered
by some interrupt if the controller isn't properly configured or is it
called from init/main.c and there is some missing timer
(initialization)? Looking at Andrei Konovalovs ML300 setup I can't see
any external timer configured...
2. gen550_progress() (or something else) seem to be hogging the console
(serial port) one way or the other, disabling printk() and making it
much harder to debug. Any suggestions how I could deal with this? The
serial device is a generic 16550 UART (Xilinx made).
Thanks in advance!
/Jakob
(PS. Andrei: You seem to be using a DCR_INTC on your card and yet
setting the parameter USE_DCR set to 0. Why is that?)
^ permalink raw reply
* QSlinux dead?
From: David Jander @ 2005-02-15 9:59 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am looking for some pointers to people who work on QSlinux, or if it's dead,
who know where I can ge the source.
I went to www.qslinux.org, but the links there are mostly dead, all e-mail
sent to addresses listed on the support page of snmc (the makers of qs)
bounce back.
Does anybody on this list know what's happening to SNMC (QSlinux)?
They claim to have developed several MPC8xx drivers, released under GPL, but
as of today I am unable to find a trace of them. Only thing left is calling
the phone number listed on their site, but I figured that I might better ask
around here first.
Greetings,
--
David Jander
^ permalink raw reply
* Reading of RTC
From: robin @ 2005-02-15 9:39 UTC (permalink / raw)
To: linux-ppc-embedded
In-Reply-To: <20050210150437.GA19134@logos.cnet>
Hi,
Can you please give me some info during system initialization?
1. Which file does the reading of RTC to set the system time?
In redhat, i have seen that the RTC is set from the script=20
/etc/rc.d/rc.sysinit. But my MPC /etc/rc.d/rc.sysinit does
not seem to do anything like that:(
2. How does the kernel interprets the time read from the RTC?
Is it interpreted as UTC or the local time?? Or is it configurable??
I am running denx kernel 2.4.20
Regards,
Robin
--=20
Dreams are free, but you get soaked on the connect time.
^ permalink raw reply
* (no subject)
From: Yuli Barcohen @ 2005-02-15 9:35 UTC (permalink / raw)
To: Markus Westergren; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.50.0502142031110.28518-100000@220a.licentiaten.umea.hsb.se>
>>>>> Markus Westergren writes:
Markus> The board in my project is almost like a Adder875 but unlike
Markus> the Adder it has a PCMCIA slot connected.
No problems, it's supported
Markus> I have tested a version of Arabella (FREE v2.1, kernel
Markus> 2.4.25). It looks like that the fec driver only supports
Markus> general PHY and no link interrupts.
Yes, because nobody of our customers needed PHY-specific support. It's
trivial to add if necessary.
--
========================================================================
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] Non-DMA mode for floppy on PowerPC
From: Pavel Fedin @ 2005-02-15 15:31 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 753 bytes --]
This patch allows to use floppy drive in non-DMA mode on PegasosPPC machines. To use it:
1. Do not build floppy driver as a module, link it statically. Transferring parameters to it from insmod is still problematic, at least it doesn't work properly on my system. May be i'll clean it up in future.
2. Specify floppy=nodma in kernel's arguments. Also you'll need to specify your drive type there using floppy=<Drive number>,<Drive type>,cmos. For example, floppy=0,4,cmos specifies type 4 (1.44 mb 3.5") for drive 0 on my system.
This patch does not affect operation of the driver in DMA mode so it's safe to use on any platform.
The patch was done using kernel version 2.6.8.
--
Best regards,
Pavel Fedin, mailto:sonic_amiga@rambler.ru
[-- Attachment #2: ppc_floppy-vdma.diff --]
[-- Type: text/plain, Size: 5681 bytes --]
--- include/asm-ppc/floppy.h.orig 2004-08-14 09:36:45.000000000 +0400
+++ include/asm-ppc/floppy.h 2005-02-12 02:26:54.000000000 +0300
@@ -11,30 +11,188 @@
#ifndef __ASM_PPC_FLOPPY_H
#define __ASM_PPC_FLOPPY_H
+#include <linux/vmalloc.h>
+
+#define CSW fd_routine[can_use_virtual_dma & 1]
+
#define fd_inb(port) inb_p(port)
#define fd_outb(value,port) outb_p(value,port)
-#define fd_enable_dma() enable_dma(FLOPPY_DMA)
-#define fd_disable_dma() disable_dma(FLOPPY_DMA)
-#define fd_request_dma() request_dma(FLOPPY_DMA,"floppy")
-#define fd_free_dma() free_dma(FLOPPY_DMA)
-#define fd_clear_dma_ff() clear_dma_ff(FLOPPY_DMA)
-#define fd_set_dma_mode(mode) set_dma_mode(FLOPPY_DMA,mode)
-#define fd_set_dma_addr(addr) set_dma_addr(FLOPPY_DMA,(unsigned int)virt_to_bus(addr))
-#define fd_set_dma_count(count) set_dma_count(FLOPPY_DMA,count)
+#define fd_disable_dma() CSW._disable_dma(FLOPPY_DMA)
+#define fd_request_dma() CSW._request_dma(FLOPPY_DMA,"floppy")
+#define fd_free_dma() CSW._free_dma(FLOPPY_DMA)
+#define fd_get_dma_residue() CSW._get_dma_residue(FLOPPY_DMA)
+#define fd_dma_mem_alloc(size) CSW._dma_mem_alloc(size)
+#define fd_dma_setup(addr, size, mode, io) CSW._dma_setup(addr, size, mode, io)
#define fd_enable_irq() enable_irq(FLOPPY_IRQ)
#define fd_disable_irq() disable_irq(FLOPPY_IRQ)
-#define fd_cacheflush(addr,size) /* nothing */
-#define fd_request_irq() request_irq(FLOPPY_IRQ, floppy_interrupt, \
- SA_INTERRUPT|SA_SAMPLE_RANDOM, \
- "floppy", NULL)
#define fd_free_irq() free_irq(FLOPPY_IRQ, NULL);
-__inline__ void virtual_dma_init(void)
+static int virtual_dma_count;
+static int virtual_dma_residue;
+static char *virtual_dma_addr;
+static int virtual_dma_mode;
+static int doing_pdma;
+
+static irqreturn_t floppy_hardint(int irq, void *dev_id, struct pt_regs * regs)
+{
+ register unsigned char st;
+
+#undef TRACE_FLPY_INT
+
+#ifdef TRACE_FLPY_INT
+ static int calls=0;
+ static int bytes=0;
+ static int dma_wait=0;
+#endif
+ if (!doing_pdma)
+ return floppy_interrupt(irq, dev_id, regs);
+
+#ifdef TRACE_FLPY_INT
+ if(!calls)
+ bytes = virtual_dma_count;
+#endif
+ {
+ register int lcount;
+ register char *lptr;
+
+ st = 1;
+ for(lcount=virtual_dma_count, lptr=virtual_dma_addr;
+ lcount; lcount--, lptr++) {
+ st=inb(virtual_dma_port+4) & 0xa0 ;
+ if(st != 0xa0)
+ break;
+ if(virtual_dma_mode)
+ outb_p(*lptr, virtual_dma_port+5);
+ else
+ *lptr = inb_p(virtual_dma_port+5);
+ }
+ virtual_dma_count = lcount;
+ virtual_dma_addr = lptr;
+ st = inb(virtual_dma_port+4);
+ }
+
+#ifdef TRACE_FLPY_INT
+ calls++;
+#endif
+ if(st == 0x20)
+ return IRQ_HANDLED;
+ if(!(st & 0x20)) {
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
+#ifdef TRACE_FLPY_INT
+ printk("count=%x, residue=%x calls=%d bytes=%d dma_wait=%d\n",
+ virtual_dma_count, virtual_dma_residue, calls, bytes,
+ dma_wait);
+ calls = 0;
+ dma_wait=0;
+#endif
+ doing_pdma = 0;
+ floppy_interrupt(irq, dev_id, regs);
+ return IRQ_HANDLED;
+ }
+#ifdef TRACE_FLPY_INT
+ if(!virtual_dma_count)
+ dma_wait++;
+#endif
+ return IRQ_HANDLED;
+}
+
+static void vdma_disable_dma(unsigned int dummy)
{
- /* Nothing to do on PowerPC */
+ doing_pdma = 0;
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
}
+static int vdma_request_dma(unsigned int dmanr, const char * device_id)
+{
+ return 0;
+}
+
+static void vdma_nop(unsigned int dummy)
+{
+}
+
+
+static int vdma_get_dma_residue(unsigned int dummy)
+{
+ return virtual_dma_count + virtual_dma_residue;
+}
+
+
+static int fd_request_irq(void)
+{
+ if(can_use_virtual_dma)
+ return request_irq(FLOPPY_IRQ, floppy_hardint,SA_INTERRUPT,
+ "floppy", NULL);
+ else
+ return request_irq(FLOPPY_IRQ, floppy_interrupt,
+ SA_INTERRUPT|SA_SAMPLE_RANDOM,
+ "floppy", NULL);
+
+}
+
+static inline unsigned long dma_mem_alloc(unsigned long size)
+{
+ return __get_dma_pages(GFP_KERNEL,get_order(size));
+}
+
+
+static inline unsigned long vdma_mem_alloc(unsigned long size)
+{
+ return __get_free_pages(GFP_KERNEL,get_order(size));
+}
+
+static int vdma_dma_setup(char *addr, unsigned long size, int mode, int io)
+{
+ doing_pdma = 1;
+ virtual_dma_port = io;
+ virtual_dma_mode = (mode == DMA_MODE_WRITE);
+ virtual_dma_addr = addr;
+ virtual_dma_count = size;
+ virtual_dma_residue = 0;
+ return 0;
+}
+
+static int hard_dma_setup(char *addr, unsigned long size, int mode, int io)
+{
+ /* actual, physical DMA */
+ doing_pdma = 0;
+ clear_dma_ff(FLOPPY_DMA);
+ set_dma_mode(FLOPPY_DMA,mode);
+ set_dma_addr(FLOPPY_DMA,(unsigned int)virt_to_bus(addr));
+ set_dma_count(FLOPPY_DMA,size);
+ enable_dma(FLOPPY_DMA);
+ return 0;
+}
+
+struct fd_routine_l {
+ void (*_disable_dma)(unsigned int dmanr);
+ int (*_request_dma)(unsigned int dmanr, const char * device_id);
+ void (*_free_dma)(unsigned int dmanr);
+ int (*_get_dma_residue)(unsigned int dummy);
+ unsigned long (*_dma_mem_alloc) (unsigned long size);
+ int (*_dma_setup)(char *addr, unsigned long size, int mode, int io);
+} fd_routine[] = {
+ {
+ disable_dma,
+ request_dma,
+ free_dma,
+ get_dma_residue,
+ dma_mem_alloc,
+ hard_dma_setup
+ },
+ {
+ vdma_disable_dma,
+ vdma_request_dma,
+ vdma_nop,
+ vdma_get_dma_residue,
+ vdma_mem_alloc,
+ vdma_dma_setup
+ }
+};
+
static int FDC1 = 0x3f0;
static int FDC2 = -1;
^ permalink raw reply
* [PATCH] Consolidate compat_sys_waitid
From: Stephen Rothwell @ 2005-02-15 3:01 UTC (permalink / raw)
To: LKML; +Cc: tony.luck, willy, ak, ralf, paulus, schwidefsky, davem
Hi all,
This patch does:
- consolidate the three implementations of compat_sys_waitid
(some were called sys32_waitid).
- adds sys_waitid syscall to ppc
- adds sys_waitid and compat_sys_waitid syscalls to ppc64
Parisc seemed to assume th existance of compat_sys_waitid. The MIPS
syscall tables have me confused and may need updating. I have arbitrarily
chosen the next available syscall number on ppc and ppc64, I hope this is
correct.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Comments?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff -ruNp linus-bk/arch/ia64/ia32/ia32_entry.S linus-bk-waitid.1/arch/ia64/ia32/ia32_entry.S
--- linus-bk/arch/ia64/ia32/ia32_entry.S 2005-01-16 07:07:51.000000000 +1100
+++ linus-bk-waitid.1/arch/ia64/ia32/ia32_entry.S 2005-02-15 12:12:21.000000000 +1100
@@ -494,7 +494,7 @@ ia32_syscall_table:
data8 compat_sys_mq_notify
data8 compat_sys_mq_getsetattr
data8 sys_ni_syscall /* reserved for kexec */
- data8 sys32_waitid
+ data8 compat_sys_waitid
// guard against failures to increase IA32_NR_syscalls
.org ia32_syscall_table + 8*IA32_NR_syscalls
diff -ruNp linus-bk/arch/ia64/ia32/sys_ia32.c linus-bk-waitid.1/arch/ia64/ia32/sys_ia32.c
--- linus-bk/arch/ia64/ia32/sys_ia32.c 2005-02-11 13:05:29.000000000 +1100
+++ linus-bk-waitid.1/arch/ia64/ia32/sys_ia32.c 2005-02-15 12:16:35.000000000 +1100
@@ -2633,32 +2633,6 @@ long sys32_fadvise64_64(int fd, __u32 of
advice);
}
-asmlinkage long sys32_waitid(int which, compat_pid_t pid,
- compat_siginfo_t __user *uinfo, int options,
- struct compat_rusage __user *uru)
-{
- siginfo_t info;
- struct rusage ru;
- long ret;
- mm_segment_t old_fs = get_fs();
-
- info.si_signo = 0;
- set_fs (KERNEL_DS);
- ret = sys_waitid(which, pid, (siginfo_t __user *) &info, options,
- uru ? (struct rusage __user *) &ru : NULL);
- set_fs (old_fs);
-
- if (ret < 0 || info.si_signo == 0)
- return ret;
-
- if (uru && (ret = put_compat_rusage(&ru, uru)))
- return ret;
-
- BUG_ON(info.si_code & __SI_MASK);
- info.si_code |= __SI_CHLD;
- return copy_siginfo_to_user32(uinfo, &info);
-}
-
#ifdef NOTYET /* UNTESTED FOR IA64 FROM HERE DOWN */
asmlinkage long sys32_setreuid(compat_uid_t ruid, compat_uid_t euid)
diff -ruNp linus-bk/arch/ppc/kernel/misc.S linus-bk-waitid.1/arch/ppc/kernel/misc.S
--- linus-bk/arch/ppc/kernel/misc.S 2005-01-04 17:05:28.000000000 +1100
+++ linus-bk-waitid.1/arch/ppc/kernel/misc.S 2005-02-15 13:12:01.000000000 +1100
@@ -1450,3 +1450,4 @@ _GLOBAL(sys_call_table)
.long sys_add_key
.long sys_request_key /* 270 */
.long sys_keyctl
+ .long sys_waitid
diff -ruNp linus-bk/arch/ppc64/kernel/misc.S linus-bk-waitid.1/arch/ppc64/kernel/misc.S
--- linus-bk/arch/ppc64/kernel/misc.S 2005-01-16 07:07:51.000000000 +1100
+++ linus-bk-waitid.1/arch/ppc64/kernel/misc.S 2005-02-15 13:13:51.000000000 +1100
@@ -939,6 +939,7 @@ _GLOBAL(sys_call_table32)
.llong .sys32_add_key
.llong .sys32_request_key
.llong .compat_sys_keyctl
+ .llong .compat_sys_waitid
.balign 8
_GLOBAL(sys_call_table)
@@ -1214,3 +1215,4 @@ _GLOBAL(sys_call_table)
.llong .sys_add_key
.llong .sys_request_key /* 270 */
.llong .sys_keyctl
+ .llong .sys_waitid
diff -ruNp linus-bk/arch/sparc64/kernel/sys_sparc32.c linus-bk-waitid.1/arch/sparc64/kernel/sys_sparc32.c
--- linus-bk/arch/sparc64/kernel/sys_sparc32.c 2005-02-11 13:05:29.000000000 +1100
+++ linus-bk-waitid.1/arch/sparc64/kernel/sys_sparc32.c 2005-02-15 12:01:55.000000000 +1100
@@ -1653,34 +1653,3 @@ sys32_timer_create(u32 clock, struct sig
return err;
}
-
-asmlinkage long compat_sys_waitid(u32 which, u32 pid,
- struct compat_siginfo __user *uinfo,
- u32 options, struct compat_rusage __user *uru)
-{
- siginfo_t info;
- struct rusage ru;
- long ret;
- mm_segment_t old_fs = get_fs();
-
- memset(&info, 0, sizeof(info));
-
- set_fs (KERNEL_DS);
- ret = sys_waitid(which, pid, (siginfo_t __user *) &info,
- options,
- uru ? (struct rusage __user *) &ru : NULL);
- set_fs (old_fs);
-
- if (ret < 0 || info.si_signo == 0)
- return ret;
-
- if (uru) {
- ret = put_compat_rusage(&ru, uru);
- if (ret)
- return ret;
- }
-
- BUG_ON(info.si_code & __SI_MASK);
- info.si_code |= __SI_CHLD;
- return copy_siginfo_to_user32(uinfo, &info);
-}
diff -ruNp linus-bk/arch/x86_64/ia32/ia32entry.S linus-bk-waitid.1/arch/x86_64/ia32/ia32entry.S
--- linus-bk/arch/x86_64/ia32/ia32entry.S 2005-01-16 11:05:29.000000000 +1100
+++ linus-bk-waitid.1/arch/x86_64/ia32/ia32entry.S 2005-02-15 12:11:52.000000000 +1100
@@ -590,7 +590,7 @@ ia32_sys_call_table:
.quad compat_sys_mq_notify
.quad compat_sys_mq_getsetattr
.quad quiet_ni_syscall /* reserved for kexec */
- .quad sys32_waitid
+ .quad compat_sys_waitid
.quad quiet_ni_syscall /* sys_altroot */
.quad sys_add_key
.quad sys_request_key
diff -ruNp linus-bk/arch/x86_64/ia32/sys_ia32.c linus-bk-waitid.1/arch/x86_64/ia32/sys_ia32.c
--- linus-bk/arch/x86_64/ia32/sys_ia32.c 2005-02-04 04:10:36.000000000 +1100
+++ linus-bk-waitid.1/arch/x86_64/ia32/sys_ia32.c 2005-02-15 12:17:04.000000000 +1100
@@ -955,32 +955,6 @@ asmlinkage long sys32_clone(unsigned int
return do_fork(clone_flags, newsp, regs, 0, parent_tid, child_tid);
}
-asmlinkage long sys32_waitid(int which, compat_pid_t pid,
- compat_siginfo_t __user *uinfo, int options,
- struct compat_rusage __user *uru)
-{
- siginfo_t info;
- struct rusage ru;
- long ret;
- mm_segment_t old_fs = get_fs();
-
- info.si_signo = 0;
- set_fs (KERNEL_DS);
- ret = sys_waitid(which, pid, (siginfo_t __user *) &info, options,
- uru ? &ru : NULL);
- set_fs (old_fs);
-
- if (ret < 0 || info.si_signo == 0)
- return ret;
-
- if (uru && (ret = put_compat_rusage(&ru, uru)))
- return ret;
-
- BUG_ON(info.si_code & __SI_MASK);
- info.si_code |= __SI_CHLD;
- return copy_siginfo_to_user32(uinfo, &info);
-}
-
/*
* Some system calls that need sign extended arguments. This could be done by a generic wrapper.
*/
diff -ruNp linus-bk/include/asm-ppc/unistd.h linus-bk-waitid.1/include/asm-ppc/unistd.h
--- linus-bk/include/asm-ppc/unistd.h 2005-01-04 17:05:28.000000000 +1100
+++ linus-bk-waitid.1/include/asm-ppc/unistd.h 2005-02-15 13:08:22.000000000 +1100
@@ -276,8 +276,9 @@
#define __NR_add_key 269
#define __NR_request_key 270
#define __NR_keyctl 271
+#define __NR_waitid 272
-#define __NR_syscalls 272
+#define __NR_syscalls 273
#define __NR(n) #n
diff -ruNp linus-bk/include/asm-ppc64/unistd.h linus-bk-waitid.1/include/asm-ppc64/unistd.h
--- linus-bk/include/asm-ppc64/unistd.h 2005-01-05 17:06:08.000000000 +1100
+++ linus-bk-waitid.1/include/asm-ppc64/unistd.h 2005-02-15 13:07:33.000000000 +1100
@@ -282,8 +282,9 @@
#define __NR_add_key 269
#define __NR_request_key 270
#define __NR_keyctl 271
+#define __NR_waitid 272
-#define __NR_syscalls 272
+#define __NR_syscalls 273
#ifdef __KERNEL__
#define NR_syscalls __NR_syscalls
#endif
diff -ruNp linus-bk/include/linux/compat.h linus-bk-waitid.1/include/linux/compat.h
--- linus-bk/include/linux/compat.h 2005-01-05 17:06:08.000000000 +1100
+++ linus-bk-waitid.1/include/linux/compat.h 2005-02-15 13:22:13.000000000 +1100
@@ -81,6 +81,12 @@ struct compat_rusage {
extern int put_compat_rusage(const struct rusage *, struct compat_rusage __user *);
+struct compat_siginfo;
+
+extern asmlinkage long compat_sys_waitid(u32, u32,
+ struct compat_siginfo __user *, u32,
+ struct compat_rusage __user *);
+
struct compat_dirent {
u32 d_ino;
compat_off_t d_off;
@@ -143,7 +149,6 @@ long compat_get_bitmap(unsigned long *ma
unsigned long bitmap_size);
long compat_put_bitmap(compat_ulong_t __user *umask, unsigned long *mask,
unsigned long bitmap_size);
-struct compat_siginfo;
int copy_siginfo_from_user32(siginfo_t *to, struct compat_siginfo __user *from);
int copy_siginfo_to_user32(struct compat_siginfo __user *to, siginfo_t *from);
#endif /* CONFIG_COMPAT */
diff -ruNp linus-bk/kernel/compat.c linus-bk-waitid.1/kernel/compat.c
--- linus-bk/kernel/compat.c 2005-01-16 07:07:51.000000000 +1100
+++ linus-bk-waitid.1/kernel/compat.c 2005-02-15 12:09:46.000000000 +1100
@@ -23,6 +23,7 @@
#include <linux/security.h>
#include <asm/uaccess.h>
+#include <asm/bug.h>
int get_compat_timespec(struct timespec *ts, const struct compat_timespec __user *cts)
{
@@ -413,6 +414,36 @@ compat_sys_wait4(compat_pid_t pid, compa
}
}
+asmlinkage long compat_sys_waitid(u32 which, u32 pid,
+ struct compat_siginfo __user *uinfo, u32 options,
+ struct compat_rusage __user *uru)
+{
+ siginfo_t info;
+ struct rusage ru;
+ long ret;
+ mm_segment_t old_fs = get_fs();
+
+ memset(&info, 0, sizeof(info));
+
+ set_fs(KERNEL_DS);
+ ret = sys_waitid(which, pid, (siginfo_t __user *)&info, options,
+ uru ? (struct rusage __user *)&ru : NULL);
+ set_fs(old_fs);
+
+ if ((ret < 0) || (info.si_signo == 0))
+ return ret;
+
+ if (uru) {
+ ret = put_compat_rusage(&ru, uru);
+ if (ret)
+ return ret;
+ }
+
+ BUG_ON(info.si_code & __SI_MASK);
+ info.si_code |= __SI_CHLD;
+ return copy_siginfo_to_user32(uinfo, &info);
+}
+
static int compat_get_user_cpu_mask(compat_ulong_t __user *user_mask_ptr,
unsigned len, cpumask_t *new_mask)
{
^ permalink raw reply
* kernprof patches for ppc?
From: Chris Friesen @ 2005-02-14 22:37 UTC (permalink / raw)
To: linuxppc-dev
Hi guys,
I'm trying to track down a long-running code path on a UP 2.4.22 system
running on an mcpn765 card. It's got various vendor patches and drivers
applied, and *something* is taking up to a second in the kernel very
intermittantly.
Has anyone ported kernprof to ppc for 2.4?
Chris
^ permalink raw reply
* Re: Mounta Vista Linux prompt on serial console
From: Wolfgang Denk @ 2005-02-14 21:49 UTC (permalink / raw)
To: srinivas.surabhi; +Cc: linuxppc-embedded
In-Reply-To: <EF9B29C78F41FA488927FCBC7750AF0E011DA5A1@hyd-mdp-msg.wipro.com>
In message <EF9B29C78F41FA488927FCBC7750AF0E011DA5A1@hyd-mdp-msg.wipro.com> you wrote:
>
> Our target is somewhat like this. It has PPC8270, Flash and SDRAM. We
> are using the uboot for booting. Successfully built the linux kernel and
> Ramdisk images using devrocket. The problem is that the kernel and
Are you sure that your Linux kernel is configured to be booted by U-Boot?
> Ramdisk images although getting extracted successfully to 0M location of
> SDRAM from Flash with the help of uboot, the serial console says nothing
> except "uboot ist nicht tot..."
Funny. This message is neiter part of the standard U-Boot code nor of
the standard Linux kernel. Try to find out where this code is coming
from.
> 1. How do I know that the control was given to linux kernel?
Set a breakpoint at a low address like 0x000C. If the debugger stops
there you are executing Linux kernel code.
Alternatively, enable DEBUG when building your U-Boot image (at least
when compiling file "common/cmd_bootm.c").
> 2. Is it that the linux kernel got the control but unable to put the
> prompt on the serial line? FYI. I modified the inittab to reflect the
> console to come on the serial line.
Inittab has nothing to do with the kernel's startup messages. Is your
kernel configured correctly for using a serial console?
> 3. Is there any documentation which gives the detailed debugging of the
> linux kernel from the loading of kernel?
This is partially covered in the DULG, see
http://www.denx.de/twiki/bin/view/DULG/Manual
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 22 - 24, Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Cogito cogito ergo cogito sum - "I think that I think, therefore I
think that I am." - Ambrose Bierce, "The Devil's Dictionary"
^ permalink raw reply
* Re: Support for Adder875 in Linux 2.4
From: Markus Westergren @ 2005-02-14 19:47 UTC (permalink / raw)
To: Jan Damborsky; +Cc: linuxppc-embedded
In-Reply-To: <42109B82.9070604@devcom.cz>
On Mon, 14 Feb 2005, Jan Damborsky wrote:
> Markus Westergren wrote:
>
> >Hi,
> >
> >I'm working on a project which will use hardware based on Analogue & Micro
> >Adder875 module together with Linux 2.4.
> >
> >I use RedBoot as bootloader and kernel 2.4.27-pre1, both came with the Adder
> >module.
> >
> >The project require:
> >
> > - dual ethernet support with AM79C874 PHY
> > The driver I've found (fec.c) only supports one ethernet. I'v started
> > modifying a newer version of this driver which have support for my PHY. I
> > have made some progress but it's not working yet. Found out that the first
> > FEC is used to communicate with both PHY's. Both devices are detected
> > correctly and the first seems to work but the second hangs the kernel when
> > the first packet is sent or received.
> >
> >
> We use our proprietary board with MPC880, dual ethernet + Am79C874 PHY.
> Kernel 2.4.25 (linuxppc_2_4_devel checked out from www.denx.de). Original
> source tree supports only one FEC, but with minor ugly hack we utilize
> both MPC880 FECs
> without problem. If interested, I can send you a patch for get 2nd FEC
> working.
>
I got my board working with both ethernet ports today. I'm interested in your
patch so that I can see if we made the same ugly hack and if I have overlocked
something :)
/Markus
^ permalink raw reply
* Re: Support for Adder875 in Linux 2.4
From: Markus Westergren @ 2005-02-14 19:44 UTC (permalink / raw)
To: Yuli Barcohen; +Cc: linuxppc-embedded
In-Reply-To: <16912.18711.885679.679568@astp0002.localdomain>
On Mon, 14 Feb 2005, Yuli Barcohen wrote:
> >>>>> Markus Westergren writes:
>
> Markus> Hi, I'm working on a project which will use hardware based
> Markus> on Analogue & Micro Adder875 module together with Linux 2.4.
>
> Markus> I use RedBoot as bootloader and kernel 2.4.27-pre1, both
> Markus> came with the Adder module.
>
> Markus> The project require:
>
> Markus> - dual ethernet support with AM79C874 PHY
> Markus> The driver I've found (fec.c) only supports one
> Markus> ethernet. I'v started
> Markus> modifying a newer version of this driver which have
> Markus> support for my PHY. I have made some progress but it's
> Markus> not working yet. Found out that the first FEC is used to
> Markus> communicate with both PHY's. Both devices are detected
> Markus> correctly and the first seems to work but the second
> Markus> hangs the kernel when the first packet is sent or
> Markus> received.
> Markus> - SPI support
> Markus> Have found a simple driver (cpm_spi.c), which I have not
> Markus> tested yet.
> Markus> - PCMCIA support
> Markus> Will try to modify the m8xx_pcmcia driver.
>
> Markus> Not required but would be good to have:
> Markus> - USB host support
> Markus> Have no clue where to start looking.
>
> Markus> Have anyone used this module together with Linux and are
> Markus> there working drivers for it? Any tips/ideas?
>
> Arabella Linux supports all these. Not sure how you are going to use
> PCMCIA on this specific board - it's not connected.
>
The board in my project is almost like a Adder875 but unlike the Adder it has a
PCMCIA slot connected.
I have tested a version of Arabella (FREE v2.1, kernel 2.4.25). It looks like
that the fec driver only supports general PHY and no link interrupts.
/Markus
^ 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