* Joystick and Lite5200
From: Alan Carvalho @ 2005-11-28 15:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 6533 bytes --]
Hi all,
I am trying use Logitech WingMan Strike Force 3D on Lite5200 board. I am
using linux-2.6.14 Denx's tree, just selecting this options:
CONFIG_INPUT=y
CONFIG_INPUT_JOYDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_EVBUG=y
and
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
CONFIG_HID_FF=y
CONFIG_LOGITECH_FF=y
As my device ID is not listed in hid-ff.c and hid-lgff.c, then I mapped it:
drivers/usb/input/hid-ff.c :
{0x46d, 0xc285, hid_lgff_init}, // Logitech Wingman Strike Force 3d
drivers/usb/input/hid-lgff.c
{0x046d, 0xc285, ff_joystick},
(I need do it in the PC to force feedback work fine too)
But the problem is the driver is not working correctly, if I try open
/dev/input/event0 it return "No such device", but as you can see below
evbug.c show correctly all joystick events.
Suggestions?
Best regard,
Alan
/ # dmesg
...
usbmon: debugfs is not available
2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PPC SOC)
block sizes: ed 64 td 64
initializing PPC-SOC USB Controller
ppc-soc-ohci ppc-soc-ohci: USB Host Controller
ppc-soc-ohci ppc-soc-ohci: new USB bus registered, assigned bus number 1
ppc-soc-ohci ppc-soc-ohci: irq 44, io mem 0xf0001000
ppc-soc-ohci ppc-soc-ohci: resetting from state 'reset', control = 0x0
ppc-soc-ohci ppc-soc-ohci: OHCI controller state
ppc-soc-ohci ppc-soc-ohci: OHCI 1.0, NO legacy support registers
ppc-soc-ohci ppc-soc-ohci: control 0x083 HCFS=operational CBSR=3
ppc-soc-ohci ppc-soc-ohci: cmdstatus 0x00000 SOC=0
ppc-soc-ohci ppc-soc-ohci: intrstatus 0x00000044 RHSC SF
ppc-soc-ohci ppc-soc-ohci: intrenable 0x8000001a MIE UE RD WDH
ppc-soc-ohci ppc-soc-ohci: hcca frame #0005
ppc-soc-ohci ppc-soc-ohci: roothub.a 02001202 POTPGT=2 NOCP NPS NDP=2(2)
ppc-soc-ohci ppc-soc-ohci: roothub.b 00000000 PPCM=0000 DR=0000
ppc-soc-ohci ppc-soc-ohci: roothub.status 00008000 DRWE
ppc-soc-ohci ppc-soc-ohci: roothub.portstatus [0] 0x00000100 PPS
ppc-soc-ohci ppc-soc-ohci: roothub.portstatus [1] 0x00000100 PPS
ppc-soc-ohci ppc-soc-ohci: created debug files
usb usb1: default language 0x0409
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: USB Host Controller
usb usb1: Manufacturer: Linux 2.6.14 ohci_hcd
usb usb1: SerialNumber: PPC-SOC USB
usb usb1: adding 1-0:1.0 (config #1, interface 0)
hub 1-0:1.0: usb_probe_interface
hub 1-0:1.0: usb_probe_interface - got id
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
hub 1-0:1.0: standalone hub
hub 1-0:1.0: ganged power switching
hub 1-0:1.0: global over-current protection
hub 1-0:1.0: power on to power good time: 4ms
hub 1-0:1.0: local power source is good
hub 1-0:1.0: no over-current condition exists
hub 1-0:1.0: enabling power on all ports
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd: block sizes: ed 64 td 64
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
hub 1-0:1.0: state 5 ports 2 chg 0000 evt 0000
Serial: MPC52xx PSC driver
ttyS0 at MMIO 0xf0002000 (irq = 39) is a MPC52xx PSC
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 64 RAM disks of 4096K size 1024 blocksize
eth0: Phy @ 0x0, type LXT971 (0x001378e2)
Generic platform RAM MTD, (c) 2004 Simtec Electronics
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 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
RAMDISK: Compressed image found at block 0
VFS: Mounted root (romfs filesystem) readonly.
Freeing unused kernel memory: 108k init
hub 1-0:1.0: state 5 ports 2 chg 0000 evt 0002
ppc-soc-ohci ppc-soc-ohci: GetStatus roothub.portstatus [0] = 0x00010301 CSC
LSDA PPS CCS
hub 1-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301
ppc-soc-ohci ppc-soc-ohci: GetStatus roothub.portstatus [0] = 0x00100303
PRSC LSDA PPS PES CCS
usb 1-1: new low speed USB device using ppc-soc-ohci and address 2
ppc-soc-ohci ppc-soc-ohci: GetStatus roothub.portstatus [0] = 0x00100303
PRSC LSDA PPS PES CCS
usb 1-1: skipped 1 descriptor after interface
usb 1-1: default language 0x0409
usb 1-1: new device strings: Mfr=4, Product=32, SerialNumber=0
usb 1-1: Product: WingMan Strike Force 3D
usb 1-1: Manufacturer: Logitech Inc.
usb 1-1: adding 1-1:1.0 (config #1, interface 0)
usbhid 1-1:1.0: usb_probe_interface
usbhid 1-1:1.0: usb_probe_interface - got id
drivers/usb/input/hid-core.c: timeout initializing reports
Force feedback for Logitech force feedback devices by Johann Deneux <
johann.deneux@it.uu.se>
input: Logitech Inc. WingMan Strike Force 3D//class/input as input0
evbug.c: Connected device: "Logitech Inc. WingMan Strike Force 3D",
usb-PPC-SOC USB-1/input0
input<7>evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 3, Code: 0,
Value: 620
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 3, Code: 1, Value: 536
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 3, Code: 5, Value: 140
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 3, Code: 6, Value: 126
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 0, Code: 0, Value: 0
: USB HID v1.00 Joystick [Logitech Inc. WingMan Strike Force 3D] on
usb-PPC-SOC USB-1
hub 1-0:1.0: state 5 ports 2 chg 0000 evt 0002
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 3, Code: 0, Value: 619
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 0, Code: 0, Value: 0
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 3, Code: 5, Value: 141
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 0, Code: 0, Value: 0
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 3, Code: 0, Value: 618
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 0, Code: 0, Value: 0
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 3, Code: 0, Value: 624
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 0, Code: 0, Value: 0
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 3, Code: 0, Value: 618
evbug.c: Event. Dev: usb-PPC-SOC USB-1/input0, Type: 0, Code: 0, Value: 0
/ # cat /dev/input/event2
cat: /dev/input/event2: No such device
[-- Attachment #2: Type: text/html, Size: 7170 bytes --]
^ permalink raw reply
* Re: yosemite flash confusion
From: Wolfgang Denk @ 2005-11-28 14:54 UTC (permalink / raw)
To: Peter Fercher; +Cc: 'linux-ppc-embedded'
In-Reply-To: <006101c5f402$613ac2c0$dbe5fed4@scsad.scs.ch>
Dear Peter,
in message <006101c5f402$613ac2c0$dbe5fed4@scsad.scs.ch> you wrote:
>
> the yosemite (revision 1.1) i got has a 512 MBit Flash chip on it (S29GL512).
> u-boot 1.1.3 that came with it was configured to use only 32 Mbytes ???
Seems they installed an old version of U-Boot.
> when i try to use the u-boot.bin (newest from the denx homepage:
> ftp://ftp.denx.de/pub/u-boot/images/amcc/yosemite/) then i get:
> (reprogrammed using the yosemite.cfg that was mailed to this list some days ago)
> U-Boot 1.1.4 (Oct 24 2005 - 09:23:33)
...
> FLASH: 64 MB
> *** Warning - bad CRC, using default environment
This means you did not set up your environment and used "saveenv" to
store it. This also means that your MAC address is undefined.
...
> Net: No ethernet found.
...
> it sees the 64MB flash but somehow can't find the ethernet anymore..
> does anybody know what the problem is there ?
You forgot to set the MAC address...
Please set the "ethaddr" environment variable to define a valid MAC
address, then use "saveenv" to save it to flash, and then reset the
board...
BTW: this is off topic here. You should have posted on the
U-Boot-Users mailing list instead.
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
Never put off until tomorrow what you can put off indefinitely.
^ permalink raw reply
* Re: [PATCH] ppc32 8xx: Added setbitsXX/clrbitsXX macro for read-modify-write operations (resend)
From: Marcelo Tosatti @ 2005-11-28 14:39 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-devel list, linuxppc-embedded list
In-Reply-To: <438B45FE.5060003@ru.mvista.com>
On Mon, Nov 28, 2005 at 09:01:34PM +0300, Vitaly Bordug wrote:
> This adds setbitsXX/clrbitsXX macro for read-modify-write operations
> and converts the 8xx core and drivers to use them.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Looks good, thanks Vitaly.
^ permalink raw reply
* [RFC] add PHY support to AM79C874
From: Aristeu Sergio Rozanski Filho @ 2005-11-28 14:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 189 bytes --]
This is a simple port from old fec driver to PHY layer to support AMD
AM79C874 PHY.
As I don't have the hardware to test this, all kinds of feedback are
most welcome.
Thanks,
--
Aristeu
[-- Attachment #2: phy-add_am79c874_phy.patch --]
[-- Type: text/plain, Size: 2901 bytes --]
Index: testing/drivers/net/phy/Kconfig
===================================================================
--- testing.orig/drivers/net/phy/Kconfig 2005-11-25 15:26:38.000000000 -0200
+++ testing/drivers/net/phy/Kconfig 2005-11-25 15:28:55.000000000 -0200
@@ -53,5 +53,11 @@
---help---
Currently supports the cis8204
+config AMD_PHY
+ tristate "Drivers for the AMD PHYs"
+ depends on PHYLIB
+ ---help---
+ Currenty supports AM79C874
+
endmenu
Index: testing/drivers/net/phy/Makefile
===================================================================
--- testing.orig/drivers/net/phy/Makefile 2005-11-25 15:26:38.000000000 -0200
+++ testing/drivers/net/phy/Makefile 2005-11-25 15:26:56.000000000 -0200
@@ -8,3 +8,5 @@
obj-$(CONFIG_CICADA_PHY) += cicada.o
obj-$(CONFIG_LXT_PHY) += lxt.o
obj-$(CONFIG_QSEMI_PHY) += qsemi.o
+obj-$(CONFIG_AMD_PHY) += amd.o
+
Index: testing/drivers/net/phy/amd.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ testing/drivers/net/phy/amd.c 2005-11-28 11:39:34.000000000 -0200
@@ -0,0 +1,71 @@
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/version.h>
+#include <linux/mii.h>
+#include <linux/ethtool.h>
+#include <linux/phy.h>
+
+#include <asm/io.h>
+#include <asm/irq.h>
+#include <asm/uaccess.h>
+
+#define MII_AM79C874_MFR 16 /* Miscellaneous Features Register */
+#define MII_AM79C874_ICSR 17 /* Interrupt Control/Status Register */
+#define MII_AM79C874_DR 18 /* Diagnostic Register */
+#define MII_AM79C874_PMLR 19 /* Power Management & Loopback Register */
+#define MII_AM79C874_MCR 21 /* Mode Control Register */
+#define MII_AM79C874_DC 23 /* Disconnect Counter */
+#define MII_AM79C874_REC 24 /* Receiver Error Counter */
+
+static int am79c874_ack_interrupt(struct phy_device *phy)
+{
+ int err;
+
+ err = phy_read(phy, MII_AM79C874_ICSR);
+
+ if (err < 0)
+ return err;
+ return 0;
+}
+
+static int am79c874_config_intr(struct phy_device *phy)
+{
+ int err;
+
+ if (phy->interrupts == PHY_INTERRUPT_ENABLED)
+ err = phy_write(phy, MII_AM79C874_ICSR, 0xff00);
+ else
+ err = phy_write(phy, MII_AM79C874_ICSR, 0);
+
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static struct phy_driver am79c874 = {
+ .phy_id = 0x00022561,
+ .name = "AM79C874",
+ .phy_id_mask = 0x0fffffff,
+ .features = PHY_BASIC_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = am79c874_ack_interrupt,
+ .config_intr = am79c874_config_intr,
+ .driver = { .owner = THIS_MODULE,},
+};
+
+static __init int am79c874_init(void)
+{
+ return phy_driver_register(&am79c874);
+}
+
+static __exit void am79c874_exit(void)
+{
+ phy_driver_unregister(&am79c874);
+}
+module_init(am79c874_init);
+module_exit(am79c874_exit);
+
^ permalink raw reply
* Re: kernel 2.6.14 on MPC8272ADS
From: Vitaly Bordug @ 2005-11-28 13:09 UTC (permalink / raw)
To: ihornberger; +Cc: linuxppc-embedded
In-Reply-To: <1133175485.30984.1.camel@iho.sysgo.com>
Ingo Hornberger wrote:
> Hi Bracha,
>
> I assume that you're using an 8xx!?
>
> This code isn't completely updated yet, but here is a small patch which
> should be more or less working...
>
There is a patch, that did what you are attempting to do below correct way.
mfspr(SPRN_IMMR) does not correctly identify the board, you need to define BOARD_CHIP_NAME
somewhere in board-specific code to get it defined. The <>_device.c and <>_sys.c pair is
in the linus git tree currently, and error message below will not appear even if
BOARD_CHIP_NAME is undefined.
You might want to try more recent kernel.
> regards,
> Ingo
>
> On Sun, 2005-11-27 at 12:22 +0200, Landau, Bracha wrote:
>> I'm trying to move to the latest kernel release from linux 2.6.13.4 on the MPC8272ADS board.
>> 2.6.13.4 works, but from 2.6.14 and up (I don't know where from 2.6.13.4 to 2.6.14 the problem starts) the kernel crashes on bootup with the message
>> "Kernel BUG in ppc_sys_init at arch/ppc/syslib/ppc_sys_init.c:131"
>> Anyone know how to fix this problem?
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>> ------------------------------------------------------------------------
>>
>> diff -Nurb a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
>> --- a/arch/ppc/syslib/m8xx_setup.c 2005-10-28 02:02:08.000000000 +0200
>> +++ b/arch/ppc/syslib/m8xx_setup.c 2005-11-25 11:11:03.000000000 +0100
>> @@ -82,7 +82,7 @@
>> ROOT_DEV = Root_HDA1; /* hda1 */
>> #endif
>>
>> -#ifdef CONFIG_BLK_DEV_INITRD
>> +#if defined(CONFIG_BLK_DEV_INITRD) || defined(CONFIG_EXTRACT_ROOTFS)
>> #if 0
>> ROOT_DEV = Root_FD0; /* floppy */
>> rd_prompt = 1;
>> @@ -389,7 +389,7 @@
>> m8xx_setup_pci_ptrs();
>> #endif
>>
>> -#ifdef CONFIG_BLK_DEV_INITRD
>> +#if defined(CONFIG_BLK_DEV_INITRD) || defined(CONFIG_EXTRACT_ROOTFS)
>> /* take care of initrd if we have one */
>> if ( r4 )
>> {
>> @@ -404,6 +404,15 @@
>> strcpy(cmd_line, (char *)(r6+KERNELBASE));
>> }
>>
>> + /*
>> + * Check if we are really on a Power QUICC CPU.
>> + * Note, that we do not halt the Kernel at this point,
>> + * because we won't get any output here otherwise.
>> + */
>> + if( (mfspr(SPRN_PVR) >> 16) != 0x0050 )
>> + printk( KERN_ERR "ERROR: %s: %d: Wrong CPU Type! (We assumed a Power QUICC CPU)\n" );
>> + identify_ppc_sys_by_id(mfspr(SPRN_IMMR));
>> +
>> ppc_md.setup_arch = m8xx_setup_arch;
>> ppc_md.show_percpuinfo = m8xx_show_percpuinfo;
>> ppc_md.irq_canonicalize = NULL;
>> diff -Nurb a/arch/ppc/syslib/mpc8xx_sys.c b/arch/ppc/syslib/mpc8xx_sys.c
>> --- a/arch/ppc/syslib/mpc8xx_sys.c 2005-10-28 02:02:08.000000000 +0200
>> +++ b/arch/ppc/syslib/mpc8xx_sys.c 2005-11-25 11:11:03.000000000 +0100
>> @@ -20,9 +20,16 @@
>>
>> struct ppc_sys_spec *cur_ppc_sys_spec;
>> struct ppc_sys_spec ppc_sys_specs[] = {
>> + /* The mpc85x and 86x, all have the system ID 0x00.
>> + * And as it seems that even the 885 has the ID 0x00,
>> + * I assume 0x00 for all MPC8XX systems.
>> + * For other cases, you should add a new entry above the
>> + * MPC8XX. You could use the first 8 bits to make
>> + * a more specific match for your system.
>> + */
>> {
>> - .ppc_sys_name = "MPC86X",
>> - .mask = 0xFFFFFFFF,
>> + .ppc_sys_name = "MPC8XX",
>> + .mask = 0x00FF0000,
>> .value = 0x00000000,
>> .num_devices = 2,
>> .device_list = (enum ppc_sys_devices[])
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: kernel 2.6.14 on MPC8272ADS
From: Vitaly Bordug @ 2005-11-28 13:04 UTC (permalink / raw)
To: Landau, Bracha; +Cc: linuxppc-embedded list
In-Reply-To: <02AA386EB831044F8537A696BA785C7807645A@ILEX5.IL.NDS.COM>
Landau, Bracha wrote:
> I'm trying to move to the latest kernel release from linux 2.6.13.4 on the MPC8272ADS board.
> 2.6.13.4 works, but from 2.6.14 and up (I don't know where from 2.6.13.4 to 2.6.14 the problem starts) the kernel crashes on bootup with the message
> "Kernel BUG in ppc_sys_init at arch/ppc/syslib/ppc_sys_init.c:131"
> Anyone know how to fix this problem?
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
The patch that 'fix' it is currently ready, I am about to submit it today, after I'll
assure that nothing missed there.
--
Sincerely,
Vitaly
^ permalink raw reply
* RE: Badness in 2.6.15-rc1 on 8xx
From: Chris Down @ 2005-11-28 11:33 UTC (permalink / raw)
To: 'Joakim Tjernlund', linuxppc-embedded
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9393FE1C7@tmnt04.transmode.se>
-----Original Message-----
From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
Sent: 28 November 2005 10:53
To: Chris Down; linuxppc-embedded@ozlabs.org
Subject: RE: Badness in 2.6.15-rc1 on 8xx
> Anyone seen this when booting 2.6.15-rc1 on 8xx?
> Mount-cache hash table entries: 512
> Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> Call trace:
> [c00039e8] check_bug_trap+0x80/0xa8
> [c0003c1c] program_check_exception+0x20c/0x480
> [c00031e0] ret_from_except_full+0x0/0x4c
> [c01b86b8] dma_alloc_init+0x40/0xcc
> [c000225c] init+0x8c/0x288
> [c00050ac] kernel_thread+0x44/0x60
> NET: Registered protocol family 16
> The kernel boots just fine into user space so it seems harmless, but I
> suspect it will bite me later.
>
>
> I am currently working with 2.6.15-rc1 on MPC852 and I am
> seeing a similar
> problem.
>
> Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> Call trace:
> [c00036f8] check_bug_trap+0xa4/0xb8
> [c0003f9c] program_check_exception+0x2f0/0x4c4
> [c0003320] ret_from_except_full+0x0/0x4c
> [c024c530] dma_alloc_init+0x3c/0xbc
> [c0002280] init+0xbc/0x25c
> [c000538c] kernel_thread+0x44/0x60
>
> Have not had time to look at it yet, however I was not getting this on
> 2.6.11.
>
> Chris
Let me guess you have IMAP_ADDR set to 0xff000000? Then you need to
change
CONSISTENT_START to something else(like 0xffa00000). Its somwhere in the
Advanced setup.
Jocke
You are correct I do have IMAP_ADDR set to 0xff000000 and setting
CONSISTENT_START to 0xffa00000 solves the problem.
Chris
^ permalink raw reply
* Re: [PATCH] Make ARCH=ppc build again with new syscall path
From: David Woodhouse @ 2005-11-28 11:28 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20051128110146.ACD2E353F54@atlas.denx.de>
On Mon, 2005-11-28 at 12:01 +0100, Wolfgang Denk wrote:
> In message <1133172766.31573.14.camel@baythorne.infradead.org> you wrote:
> >
> > There's also a third option, which _encourages_ people to port their
> > platform without necessarily making it easier: just let arch/ppc break.
>
> Please don't. This is supposed to be a "stable" kernel tree.
I wouldn't advocate doing it just yet, but I don't think anyone really
expects to see arch/ppc continue until Linus announces 2.7.0. Setting a
cut-off of 2.6.17 or so, or perhaps a point in time when we officially
stop caring about it, would seem a sensible approach.
Neither did I suggest actively breaking it or removing it -- if you feel
strongly about keeping it then I'm sure Paul would accept your patches
to make it keep working, even after others have stopped bothering.
But I think the time and effort required to maintain arch/ppc in
perpetuity should be weighed up against that of just porting the
embedded platforms to arch/powerpc.
It's your choice, of course, but I personally don't think I'll be
submitting many more patches which take arch/ppc into account -- this
one was an exception because it was me who broke it, and it is still a
_little_ too early to be letting it break, IMO.
--
dwmw2
^ permalink raw reply
* Re: kernel 2.6.14 on MPC8272ADS
From: Ingo Hornberger @ 2005-11-28 10:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <02AA386EB831044F8537A696BA785C7807645A@ILEX5.IL.NDS.COM>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
Hi Bracha,
I assume that you're using an 8xx!?
This code isn't completely updated yet, but here is a small patch which
should be more or less working...
regards,
Ingo
On Sun, 2005-11-27 at 12:22 +0200, Landau, Bracha wrote:
> I'm trying to move to the latest kernel release from linux 2.6.13.4 on the MPC8272ADS board.
> 2.6.13.4 works, but from 2.6.14 and up (I don't know where from 2.6.13.4 to 2.6.14 the problem starts) the kernel crashes on bootup with the message
> "Kernel BUG in ppc_sys_init at arch/ppc/syslib/ppc_sys_init.c:131"
> Anyone know how to fix this problem?
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: ppc_8xx_2.6.14_syslib.patch --]
[-- Type: text/x-patch, Size: 2326 bytes --]
diff -Nurb a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c 2005-10-28 02:02:08.000000000 +0200
+++ b/arch/ppc/syslib/m8xx_setup.c 2005-11-25 11:11:03.000000000 +0100
@@ -82,7 +82,7 @@
ROOT_DEV = Root_HDA1; /* hda1 */
#endif
-#ifdef CONFIG_BLK_DEV_INITRD
+#if defined(CONFIG_BLK_DEV_INITRD) || defined(CONFIG_EXTRACT_ROOTFS)
#if 0
ROOT_DEV = Root_FD0; /* floppy */
rd_prompt = 1;
@@ -389,7 +389,7 @@
m8xx_setup_pci_ptrs();
#endif
-#ifdef CONFIG_BLK_DEV_INITRD
+#if defined(CONFIG_BLK_DEV_INITRD) || defined(CONFIG_EXTRACT_ROOTFS)
/* take care of initrd if we have one */
if ( r4 )
{
@@ -404,6 +404,15 @@
strcpy(cmd_line, (char *)(r6+KERNELBASE));
}
+ /*
+ * Check if we are really on a Power QUICC CPU.
+ * Note, that we do not halt the Kernel at this point,
+ * because we won't get any output here otherwise.
+ */
+ if( (mfspr(SPRN_PVR) >> 16) != 0x0050 )
+ printk( KERN_ERR "ERROR: %s: %d: Wrong CPU Type! (We assumed a Power QUICC CPU)\n" );
+ identify_ppc_sys_by_id(mfspr(SPRN_IMMR));
+
ppc_md.setup_arch = m8xx_setup_arch;
ppc_md.show_percpuinfo = m8xx_show_percpuinfo;
ppc_md.irq_canonicalize = NULL;
diff -Nurb a/arch/ppc/syslib/mpc8xx_sys.c b/arch/ppc/syslib/mpc8xx_sys.c
--- a/arch/ppc/syslib/mpc8xx_sys.c 2005-10-28 02:02:08.000000000 +0200
+++ b/arch/ppc/syslib/mpc8xx_sys.c 2005-11-25 11:11:03.000000000 +0100
@@ -20,9 +20,16 @@
struct ppc_sys_spec *cur_ppc_sys_spec;
struct ppc_sys_spec ppc_sys_specs[] = {
+ /* The mpc85x and 86x, all have the system ID 0x00.
+ * And as it seems that even the 885 has the ID 0x00,
+ * I assume 0x00 for all MPC8XX systems.
+ * For other cases, you should add a new entry above the
+ * MPC8XX. You could use the first 8 bits to make
+ * a more specific match for your system.
+ */
{
- .ppc_sys_name = "MPC86X",
- .mask = 0xFFFFFFFF,
+ .ppc_sys_name = "MPC8XX",
+ .mask = 0x00FF0000,
.value = 0x00000000,
.num_devices = 2,
.device_list = (enum ppc_sys_devices[])
^ permalink raw reply
* RE: Badness in 2.6.15-rc1 on 8xx
From: Ingo Hornberger @ 2005-11-28 10:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <TMNT04vAauNjVuMhvqg000000ab@tmnt04.transmode.se>
Hi Joakim,
I was recently faced with the same problem. It's right that it boots
fine into user land. But the bad 'consistent' start address would cause
trouble as soon as you try to initiate some dma transfer.
It is configurable under [Advanced setup].
I now use a value, seen on another 8xx board (it was some siemens board)
which was 0xf0000000. It works just fine.
As far as I understood the exact address isn't important, only that it
is unused in the kernel.
regards,
Ingo
On Fri, 2005-11-25 at 22:41 +0100, Joakim Tjernlund wrote:
> >
> > > -----Original Message-----
> > > From: linuxppc-embedded-bounces@ozlabs.org
> > > [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
> > > Joakim Tjernlund
> > > Sent: Freitag, 25. November 2005 14:28
> > > To: linuxppc-embedded@ozlabs.org
> > > Subject: Badness in 2.6.15-rc1 on 8xx
> > >
> > > Anyone seen this when booting 2.6.15-rc1 on 8xx?
> > > Mount-cache hash table entries: 512
> > > Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> > > Call trace:
> > > [c00039e8] check_bug_trap+0x80/0xa8
> > > [c0003c1c] program_check_exception+0x20c/0x480
> > > [c00031e0] ret_from_except_full+0x0/0x4c
> > > [c01b86b8] dma_alloc_init+0x40/0xcc
> > > [c000225c] init+0x8c/0x288
> > > [c00050ac] kernel_thread+0x44/0x60
> > > NET: Registered protocol family 16
> > > The kernel boots just fine into user space so it seems
> > > harmless, but I suspect it will bite me later.
> > >
> > > Something anoying:
> > > Why did the new cpm_uart driver change major and minor number
> > > for the tty?
> > > As it is now I can't boot my 2.4 rootfs as init think it
> > > should find the console on ttyS0.
> > > Would be great if major and minor could be configurable.
> > Because it's a new driver...with a new name (ttyCPM0) and a new
> > device number. It shared the device number and name in 2.4
> > with the "standard" device driver (8250/16550), and that made
> > it very difficult to use both in 2.4.
>
> To me it makes more sense to let a major number represent a function, not a driver.
> Shouldn't be that hard to make these drivers cooperate wrt. minor number.
>
> To allow for easy customization one could instead do:
> #ifndef SERIAL_CPM_MAJOR
> #define SERIAL_CPM_MAJOR 204
> #endif
> #ifndef SERIAL_CPM_MINOR
> #define SERIAL_CPM_MINOR 46
> #endif
>
> Each platform could then define major and minor as they like.
>
> Jocke
>
> > Maybe you should use console=ttyCPM0 in your boot parameters for 2.6.
> >
> > Regards,
> > Torsten
> > >
> > > Jocke
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [PATCH] Make ARCH=ppc build again with new syscall path
From: Wolfgang Denk @ 2005-11-28 11:01 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1133172766.31573.14.camel@baythorne.infradead.org>
In message <1133172766.31573.14.camel@baythorne.infradead.org> you wrote:
>
> There's also a third option, which _encourages_ people to port their
> platform without necessarily making it easier: just let arch/ppc break.
Please don't. This is supposed to be a "stable" kernel tree.
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
Monday is an awful way to spend one seventh of your life.
^ permalink raw reply
* RE: Badness in 2.6.15-rc1 on 8xx
From: Joakim Tjernlund @ 2005-11-28 10:52 UTC (permalink / raw)
To: Chris Down, linuxppc-embedded
=20
> -----Original Message-----
> From: Chris Down [mailto:chris@alcor.co.uk]=20
> Sent: 28 November 2005 11:01
> To: Joakim Tjernlund; linuxppc-embedded@ozlabs.org
> Subject: RE: Badness in 2.6.15-rc1 on 8xx
>=20
> From: linuxppc-embedded-bounces@ozlabs.org
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> Joakim Tjernlund
> Sent: 25 November 2005 13:28
> To: linuxppc-embedded@ozlabs.org
> Subject: Badness in 2.6.15-rc1 on 8xx
>=20
> Anyone seen this when booting 2.6.15-rc1 on 8xx?
> Mount-cache hash table entries: 512
> Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> Call trace:
> [c00039e8] check_bug_trap+0x80/0xa8
> [c0003c1c] program_check_exception+0x20c/0x480
> [c00031e0] ret_from_except_full+0x0/0x4c
> [c01b86b8] dma_alloc_init+0x40/0xcc
> [c000225c] init+0x8c/0x288
> [c00050ac] kernel_thread+0x44/0x60
> NET: Registered protocol family 16
> The kernel boots just fine into user space so it seems harmless, but I
> suspect it will bite me later.
>=20
>=20
> I am currently working with 2.6.15-rc1 on MPC852 and I am=20
> seeing a similar
> problem.
>=20
> Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> Call trace:
> [c00036f8] check_bug_trap+0xa4/0xb8
> [c0003f9c] program_check_exception+0x2f0/0x4c4
> [c0003320] ret_from_except_full+0x0/0x4c
> [c024c530] dma_alloc_init+0x3c/0xbc
> [c0002280] init+0xbc/0x25c
> [c000538c] kernel_thread+0x44/0x60
>=20
> Have not had time to look at it yet, however I was not getting this on
> 2.6.11.
>=20
> Chris
Let me guess you have IMAP_ADDR set to 0xff000000? Then you need to
change
CONSISTENT_START to something else(like 0xffa00000). Its somwhere in the
Advanced setup.
Jocke
^ permalink raw reply
* RE: Badness in 2.6.15-rc1 on 8xx
From: Chris Down @ 2005-11-28 10:01 UTC (permalink / raw)
To: 'Joakim Tjernlund', linuxppc-embedded
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D9393FE122@tmnt04.transmode.se>
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Joakim Tjernlund
Sent: 25 November 2005 13:28
To: linuxppc-embedded@ozlabs.org
Subject: Badness in 2.6.15-rc1 on 8xx
Anyone seen this when booting 2.6.15-rc1 on 8xx?
Mount-cache hash table entries: 512
Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
Call trace:
[c00039e8] check_bug_trap+0x80/0xa8
[c0003c1c] program_check_exception+0x20c/0x480
[c00031e0] ret_from_except_full+0x0/0x4c
[c01b86b8] dma_alloc_init+0x40/0xcc
[c000225c] init+0x8c/0x288
[c00050ac] kernel_thread+0x44/0x60
NET: Registered protocol family 16
The kernel boots just fine into user space so it seems harmless, but I
suspect it will bite me later.
I am currently working with 2.6.15-rc1 on MPC852 and I am seeing a similar
problem.
Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
Call trace:
[c00036f8] check_bug_trap+0xa4/0xb8
[c0003f9c] program_check_exception+0x2f0/0x4c4
[c0003320] ret_from_except_full+0x0/0x4c
[c024c530] dma_alloc_init+0x3c/0xbc
[c0002280] init+0xbc/0x25c
[c000538c] kernel_thread+0x44/0x60
Have not had time to look at it yet, however I was not getting this on
2.6.11.
Chris
^ permalink raw reply
* Re: kernel 2.6.14 on MPC8272ADS
From: Ingo Hornberger @ 2005-11-28 10:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <02AA386EB831044F8537A696BA785C7807645A@ILEX5.IL.NDS.COM>
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]
Hi Bracha,
I assume that you're using an 8xx!?
This code isn't completely updated yet, but here is a small patch which
should be more or less working...
regards,
Ingo
On Sun, 2005-11-27 at 12:22 +0200, Landau, Bracha wrote:
> I'm trying to move to the latest kernel release from linux 2.6.13.4 on the MPC8272ADS board.
> 2.6.13.4 works, but from 2.6.14 and up (I don't know where from 2.6.13.4 to 2.6.14 the problem starts) the kernel crashes on bootup with the message
> "Kernel BUG in ppc_sys_init at arch/ppc/syslib/ppc_sys_init.c:131"
> Anyone know how to fix this problem?
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: ppc_8xx_2.6.14_syslib.patch --]
[-- Type: text/x-patch, Size: 2326 bytes --]
diff -Nurb a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c 2005-10-28 02:02:08.000000000 +0200
+++ b/arch/ppc/syslib/m8xx_setup.c 2005-11-25 11:11:03.000000000 +0100
@@ -82,7 +82,7 @@
ROOT_DEV = Root_HDA1; /* hda1 */
#endif
-#ifdef CONFIG_BLK_DEV_INITRD
+#if defined(CONFIG_BLK_DEV_INITRD) || defined(CONFIG_EXTRACT_ROOTFS)
#if 0
ROOT_DEV = Root_FD0; /* floppy */
rd_prompt = 1;
@@ -389,7 +389,7 @@
m8xx_setup_pci_ptrs();
#endif
-#ifdef CONFIG_BLK_DEV_INITRD
+#if defined(CONFIG_BLK_DEV_INITRD) || defined(CONFIG_EXTRACT_ROOTFS)
/* take care of initrd if we have one */
if ( r4 )
{
@@ -404,6 +404,15 @@
strcpy(cmd_line, (char *)(r6+KERNELBASE));
}
+ /*
+ * Check if we are really on a Power QUICC CPU.
+ * Note, that we do not halt the Kernel at this point,
+ * because we won't get any output here otherwise.
+ */
+ if( (mfspr(SPRN_PVR) >> 16) != 0x0050 )
+ printk( KERN_ERR "ERROR: %s: %d: Wrong CPU Type! (We assumed a Power QUICC CPU)\n" );
+ identify_ppc_sys_by_id(mfspr(SPRN_IMMR));
+
ppc_md.setup_arch = m8xx_setup_arch;
ppc_md.show_percpuinfo = m8xx_show_percpuinfo;
ppc_md.irq_canonicalize = NULL;
diff -Nurb a/arch/ppc/syslib/mpc8xx_sys.c b/arch/ppc/syslib/mpc8xx_sys.c
--- a/arch/ppc/syslib/mpc8xx_sys.c 2005-10-28 02:02:08.000000000 +0200
+++ b/arch/ppc/syslib/mpc8xx_sys.c 2005-11-25 11:11:03.000000000 +0100
@@ -20,9 +20,16 @@
struct ppc_sys_spec *cur_ppc_sys_spec;
struct ppc_sys_spec ppc_sys_specs[] = {
+ /* The mpc85x and 86x, all have the system ID 0x00.
+ * And as it seems that even the 885 has the ID 0x00,
+ * I assume 0x00 for all MPC8XX systems.
+ * For other cases, you should add a new entry above the
+ * MPC8XX. You could use the first 8 bits to make
+ * a more specific match for your system.
+ */
{
- .ppc_sys_name = "MPC86X",
- .mask = 0xFFFFFFFF,
+ .ppc_sys_name = "MPC8XX",
+ .mask = 0x00FF0000,
.value = 0x00000000,
.num_devices = 2,
.device_list = (enum ppc_sys_devices[])
^ permalink raw reply
* RE: Badness in 2.6.15-rc1 on 8xx
From: Ingo Hornberger @ 2005-11-28 10:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <TMNT04vAauNjVuMhvqg000000ab@tmnt04.transmode.se>
Hi Joakim,
I was recently faced with the same problem. It's right that it boots
fine into user land. But the bad 'consistent' start address would cause
trouble as soon as you try to initiate some dma transfer.
It is configurable under [Advanced setup].
I now use a value, seen on another 8xx board (it was some siemens board)
which was 0xf0000000. It works just fine.
As far as I understood the exact address isn't important, only that it
is unused in the kernel.
regards,
Ingo
On Fri, 2005-11-25 at 22:41 +0100, Joakim Tjernlund wrote:
> >
> > > -----Original Message-----
> > > From: linuxppc-embedded-bounces@ozlabs.org
> > > [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of
> > > Joakim Tjernlund
> > > Sent: Freitag, 25. November 2005 14:28
> > > To: linuxppc-embedded@ozlabs.org
> > > Subject: Badness in 2.6.15-rc1 on 8xx
> > >
> > > Anyone seen this when booting 2.6.15-rc1 on 8xx?
> > > Mount-cache hash table entries: 512
> > > Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:346
> > > Call trace:
> > > [c00039e8] check_bug_trap+0x80/0xa8
> > > [c0003c1c] program_check_exception+0x20c/0x480
> > > [c00031e0] ret_from_except_full+0x0/0x4c
> > > [c01b86b8] dma_alloc_init+0x40/0xcc
> > > [c000225c] init+0x8c/0x288
> > > [c00050ac] kernel_thread+0x44/0x60
> > > NET: Registered protocol family 16
> > > The kernel boots just fine into user space so it seems
> > > harmless, but I suspect it will bite me later.
> > >
> > > Something anoying:
> > > Why did the new cpm_uart driver change major and minor number
> > > for the tty?
> > > As it is now I can't boot my 2.4 rootfs as init think it
> > > should find the console on ttyS0.
> > > Would be great if major and minor could be configurable.
> > Because it's a new driver...with a new name (ttyCPM0) and a new
> > device number. It shared the device number and name in 2.4
> > with the "standard" device driver (8250/16550), and that made
> > it very difficult to use both in 2.4.
>
> To me it makes more sense to let a major number represent a function, not a driver.
> Shouldn't be that hard to make these drivers cooperate wrt. minor number.
>
> To allow for easy customization one could instead do:
> #ifndef SERIAL_CPM_MAJOR
> #define SERIAL_CPM_MAJOR 204
> #endif
> #ifndef SERIAL_CPM_MINOR
> #define SERIAL_CPM_MINOR 46
> #endif
>
> Each platform could then define major and minor as they like.
>
> Jocke
>
> > Maybe you should use console=ttyCPM0 in your boot parameters for 2.6.
> >
> > Regards,
> > Torsten
> > >
> > > Jocke
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* yosemite flash confusion
From: Peter Fercher @ 2005-11-28 9:59 UTC (permalink / raw)
To: 'linux-ppc-embedded'
hi,
the yosemite (revision 1.1) i got has a 512 MBit Flash chip on it
(S29GL512).
u-boot 1.1.3 that came with it was configured to use only 32 Mbytes ???
trying to use the whole size of the flashchip on the board I run into the
following problem:
when i try to use the u-boot.bin (newest from the denx homepage:
ftp://ftp.denx.de/pub/u-boot/images/amcc/yosemite/) then i get:
(reprogrammed using the yosemite.cfg that was mailed to this list some days
ago)
U-Boot 1.1.4 (Oct 24 2005 - 09:23:33)
AMCC PowerPC 440EP Rev. B
Board: Yosemite - AMCC PPC440EP Evaluation Board
VCO: 1066 MHz
CPU: 533 MHz
PLB: 133 MHz
OPB: 66 MHz
EPB: 66 MHz
PCI: 66 MHz
I2C: ready
DRAM: 256 MB
FLASH: 64 MB
*** Warning - bad CRC, using default environment
PCI: Bus Dev VenId DevId Class Int
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Type "run flash_nfs" to mount root filesystem over NFS
Hit any key to stop autoboot: 0
it sees the 64MB flash but somehow can't find the ethernet anymore..
does anybody know what the problem is there ?
cheers, peter
^ permalink raw reply
* Re: [PATCH] Make ARCH=ppc build again with new syscall path
From: David Woodhouse @ 2005-11-28 10:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17290.28508.336476.478948@cargo.ozlabs.ibm.com>
On Mon, 2005-11-28 at 13:45 +1100, Paul Mackerras wrote:
> Hmmm. If we need to do this then maybe we should just get rid of the
> arch/ppc versions of the relevant files and make ARCH=ppc use the
> versions from arch/powerpc.
>
> What do people think? Do we make ARCH=ppc use more and more stuff
> from arch/powerpc, and delete the duplicates from arch/ppc, or do
> people want to be conservative and keep arch/ppc largely unchanged?
> (I would prefer the former, myself.)
I also prefer the former, in general -- it makes it easier for people to
port their platform from ppc to powerpc if we don't let the two diverge
too much.
There's also a third option, which _encourages_ people to port their
platform without necessarily making it easier: just let arch/ppc break.
I'm not sure I'd necessarily advocate that one _yet_ but maybe in the
not-so-distant future.
--
dwmw2
^ permalink raw reply
* Re: MPC8272ADS stability issues
From: Alex Zeffertt @ 2005-11-28 9:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051126052207.GA11393@gate.ebshome.net>
Thanks everybody. I was hoping to hear that others had seen this
problem and that it is probably hardware, not software.
My ADS is just about stable enough to use for development till our
custom hardware arrives, at which point - hopefully - the problems
will disappear!
Alex
^ permalink raw reply
* porting linux ppc on custom board, stuck in timer loop ?
From: David H. Lynch Jr. @ 2005-11-28 6:48 UTC (permalink / raw)
To: grave, linuxppc-embedded
Xavier;
I am having/had the exact same problem on a Xilinx VI based system and 2.6.12-2.6.14.2
I was eventually able to resolve it by removing MSR_ME from MSR_KERNEL. After that I have been able to successfully boot through to
starting init where I am hanging now. I beleive I do not have a working timer and that may be related to the problem with Machine Check Exceptions.
Were you ever able to resolve your problem aside from switching to 2.4.20, and if so what solution did you come up with ?
>Hi !
>I still try to port linux ppc on our ppc405 based hardware, after a look
>at xilinx_ml300.c file that gives the list of function calls I wait for
>a call to start_kernel but I found that start_kernel is never reached...
>In fact the code in head_4xx.S jumps to 0x00001000 which is Decrementer
>exception :
>/* Now turn on the MMU for real! */
> lis r4,MSR_KERNEL at h <https://ozlabs.org/mailman/listinfo/linuxppc-dev>
> ori r4,r4,MSR_KERNEL at l <https://ozlabs.org/mailman/listinfo/linuxppc-dev>
> lis r3,start_kernel at h <https://ozlabs.org/mailman/listinfo/linuxppc-dev>
> ori r3,r3,start_kernel at l <https://ozlabs.org/mailman/listinfo/linuxppc-dev>
> mtspr SPRN_SRR0,r3
> mtspr SPRN_SRR1,r4
> rfi /* enable MMU and jump to start_kernel */
> b . /* prevent prefetch past rfi */
>Is this my hardware implementation that is incorrect ? Or I missed
>something in my kernel configuration ?
>Thanks in advance for any answer...
>xavier
^ permalink raw reply
* Re: [PATCH] Make ARCH=ppc build again with new syscall path
From: Eugene Surovegin @ 2005-11-28 5:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Woodhouse
In-Reply-To: <17290.28508.336476.478948@cargo.ozlabs.ibm.com>
On Mon, Nov 28, 2005 at 01:45:48PM +1100, Paul Mackerras wrote:
>
> What do people think? Do we make ARCH=ppc use more and more stuff
> from arch/powerpc, and delete the duplicates from arch/ppc, or do
> people want to be conservative and keep arch/ppc largely unchanged?
> (I would prefer the former, myself.)
I thought initial idea was to keep arch/ppc mostly unchanged (we are in
"stable" series after all :), and migrate code to arch/powerpc when
it's ready.
Personally, the amount of PPC/PPC64 changes in 2.6 make me nervous,
looks like I'll stick with 2.4 longer than I thought for production.
--
Eugene
^ permalink raw reply
* 8248 Reboot Puzzle
From: Sam Song @ 2005-11-28 3:21 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I met a reboot puzzle those days. Nearly every boards
of 20 samples had a symptom
that after issuing a reboot command in Linux land more
than 10 times or so, the
target would encounter some unexpections like hang
after kernel uncompresing or
reset the target when initializing USB[VT6212L] 1.1
host controller. But I never
see any problem if cycle power. Then I have to switch
for a replacement method.
In 8248 restart function, use a GPIO to pull LOW
POWER_RESET# to get a similar
result and it did solve the problem. Well, if I use
the GPIO to pull LOW
HARD_RESET#, problems still existed. I use 2.4.31
kernel.
So I wonder what the problem could be according to
your experience. Can we get
the same result with software as POWER_RESET does? I
also want to know more on the
difference among software reboot and Power On reset
and Hard reset. I mean the
possibble effect on target running or initialization.
What I wanna to implement is a software power off and
on operation.
Power-on -> waitting for power button pushing in
u-boot -> boot the target
-> power off the target in Linux land by pushing the
power button
-> back to u-boot in a software power off state for
next power button pressing
-> ...
Thanks in advance for any comments/suggestion,
Sam
___________________________________________________________
雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱
http://cn.mail.yahoo.com
^ permalink raw reply
* Re: CPU off power consumption
From: Benjamin Herrenschmidt @ 2005-11-28 2:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: LinuxPPC-dev
In-Reply-To: <17290.26688.710369.613144@cargo.ozlabs.ibm.com>
On Mon, 2005-11-28 at 13:15 +1100, Paul Mackerras wrote:
> Giuliano Pochini writes:
>
> > Out of curiosity, what's the difference between a cpu that has never been
> > enabled and one that has been disabled with echo 0>/sys/.../online ? It
> > happens that when I boot with maxcpus=0 the temperature always stays low
> > enoung that the fan never spins up. If I enable and then I immediately
> > disable the 2nd cpu, the temperature goes a few degrees up. I have a dual
> > G4-MDD.
>
> Interesting. A cpu that has been disabled will be in sleep mode with
> interrupts disabled and its caches flushed. One that has never been
> started may possibly be held in the reset state. The way to check
> would be to check the state of the GPIO register that controls the
> soft reset line of the second CPU.
No, I think CPUs that have not been started are held in a similar sleep
loop in ROM. I don't see right away why there would be any power
consumption difference unless some bug causing us to never actually call
the sleep loop ....
Ben.
^ permalink raw reply
* Re: [PATCH] Make ARCH=ppc build again with new syscall path
From: Paul Mackerras @ 2005-11-28 2:45 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1133016287.4044.65.camel@baythorne.infradead.org>
David Woodhouse writes:
> This makes ARCH=ppc build in your powerpc tree again, with the new
> syscall entry/exit path.
Hmmm. If we need to do this then maybe we should just get rid of the
arch/ppc versions of the relevant files and make ARCH=ppc use the
versions from arch/powerpc.
What do people think? Do we make ARCH=ppc use more and more stuff
from arch/powerpc, and delete the duplicates from arch/ppc, or do
people want to be conservative and keep arch/ppc largely unchanged?
(I would prefer the former, myself.)
Paul.
^ permalink raw reply
* Re: CPU off power consumption
From: Paul Mackerras @ 2005-11-28 2:15 UTC (permalink / raw)
To: Giuliano Pochini; +Cc: LinuxPPC-dev
In-Reply-To: <20051126113805.709ee538.pochini@shiny.it>
Giuliano Pochini writes:
> Out of curiosity, what's the difference between a cpu that has never been
> enabled and one that has been disabled with echo 0>/sys/.../online ? It
> happens that when I boot with maxcpus=0 the temperature always stays low
> enoung that the fan never spins up. If I enable and then I immediately
> disable the 2nd cpu, the temperature goes a few degrees up. I have a dual
> G4-MDD.
Interesting. A cpu that has been disabled will be in sleep mode with
interrupts disabled and its caches flushed. One that has never been
started may possibly be held in the reset state. The way to check
would be to check the state of the GPIO register that controls the
soft reset line of the second CPU.
Paul.
^ permalink raw reply
* [PATCH] powerpc: More serial probing fixes
From: Benjamin Herrenschmidt @ 2005-11-28 0:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev list
Serial port detection code at boot needs a few more fixes, especially
to deal with MMIO based ports. Here they are. An additional patch to
the serial core is needed for a boot-time MMIO port to not conflict
with 8250_pci.c, that patch is reviewed separately by Russell King.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-serialfix/arch/powerpc/kernel/legacy_serial.c
===================================================================
--- linux-serialfix.orig/arch/powerpc/kernel/legacy_serial.c 2005-11-28 11:18:08.000000000 +1100
+++ linux-serialfix/arch/powerpc/kernel/legacy_serial.c 2005-11-28 11:24:20.000000000 +1100
@@ -38,12 +38,15 @@ static int __init add_legacy_port(struct
int iotype, phys_addr_t base,
phys_addr_t taddr, unsigned long irq)
{
- u32 *clk, *spd, clock;
+ u32 *clk, *spd, clock = 0;
int index;
/* get clock freq. if present */
clk = (u32 *)get_property(np, "clock-frequency", NULL);
- clock = clk ? *clk : BASE_BAUD * 16;
+ if (clk)
+ clock = *clk;
+ if (clock == 0)
+ clock = BASE_BAUD * 16;
/* get default speed if present */
spd = (u32 *)get_property(np, "current-speed", NULL);
@@ -85,7 +88,7 @@ static int __init add_legacy_port(struct
if (iotype == UPIO_PORT)
legacy_serial_ports[index].iobase = base;
else
- legacy_serial_ports[index].membase = (void __iomem *)base;
+ legacy_serial_ports[index].mapbase = base;
legacy_serial_ports[index].iotype = iotype;
legacy_serial_ports[index].uartclk = clock;
legacy_serial_ports[index].irq = irq;
@@ -145,17 +148,17 @@ static int __init add_legacy_pci_port(st
{
phys_addr_t addr, base;
u32 *addrp;
- int iotype, index = -1;
+ int iotype, index = -1, lindex = 0;
-#if 0
/* We only support ports that have a clock frequency properly
* encoded in the device-tree (that is have an fcode). Anything
* else can't be used that early and will be normally probed by
- * the generic 8250_pci driver later on.
+ * the generic 8250_pci driver later on. The reason is that 8250
+ * compatible UARTs on PCI need all sort of quirks (port offsets
+ * etc...) that this code doesn't know about
*/
if (get_property(np, "clock-frequency", NULL) == NULL)
return -1;
-#endif
/* Get the PCI address. Assume BAR 0 */
addrp = of_get_pci_address(pci_dev, 0, NULL);
@@ -180,7 +183,23 @@ static int __init add_legacy_pci_port(st
if (np != pci_dev) {
u32 *reg = (u32 *)get_property(np, "reg", NULL);
if (reg && (*reg < 4))
- index = legacy_serial_count + *reg;
+ index = lindex = *reg;
+ }
+
+ /* Local index means it's the Nth port in the PCI chip. Unfortunately
+ * the offset to add here is device specific. We know about those
+ * EXAR ports and we default to the most common case. If your UART
+ * doesn't work for these settings, you'll have to add your own special
+ * cases here
+ */
+ if (device_is_compatible(np, "pci13a8,152") ||
+ device_is_compatible(np, "pci13a8,154") ||
+ device_is_compatible(np, "pci13a8,158")) {
+ addrp += 0x200 * lindex;
+ base += 0x200 * lindex;
+ } else {
+ addrp += 8 * lindex;
+ base += 8 * lindex;
}
/* Add port, irq will be dealt with later. We passed a translated
@@ -261,7 +280,6 @@ void __init find_legacy_serial_ports(voi
DBG("legacy_serial_console = %d\n", legacy_serial_console);
/* udbg is 64 bits only for now, that will change soon though ... */
-#ifdef CONFIG_PPC64
while (legacy_serial_console >= 0) {
struct legacy_serial_info *info =
&legacy_serial_infos[legacy_serial_console];
@@ -278,7 +296,6 @@ void __init find_legacy_serial_ports(voi
udbg_init_uart(addr, info->speed, info->clock);
break;
}
-#endif /* CONFIG_PPC64 */
DBG(" <- find_legacy_serial_port()\n");
}
@@ -340,6 +357,15 @@ static void __init fixup_port_pio(int in
}
}
+static void __init fixup_port_mmio(int index,
+ struct device_node *np,
+ struct plat_serial8250_port *port)
+{
+ DBG("fixup_port_mmio(%d)\n", index);
+
+ port->membase = ioremap(port->mapbase, 0x100);
+}
+
/*
* This is called as an arch initcall, hopefully before the PCI bus is
* probed and/or the 8250 driver loaded since we need to register our
@@ -374,6 +400,8 @@ static int __init serial_dev_init(void)
fixup_port_irq(i, np, port);
if (port->iotype == UPIO_PORT)
fixup_port_pio(i, np, port);
+ if (port->iotype == UPIO_MEM)
+ fixup_port_mmio(i, np, port);
}
DBG("Registering platform serial ports\n");
^ 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