* Re: About 2.6.14 on AMCC Yosemite board
From: Wolfgang Denk @ 2005-11-02 16:46 UTC (permalink / raw)
To: KylongMu; +Cc: Linuxppc-embedded
In-Reply-To: <20051102135009.27C46102A@smtp.263.net>
Dear Kylong Mu,
in message <20051102135009.27C46102A@smtp.263.net> you wrote:
>
> I've got my Yosemite board today, it's shows very good by default test.
> I downloaded the 2.6.14 according the repository from your website by cogito.
> with default configure, I boot with the uImage, but the system halt, attachment
> is the message.
> I don't know what happen with it, pls help me.
...
> DRAM: 256 MB
> FLASH: 32 MB
---------^^^^^
That's the problem. The board we got from AMCC for the port and for
testing all had 64 MB flash, and there was no information that other
configurations are available too. The MTD mapping driver ist a bit
braindead at the moment and assumes 64 MB. This fails on your board.
The quick and dirty fix is to edit "drivers/mtd/maps/yosemite.c" and
replace the lines:
...
31
32 #define WINDOW_ADDR 0xfc000000
33 #define WINDOW_SIZE 0x04000000
34
...
with:
#define WINDOW_ADDR 0xFE000000
#define WINDOW_SIZE 0x02000000
We will implement a better fix (automatically adjust values according
to the values pased by the boot loader) later today / early tomorrow.
Sorry for the inconvenience.
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
If you want strict real-time behavior, run in the real time schedu-
ling class. But there are no seatbelts or airbags; main(){for(;;);}
can hard hang your system. -- Bart Smaalders
^ permalink raw reply
* Re: onboard pci ethernet controller(i82551)without eprom(linuxppc2.2.4 MPC5200)
From: Joshua Lamorie @ 2005-11-02 15:21 UTC (permalink / raw)
To: xiay; +Cc: linuxppc-embedded
In-Reply-To: <200510082230.AA69861636@NARI-RELAYS.COM>
=E6=82=A8=E5=A5=BD,
I am using the same chip connected through PCI to a Virtex-II Pro (PPC=20
405). I do not have an EEPROM connected to the chip. However, I am=20
having problem with the code because it seems to be built specifically=20
for processors that have coherent cache. So each time the code tries to =
execute I get a kernel panic. (kernel 2.4.26, with RTAI patch)
This occurs because in many places it executes a bottom-half spin lock=20
before calling pci_free_consistent. This increments the bottom-half=20
counter and so when pci_free_consistent is called it calls BUG(); and=20
the whole thing goes Tango Uniform. I'm about to go through and try to=20
fix this, but it seems like an extremely dangerous thing for me to play=20
with.
I seem to be able to get the eepro100.c code to work, but I was hoping=20
to use the e100 driver to program an EEPROM on the board.
=E8=B0=A2=E8=B0=A2
Joshua
=C3=8F=C3=84=C3=93=C3=AA wrote:
>After i modified e100_init() in e100_main.c , the pci ethernet card coul=
d been found :
>
>bash-2.05b# ifconfig -a
>eth0 Link encap:Ethernet HWaddr FF:FF:FF:FF:FF:FF
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
> Memory:40000000-40000038
>
>eth1 Link encap:Ethernet HWaddr 00:04:9F:00:15:2B
> inet addr:198.87.102.215 Bcast:198.87.102.255 Mask:255.255.2=
55.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:12606 errors:42 dropped:0 overruns:0 frame:0
> TX packets:7668 errors:3 dropped:0 overruns:3 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:10596597 (10.1 Mb) TX bytes:1218624 (1.1 Mb)
> Interrupt:43
>
>lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:4 errors:0 dropped:0 overruns:0 frame:0
> TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
>
>But i still could not config eth0:
>
>bash-2.05b# ifconfig eth0 198.87.102.140
>SIOCSIFFLAGS: Resource temporarily unavailable
>
>I noticed that there was message as blow during kernel bootup:
>
>POSIX conformance testing by UNIFIX
>PCI: Probing PCI hardware
>PCI: Cannot allocate resource region 0 of device 00:1a.0
>Linux NET4.0 for Linux 2.4
>
>Intel(R) PRO/100 Network Driver - version 2.3.38-k1
>Copyright (c) 2004 Intel Corporation
>
>PCI: Enabling device 00:18.0 (0006 -> 0007)
>e100: eth0: Intel(R) PRO/100 Network Connection
>Hardware receive checksums enabled
>
>IP-Config: Failed to open eth0
>
>what is wrong?
>
>Best regards
>
>Xiayu
>
>
>
>
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> =20
>
--=20
Xiphos Technologies
(514) 848-9640 x227
(514) 848-9644 fax
www.xiplink.com
_______________________________________________
The information transmitted is intended only for the
person or entity to which it is addressed and may contain
confidential and/or privileged material. If you have
received this in error, please contact the sender and delete
this communication and any copy immediately. Thank you.
^ permalink raw reply
* Re: compact flash driver
From: mcr @ 2005-11-02 16:06 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA91127964158496E9@xmb-sjc-212.amer.cisco.com>
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Alex" == Alex Zeffertt <ajz@cambridgebroadband.com> writes:
>Do you have an early release code? I can start to work at.
I have to merge code into the torsvalds tree still.
Priority goes to actually shipping our product :-)
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQ2jj7oqHRg3pndX9AQGCeQP+KaWWyMTz8rlhLALd39vvTQqZkl32k1bq
YEs/0lZrcxwbLEPa4U+8cgc7JFgeJR0aKXr89cnSmgurOs2pzhU9SNdsY75dAywk
oJzC26nf0gXngDtv2YAb9clm2YkZgKuQUt7bQGgjfls8LXnLlQXuuIIchzbRh89K
gDBwa6VnGoY=
=csPz
-----END PGP SIGNATURE-----
^ permalink raw reply
* RE: About 2.6.14 on AMCC Yosemite board
From: Steven Blakeslee @ 2005-11-02 14:31 UTC (permalink / raw)
To: KylongMu, Wolfgang Denk; +Cc: Linuxppc-embedded
Your FLASH mapping says that FLASH starts at 0xFC000000. There should
only be 32Meg of FLASH starting at address 0xFE000000.=20
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of KylongMu
> Sent: Wednesday, November 02, 2005 8:50 AM
> To: 'Wolfgang Denk'
> Cc: Linuxppc-embedded@ozlabs.org
> Subject: About 2.6.14 on AMCC Yosemite board
>=20
> Hi, Denk
> I've got my Yosemite board today, it's shows very good=20
> by default test.
> I downloaded the 2.6.14 according the repository from your=20
> website by cogito.
> with default configure, I boot with the uImage, but the=20
> system halt, attachment is the message.
> I don't know what happen with it, pls help me.
>=20
> Thanks a lot!
>=20
> Kylong Mu
>=20
^ permalink raw reply
* About 2.6.14 on AMCC Yosemite board
From: KylongMu @ 2005-11-02 13:49 UTC (permalink / raw)
To: 'Wolfgang Denk'; +Cc: Linuxppc-embedded
In-Reply-To: <20050711142250.BC3253539FE@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 330 bytes --]
Hi, Denk
I've got my Yosemite board today, it's shows very good by default
test.
I downloaded the 2.6.14 according the repository from your website by
cogito.
with default configure, I boot with the uImage, but the system halt,
attachment
is the message.
I don't know what happen with it, pls help me.
Thanks a lot!
Kylong Mu
[-- Attachment #2: make_command.txt --]
[-- Type: text/plain, Size: 76 bytes --]
924 make yosemite_defconfig
925 make menuconfig
926 make uImage
[-- Attachment #3: bootmessage.txt --]
[-- Type: text/plain, Size: 6122 bytes --]
U-Boot 1.1.3 (Sep 7 2005 - 09:03:02)
IBM PowerPC 440 EP Rev. B
Board: AMCC YOSEMITE
VCO: 1066 MHz
CPU: 533 MHz
PLB: 133 MHz
OPB: 66 MHz
PER: 66 MHz
PCI: 66 MHz
I2C: ready
DRAM: 256 MB
FLASH: 32 MB
PCI: Bus Dev VenId DevId Class Int
00 0c 105a 4d68 0180 0e
In: serial
Out: serial
Err: serial
Net: ppc_440x_eth0, ppc_440x_eth1
Hit any key to stop autoboot: 0
=> tftp 0x4000000 uImage
Waiting for PHY auto negotiation to complete.. done
Using ppc_440x_eth0 device
TFTP from server 192.168.0.93; our IP address is 192.168.0.66
Filename 'uImage'.
Load address: 0x4000000
Loading: #################################################################
#################################################################
#################################################################
#############################################
done
Bytes transferred = 1225628 (12b39c hex)
=> bootm 0x4000000 fed40000
## Booting image at 04000000 ...
Image Name: Linux-2.6.14
Created: 2005-11-02 13:20:24 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1225564 Bytes = 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at fed40000 ...
Image Name: Yosemite Ramdisk
Created: 2005-08-30 2:13:49 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 17770706 Bytes = 16.9 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0ee9b000, end 0ff8d8d2 ... OK
Linux version 2.6.14 (root@dxp) (gcc �.� 3.3.3 (DENX ELDK 3.1.1 3.3.3-10)) #2 Wed Nov 2 21:20:16 CST 2005
AMCC PowerPC 440EP Yosemite Platform
Built 1 zonelists
Kernel command line: ramdisk=49152 root=/dev/ram ip=192.168.1.62:::::eth0:off
PID hash table entries: 2048 (order: 11, 32768 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 239360k available (1876k kernel code, 708k data, 140k init, 0k highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
softlockup thread 0 started up.
Freeing initrd memory: 17354k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
usbcore: registered new driver usbfs
usbcore: registered new driver hub
SCSI subsystem initialized
usbmon: debugfs is not available
ppc-soc-ohci ppc-soc-ohci.0: USB Host Controller
ppc-soc-ohci ppc-soc-ohci.0: new USB bus registered, assigned bus number 1
ppc-soc-ohci ppc-soc-ohci.0: irq 40, io mem 0xef601000
usb usb1: Product: USB Host Controller
usb usb1: Manufacturer: Linux 2.6.14 ohci_hcd
usb usb1: SerialNumber: PPC-SOC USB
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
pegasus: v0.6.12 (2005/01/13), Pegasus/Pegasus II USB Ethernet driver
usbcore: registered new driver pegasus
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 49152K size 1024 blocksize
PPC 4xx OCP EMAC driver, version 3.53
mal0: initialized, 4 TX channels, 2 RX channels
zmii0: bridge in RMII mode
eth0: emac0, MAC 00:10:ec:00:8f:aa
eth0: found Generic MII PHY (0x01)
eth1: emac1, MAC 00:10:ec:80:8f:aa
eth1: found Generic MII PHY (0x03)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
yosemite: flash mapping: 4000000 at fc000000
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR= 0xfdffffff
POB0: BEAR=0xc27e319400000001 BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00000000 LR: C015D7C8 SP: C0521E30 REGS: c0291f50 TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = cee98b10[1] 'swapper' THREAD: c0520000
Last syscall: 120
GPR00: 00000002 C0521E30 CEE98B10 C0242F18 00000000 00000000 C0521EE0 CEF0C3F8
GPR08: 000000FF 00000004 00000002 00000001 42254128 C0020028 0FFE6E00 00000001
GPR16: FFFFFFFF 007FFF00 0FFE1AD4 00000000 00000003 007FFE70 00800000 00000001
GPR24: 00000000 C0521EE0 C0242DB0 00000000 C0242F18 C0521EE0 00000000 C0242F18
NIP [00000000] 0x0
LR [c015d7c8] genprobe_new_chip+0xa8/0xc0
Call trace:
[c015d7c8] genprobe_new_chip+0xa8/0xc0
[c015d508] genprobe_ident_chips+0x3c/0x254
[c015d444] mtd_do_chip_probe+0x18/0xa0
[c01587b8] cfi_probe+0x18/0x28
[c01570c4] do_map_probe+0x40/0xe0
[c028594c] init_yosemite_flash+0x90/0xec
[c026c728] do_initcalls+0x54/0xfc
[c000137c] init+0x2c/0x13c
[c0004630] kernel_thread+0x48/0x64
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR= 0xfdffffff
POB0: BEAR=0xc27e319400000001 BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#2]
NIP: 00000000 LR: C000229C SP: C0291E60 REGS: c0291f50 TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = cee98b10[1] 'swapper' THREAD: c0520000
Last syscall: 120
GPR00: 08000000 C0291E60 CEE98B10 C0291E70 000015D7 FFFFFFFF C0230000 C0290000
GPR08: C0230000 C000229C 00021002 C00036D0 CEE98CD8 C0020028 0FFE6E00 00000001
GPR16: FFFFFFFF 007FFF00 0FFE1AD4 00000000 00000003 007FFE70 00800000 00000001
GPR24: 00000000 C0521EE0 C0242DB0 00000000 C0242F18 C0521EE0 C0291F50 00000007
NIP [00000000] 0x0
LR [c000229c] ret_from_except+0x0/0x18
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
^ permalink raw reply
* Re: [PATCH] ppc32: fix: swallowed chars when booting.
From: Heiko Schocher @ 2005-11-02 13:01 UTC (permalink / raw)
To: linuxppc-dev
Hello,
during I am searching the right solution for my
other patch, i found another way for solving the
swallowed chars problem when booting on SMC2.
Please comment.
thanks
Heiko Schocher
[PATCH] ppc32: Fix: swallowed chars on SMC2 Console.
Signed-off-by: Heiko Schocher <hs@denx.de>
---
drivers/serial/cpm_uart/cpm_uart_core.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index 25825f2..baedd74 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -552,9 +552,9 @@ static void cpm_uart_set_termios(struct
* enables, because we want to put them back if they were
* present.
*/
- prev_mode = smcp->smc_smcmr;
- smcp->smc_smcmr = smcr_mk_clen(bits) | cval | SMCMR_SM_UART;
- smcp->smc_smcmr |= (prev_mode & (SMCMR_REN | SMCMR_TEN));
+ prev_mode = smcp->smc_smcmr & (SMCMR_REN | SMCMR_TEN);
+ smcp->smc_smcmr = smcr_mk_clen(bits) | cval | SMCMR_SM_UART
+ | prev_mode;
} else {
sccp->scc_psmr = (sbits << 12) | scval;
}
^ permalink raw reply related
* Re: compact flash driver
From: Bizhan Gholikhamseh (bgholikh) @ 2005-11-02 11:28 UTC (permalink / raw)
To: mcr; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
>>>>> "Alex" == Alex Zeffertt <ajz@cambridgebroadband.com> writes:
>> Hello All, Are there any compact flash driver supported for Linux
>> 2.6? If there is where can i get the source code. Thanks, Bizhan
>>
Alex> I think that CF cards just get treated the same as any other
Alex> IDE disk by linux. No special driver needed.
>Yes. There are some gotchas with newer pcmcia/cardbus flash cards.
>For instance, Silicon Systems devices claim to support IORDY, but
don't, which results in a system hang. I imagine that the same >kind of
things will show up in newer CF devices, although I think that CF can't
support DMA.
>It also depends upon how you interface CF: via an IDE controller, or
via a cardbus interface.
>I expect to have a git tree with stuff available soon.
Do you have an early release code? I can start to work at.
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 2064 bytes --]
^ permalink raw reply
* Board Bringup problem with 2.6.13.4
From: David H. Lynch Jr @ 2005-11-02 9:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050906130029.74727.qmail@web8405.mail.in.yahoo.com>
I am working through bringing up Linux 2.6.13.4 on a Xilinx V4 based ppc405.
with memory from 0x0 through 0x7fffffff
Right now I get:
>Starting MonitorX.elf: V3.3.2.0.
>
>loaded at: 00400000 0047F13C
>board data at: 0047D128 0047D13C
>relocated to: 00405300 00405314
>zimage at: 00405A95 0047CE71
>avail ram: 00480000 08000000
>
>Linux/PPC load: console=ttyS0,9600 console=tty0 init=/linuxrc
looptype=squashfs cdroot splash=silentttttt
>Uncompressing Linux......done.
>Now booting the kernel
I have been able to trace execution into head_4xx.S to immediately
before turn_on_mmu:
But immediately after this I lose the ability to trace.
I have been tracing things with a status port at 0x70000000 I can write
to and read from the host side with code like
lis r14,0x7000 /* debugging port */
li r15,0x2305 /* value to output */
stw r15,4(r14)
eieio
after turn_on_mmu executes this does not seem to work.
looking at other code it appeared that I needed to add
tophy(r14,r14) prior to the stw
but that does not seem to help.
What do I need to do to be able to continue to use my debug port ?
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: David Woodhouse @ 2005-11-02 9:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17256.4190.184855.821331@cargo.ozlabs.ibm.com>
On Wed, 2005-11-02 at 12:03 +1100, Paul Mackerras wrote:
> That's probably either the pci quirk that got added to do USB host
> controller handoff unconditionally on all platforms, and which touches
> the device without doing pci_enable_device or checking whether MMIO is
> enabled. A fix has gone into Linus' tree for that.
>
> There was also a bug added to the adbhid.c driver which would cause an
> oops when you pressed a key if you had an ADB keyboard (which
> powerbooks do). That's also fixed in Linus' tree.
It was neither of those -- after a few warnings about sleeping in
inappropriate contexts it just seems to stop. The Pegasos is a little
more informative -- lots of 'hda: lost interrupt' on that. Keyboard
seems to work though, and Bogomips calculation -- so maybe it's just PCI
interrupts which are missing. I'll poke at it further.
I'll also try again on the powerbook today and see if I can get anything
more useful out of it.
--
dwmw2
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: David Woodhouse @ 2005-11-02 7:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17256.17408.247708.622755@cargo.ozlabs.ibm.com>
On Wed, 2005-11-02 at 15:43 +1100, Paul Mackerras wrote:
> I also pulled in Linus' tree, and now drivers/char/tlclk.c fails to
> build for some reason. I claim that's not my fault, however. :)
It just needs <linux/platform_device.h> included. That reminds me -- I
needed that in platforms/chrp/pegasos_eth.c too.
diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/powerpc/platforms/chrp/pegasos_eth.c
--- a/arch/powerpc/platforms/chrp/pegasos_eth.c
+++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
@@ -15,6 +15,7 @@
#include <linux/ioport.h>
#include <linux/device.h>
#include <linux/mv643xx.h>
+#include <linux/platform_device.h>
#include <linux/pci.h>
#define PEGASOS2_MARVELL_REGBASE (0xf1000000)
diff --git a/drivers/char/tlclk.c b/drivers/char/tlclk.c
--- a/drivers/char/tlclk.c
+++ b/drivers/char/tlclk.c
@@ -43,6 +43,7 @@
#include <linux/sysfs.h>
#include <linux/device.h>
#include <linux/miscdevice.h>
+#include <linux/platform_device.h>
#include <asm/io.h> /* inb/outb */
#include <asm/uaccess.h>
--
dwmw2
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: Paul Mackerras @ 2005-11-02 4:43 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <1130861207.21212.66.camel@hades.cambridge.redhat.com>
David Woodhouse writes:
> The ppc64 build (http://david.woodhou.se/powerpc-merge-64.config) fares
> worse than ppc32 for me -- it doesn't even build.
Those errors were all due to getting powerbook sleep code included
because you have CONFIG_PM=y. I have changed things so that that code
doesn't get included on a 64-bit build (at least until BenH gets sleep
going on the G5 :).
I also pulled in Linus' tree, and now drivers/char/tlclk.c fails to
build for some reason. I claim that's not my fault, however. :)
Paul.
^ permalink raw reply
* Re: [PATCH] ppc bug.h namespace pollution
From: Paul Mackerras @ 2005-11-02 3:29 UTC (permalink / raw)
To: Al Viro; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <20051102031043.GB7992@ftp.linux.org.uk>
Al Viro writes:
> Should be OK...
>
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
OK, I'll put that in my powerpc-merge tree and ask Linus to pull it.
I want to do a few more cleanups on that file now that I look at it.
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH] ppc bug.h namespace pollution
From: Al Viro @ 2005-11-02 3:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <17256.10342.228209.745529@cargo.ozlabs.ibm.com>
On Wed, Nov 02, 2005 at 01:45:58PM +1100, Paul Mackerras wrote:
> Al Viro writes:
>
> > DATA_TYPE is really not a good thing to put into header that
> > gets included all over the tree...
>
> Very true. However, I don't see any reason why the cast shouldn't
> just be (long) on both 32-bit and 64-bit, so we can get rid of that
> define altogether.
Should be OK...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
----
diff -urN RC14-base/include/asm-powerpc/bug.h current/include/asm-powerpc/bug.h
--- RC14-base/include/asm-powerpc/bug.h 2005-11-01 22:08:35.000000000 -0500
+++ current/include/asm-powerpc/bug.h 2005-11-01 22:09:28.000000000 -0500
@@ -15,12 +15,10 @@
#define BUG_TABLE_ENTRY(label, line, file, func) \
".llong " #label "\n .long " #line "\n .llong " #file ", " #func "\n"
#define TRAP_OP(ra, rb) "1: tdnei " #ra ", " #rb "\n"
-#define DATA_TYPE long long
#else
#define BUG_TABLE_ENTRY(label, line, file, func) \
".long " #label ", " #line ", " #file ", " #func "\n"
#define TRAP_OP(ra, rb) "1: twnei " #ra ", " #rb "\n"
-#define DATA_TYPE int
#endif /* __powerpc64__ */
struct bug_entry {
@@ -55,7 +53,7 @@
".section __bug_table,\"a\"\n\t" \
BUG_TABLE_ENTRY(1b,%1,%2,%3) \
".previous" \
- : : "r" ((DATA_TYPE)(x)), "i" (__LINE__), \
+ : : "r" ((long)(x)), "i" (__LINE__), \
"i" (__FILE__), "i" (__FUNCTION__)); \
} while (0)
@@ -65,7 +63,7 @@
".section __bug_table,\"a\"\n\t" \
BUG_TABLE_ENTRY(1b,%1,%2,%3) \
".previous" \
- : : "r" ((DATA_TYPE)(x)), \
+ : : "r" ((long)(x)), \
"i" (__LINE__ + BUG_WARNING_TRAP), \
"i" (__FILE__), "i" (__FUNCTION__)); \
} while (0)
^ permalink raw reply
* Re: [PATCH] ppc bug.h namespace pollution
From: Paul Mackerras @ 2005-11-02 2:45 UTC (permalink / raw)
To: Al Viro; +Cc: linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <20051101151716.GY7992@ftp.linux.org.uk>
Al Viro writes:
> DATA_TYPE is really not a good thing to put into header that
> gets included all over the tree...
Very true. However, I don't see any reason why the cast shouldn't
just be (long) on both 32-bit and 64-bit, so we can get rid of that
define altogether.
Paul.
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: Paul Mackerras @ 2005-11-02 1:04 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <1130860444.21212.52.camel@hades.cambridge.redhat.com>
[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 170 bytes --]
David Woodhouse writes:
> Hm. Not entirely in line with my experience. Can you share the configs
> you used?
Forgot to attach the configs on my previous reply.
Paul.
[-- Attachment #2: config tarball --]
[-- Type: application/octet-stream, Size: 19644 bytes --]
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: Paul Mackerras @ 2005-11-02 1:03 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <1130860444.21212.52.camel@hades.cambridge.redhat.com>
David Woodhouse writes:
> Hm. Not entirely in line with my experience. Can you share the configs
> you used?
Sure, attached (as a .tar.gz). For 32-bit pmac, you currently have to
disable CONFIG_PREP and (I believe) the TAU options. For the 64-bit
configs I basically just used the defconfigs in arch/ppc64/configs.
> Using http://david/woodhou.se/powerpc-merge-32.config it doesn't
> actually boot on my powerbook. I'll try it on the Pegasos later or
> tomorrow, where I have a serial console; it dies very early.
That's probably either the pci quirk that got added to do USB host
controller handoff unconditionally on all platforms, and which touches
the device without doing pci_enable_device or checking whether MMIO is
enabled. A fix has gone into Linus' tree for that.
There was also a bug added to the adbhid.c driver which would cause an
oops when you pressed a key if you had an ADB keyboard (which
powerbooks do). That's also fixed in Linus' tree.
> Aside from disabling CONFIG_NVRAM because call_rtas() isn't implemented
> anywhere, I also needed to do this to make that config build:
>
> --- linux-2.6.14/arch/powerpc/kernel/setup-common.c.orig 2005-11-01 10:14:32.000000000 +0000
> +++ linux-2.6.14/arch/powerpc/kernel/setup-common.c 2005-11-01 10:15:03.000000000 +0000
> @@ -203,11 +203,11 @@ static int show_cpuinfo(struct seq_file
> #ifdef CONFIG_TAU_AVERAGE
> /* more straightforward, but potentially misleading */
> seq_printf(m, "temperature \t: %u C (uncalibrated)\n",
> - cpu_temp(i));
> + cpu_temp(cpu_id));
> #else
> /* show the actual temp sensor range */
> u32 temp;
> - temp = cpu_temp_both(i);
> + temp = cpu_temp_both(cpu_id);
> seq_printf(m, "temperature \t: %u-%u C (uncalibrated)\n",
> temp & 0xff, temp >> 16);
> #endif
Thanks, I'll put that in.
Paul.
^ permalink raw reply
* Re: please pull the powerpc-merge.git tree
From: David Gibson @ 2005-11-02 0:06 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <1130860444.21212.52.camel@hades.cambridge.redhat.com>
On Tue, Nov 01, 2005 at 03:54:04PM +0000, David Woodhouse wrote:
> On Mon, 2005-10-31 at 15:23 +1100, Paul Mackerras wrote:
> > It is now possible to build kernels for powermac, pSeries, iSeries and
> > maple with ARCH=powerpc, and for powermac, both 32-bit and 64-bit
> > build and run.
>
> Hm. Not entirely in line with my experience. Can you share the configs
> you used?
I gather paulus doesn't believe in CONFIG_TAU.
> Using http://david/woodhou.se/powerpc-merge-32.config it doesn't
> actually boot on my powerbook. I'll try it on the Pegasos later or
> tomorrow, where I have a serial console; it dies very early.
>
> Aside from disabling CONFIG_NVRAM because call_rtas() isn't implemented
> anywhere, I also needed to do this to make that config build:
>
> --- linux-2.6.14/arch/powerpc/kernel/setup-common.c.orig 2005-11-01 10:14:32.000000000 +0000
> +++ linux-2.6.14/arch/powerpc/kernel/setup-common.c 2005-11-01 10:15:03.000000000 +0000
> @@ -203,11 +203,11 @@ static int show_cpuinfo(struct seq_file
> #ifdef CONFIG_TAU_AVERAGE
> /* more straightforward, but potentially misleading */
> seq_printf(m, "temperature \t: %u C (uncalibrated)\n",
> - cpu_temp(i));
> + cpu_temp(cpu_id));
> #else
> /* show the actual temp sensor range */
> u32 temp;
> - temp = cpu_temp_both(i);
> + temp = cpu_temp_both(cpu_id);
> seq_printf(m, "temperature \t: %u-%u C (uncalibrated)\n",
> temp & 0xff, temp >> 16);
> #endif
>
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* Re: [PATCH 2/2] MTD: Add initial support for DAVE "PPChameleon" board.
From: Matt Porter @ 2005-11-01 23:30 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: llandre, linuxppc-embedded
In-Reply-To: <20051012154431.C4C53353A4F@atlas.denx.de>
On Wed, Oct 12, 2005 at 05:44:31PM +0200, Wolfgang Denk wrote:
> Hello,
>
> the following patch (against current kernel.org tree) adds MTD
> support for the NOR and NAND flashes on the "PPChameleon" modules /
> eval boards manufactured by DAVE s.r.l.
This should be submitted to the MTD maintainer(s).
-Matt
^ permalink raw reply
* Re: [PATCH 1/2] ppc32: Add initial support for DAVE "PPChameleon" board.
From: Matt Porter @ 2005-11-01 23:29 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: llandre, linuxppc-embedded
In-Reply-To: <20051012153817.D370D353A4F@atlas.denx.de>
On Wed, Oct 12, 2005 at 05:38:17PM +0200, Wolfgang Denk wrote:
> the following patch (against current kernel.org tree) adds suport for
> the "PPChameleon" modules / eval boards manufactured by DAVE s.r.l.
See comments below.
> +config PPChameleonEVB
> + bool "PPChameleonEVB"
> + help
> + This option enables support for the DAVE 405EP evaluation board.
> +
It's unusual to have a mixed case config option. Is there a better
option that makes sense? PP_CHAM_EVB?
> /* DCR defines */
> -#define DCRN_CPMSR_BASE 0x0BA
> -#define DCRN_CPMFR_BASE 0x0B9
> +#define DCRN_CPMSR_BASE 0x0BA
> +#define DCRN_CPMFR_BASE 0x0B9
Please drop these whitespace changes.
> -#define IBM_CPM_GPT 0x80000000 /* GPT interface */
> -#define IBM_CPM_PCI 0x40000000 /* PCI bridge */
> -#define IBM_CPM_UIC 0x00010000 /* Universal Int Controller */
> -#define IBM_CPM_CPU 0x00008000 /* processor core */
> -#define IBM_CPM_EBC 0x00002000 /* EBC controller */
> -#define IBM_CPM_SDRAM0 0x00004000 /* SDRAM memory controller */
> -#define IBM_CPM_GPIO0 0x00001000 /* General Purpose IO */
> -#define IBM_CPM_TMRCLK 0x00000400 /* CPU timers */
> -#define IBM_CPM_PLB 0x00000100 /* PLB bus arbiter */
> -#define IBM_CPM_OPB 0x00000080 /* PLB to OPB bridge */
> -#define IBM_CPM_DMA 0x00000040 /* DMA controller */
> -#define IBM_CPM_IIC0 0x00000010 /* IIC interface */
> -#define IBM_CPM_UART1 0x00000002 /* serial port 0 */
> -#define IBM_CPM_UART0 0x00000001 /* serial port 1 */
> +#define IBM_CPM_GPT 0x80000000 /* GPT interface */
> +#define IBM_CPM_PCI 0x40000000 /* PCI bridge */
> +#define IBM_CPM_UIC 0x00010000 /* Universal Int Controller */
> +#define IBM_CPM_CPU 0x00008000 /* processor core */
> +#define IBM_CPM_EBC 0x00002000 /* EBC controller */
> +#define IBM_CPM_SDRAM0 0x00004000 /* SDRAM memory controller */
> +#define IBM_CPM_GPIO0 0x00001000 /* General Purpose IO */
> +#define IBM_CPM_TMRCLK 0x00000400 /* CPU timers */
> +#define IBM_CPM_PLB 0x00000100 /* PLB bus arbiter */
> +#define IBM_CPM_OPB 0x00000080 /* PLB to OPB bridge */
> +#define IBM_CPM_DMA 0x00000040 /* DMA controller */
> +#define IBM_CPM_IIC0 0x00000010 /* IIC interface */
> +#define IBM_CPM_UART1 0x00000002 /* serial port 0 */
> +#define IBM_CPM_UART0 0x00000001 /* serial port 1 */
Same here, if whitespace chanes are important submit them separately.
> diff --git a/arch/ppc/platforms/4xx/ppchameleon.c b/arch/ppc/platforms/4xx/ppchameleon.c
> new file mode 100644
> --- /dev/null
<snip>
> +#if defined(CONFIG_BIOS_FIXUP)
> +void __init bios_fixup (struct pci_controller *hose, struct pcil0_regs *pcip)
<snip>
You don't use this bios_fixup garbage in this port (at least according
to your defconfig) so just drop it.
As an aside, this stuff is pretty awful and has been since 405 first
came into the tree. If the basic functionality were required, a new
port should simply reprogram the pci host bridge and let the pci
subsystem place the BARs.
-Matt
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Pantelis Antoniou @ 2005-11-01 22:55 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Dan Malek, linuxppc-embedded
In-Reply-To: <20051101172524.GA5623@logos.cnet>
On Tuesday 01 November 2005 19:25, Marcelo Tosatti wrote:
> On Sun, Oct 30, 2005 at 11:03:24PM +0300, Pantelis Antoniou wrote:
> > Latest MMU changes caused 8xx to stop working. Flushing tlb of the faulting
> > address fixes the problem.
>
> Hi Panto,
>
> Its working fine around here. How much of a vanilla 2.6.14 your is?
>
> [root@CAS root]# cat /proc/cpuinfo
> processor : 0
> cpu : 8xx
> clock : 48MHz
> bus clock : 48MHz
> revision : 0.0 (pvr 0050 0000)
> bogomips : 47.82
> [root@CAS root]# uname -a
> Linux CAS 2.6.14 #2 Tue Nov 1 16:20:28 CST 2005 ppc unknown
>
>
Vanila 2.6.14 worked fine too.
It's the mm patches that started coming in later.
Unfortunately the version did not change, so I can't provide it.
Did you used a current git tree?
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Marcelo Tosatti @ 2005-11-01 17:25 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Dan Malek, linuxppc-embedded
In-Reply-To: <200510302203.25390.pantelis.antoniou@gmail.com>
On Sun, Oct 30, 2005 at 11:03:24PM +0300, Pantelis Antoniou wrote:
> Latest MMU changes caused 8xx to stop working. Flushing tlb of the faulting
> address fixes the problem.
Hi Panto,
Its working fine around here. How much of a vanilla 2.6.14 your is?
[root@CAS root]# cat /proc/cpuinfo
processor : 0
cpu : 8xx
clock : 48MHz
bus clock : 48MHz
revision : 0.0 (pvr 0050 0000)
bogomips : 47.82
[root@CAS root]# uname -a
Linux CAS 2.6.14 #2 Tue Nov 1 16:20:28 CST 2005 ppc unknown
^ permalink raw reply
* Re: Makefile check for older binutils broken?
From: Marcelo Tosatti @ 2005-11-01 16:33 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20051028161054.GB22245@smtp.west.cox.net>
> > Yep, that does the trick. Is it good now?
>
> Er, that's odd. I was using writing parens, not shell parens :) Can
> you test the failure case here by changing dssall to garbage? Also,
> that's not a clean patch, but vs your last one that wasn't valid.
Problem is specific to invocation of "make" inside a (particular) Makefile.
Again, sorry for you wasting your time.
^ permalink raw reply
* RE: AMCC440EP Boot Source
From: Steven Blakeslee @ 2005-11-01 16:43 UTC (permalink / raw)
To: Dick Hollenbeck, linuxppc-dev
> We are looking at the yosemite design but want a CF2 socket=20
> for the OS=20
> image. Can U-Boot reside in the EEPROM accessible via I2C? =20
Are you sure that the 440EP can run code from the EEPROM on the I2C?
The 440EP loads configuration information from the EEPROM on the I2C but
I don't know it can run code.=20
>=20
> This would allow us to remove the flash entirely in favor of=20
> the CF2 flash. If yes, are there any drawbacks to this vs.=20
> keeping a small bit of flash soldered to the board?
I'm pretty sure you need to have flash. If you don't want the onboard
flash you can connect some through the PCI.
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Mark A. Greer @ 2005-11-01 16:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev, Sven Luther
In-Reply-To: <17255.13444.672360.996441@cargo.ozlabs.ibm.com>
On Tue, Nov 01, 2005 at 08:25:24PM +1100, Paul Mackerras wrote:
> Mark A. Greer writes:
>
> > It does have a PIC, DMA engine, and SRAM that Sven mentioned but there
> > are also a serial controller (MPSC), an i2c controller, and a watchdog
> > timer. I would guess that the MPSC and i2c drivers, at least, should
> > use MODULE_DEVICE_TABLE. If you agree, I'll add it to the list.
>
> But the point is that if one driver has claimed the device (because
> its ID is in its module device table), the other drivers won't be able
> to.
Okay. TBH, I still have to look at what the MODULE_DEVICE_TABLE does so
it was ignorance + laziness on my part.
> You need something like the macio driver that BenH did, which
> claims the macio device and creates a macio bus structure and allows
> individual macio device drivers to claim the pieces of it.
I'll take a look.
Mark
^ permalink raw reply
* Re: [PATCH] ppc32: Fix SCC Uart write problem after 2. open()
From: Dan Malek @ 2005-11-01 16:08 UTC (permalink / raw)
To: hs; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <AHEILKONAKAEJPHNMOPNMEFBCDAA.hs@denx.de>
On Nov 1, 2005, at 2:17 AM, Heiko Schocher wrote:
> The following Patch will fix this problem.
This is wrong. We should never have to reinitialize the
buffer descriptors (which I see the driver does in some cases)
and we certainly should never have to reinitialize the
SCC or SMC peripherals like this.
Once the driver has initialized the SCC or SMC and set up
the buffer descriptors during kernel start up, it should never
be done again. The only thing we should do is stop/start
the transmitter or receiver, and they should continue operation
with the next buffer descriptor in the ring.
This patch just covers up a driver bug, find and fix the real bug.
Thanks.
-- Dan
^ 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