* Need help on adding a command to my ramdi sk
From: Denny @ 2006-06-27 1:38 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
In-Reply-To: <44A08BA0.000020.01911@bj163app63.163.com>
[-- Attachment #1: Type: text/plain, Size: 256 bytes --]
Hi,
Since there is no "ldd" command in busybox1.1.3, so I copied it from ELDK4.0 to my bin,
but it didn't work, can anybody tell me how to add a new command to my ramdisk ?
bash-3.00# ldd /bin/ftp
sh: applet not found
bash-3.00#
- Denny
[-- Attachment #2: Type: text/html, Size: 889 bytes --]
^ permalink raw reply
* Need help on adding a command to my ramdi sk
From: Denny @ 2006-06-27 1:36 UTC (permalink / raw)
To: de; +Cc: linuxppc-embedded
In-Reply-To: <44A08AEC.000113.30549@bj163app63.163.com>
[-- Attachment #1: Type: text/plain, Size: 255 bytes --]
Hi,
Since there is no "ldd" command in busybox1.1.3, so I copied it from ELDK4.0 to my bin,
but it didn't work, can anybody tell me how to add a new command to my ramdisk ?
bash-3.00# ldd /bin/ftp
sh: applet not found
bash-3.00#
- Denny
[-- Attachment #2: Type: text/html, Size: 876 bytes --]
^ permalink raw reply
* Need help on ftp and telnet in my Ramdisk
From: Denny @ 2006-06-27 1:33 UTC (permalink / raw)
To: de; +Cc: linuxppc-embedded
In-Reply-To: <44A01925.9050100@ovro.caltech.edu>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
Hi,
1. I copied the ftp and telnet commands to my /bin, and the needed library is also copied to my /lib, but they still don't work so far, can anybody tell me why, thanks!
logs:
...
RAMDISK: Compressed image found at block 0
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 120k init
init started: BusyBox v1.1.3 (2006.06.23-09:32+0000) multi-call binary
Bad inittab entry: :reth0: link is up, 100 FDX
Starting pid 23, console /dev/ttyS1: '/bin/application'
Starting pid 24, console /dev/ttyS1: '/bin/bash'
### Application running ...
bash-3.00# ]
bash: ]: command not found
bash-3.00#
bash-3.00#
bash-3.00#
bash-3.00#
bash-3.00# ftp 192.168.65.143
ftp: ftp/tcp: unknown service
bash-3.00# telnet 192.168.65.143
telnet: telnet: bad port
Starting pid 29, console /dev/ttyS1: '/bin/application'
Starting pid 30, console /dev/ttyS1: '/bin/bash'
### Application running ...
Starting pid 33, console /dev/ttyS1: '/bin/bash'
Starting pid 32, console /dev/ttyS1: '/bin/application'
### Application running ...
bash-3.00#
Thanks!
- Denny
[-- Attachment #2: Type: text/html, Size: 1803 bytes --]
^ permalink raw reply
* Need help on ftp and telnet in my Ramdisk
From: Denny @ 2006-06-27 1:39 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
In-Reply-To: <44A08AEC.000113.30549@bj163app63.163.com>
[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]
Hi,
1. I copied the ftp and telnet commands to my /bin, and the needed library is also copied to my /lib, but they still don't work so far, can anybody tell me why, thanks!
logs:
...
RAMDISK: Compressed image found at block 0
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 120k init
init started: BusyBox v1.1.3 (2006.06.23-09:32+0000) multi-call binary
Bad inittab entry: :reth0: link is up, 100 FDX
Starting pid 23, console /dev/ttyS1: '/bin/application'
Starting pid 24, console /dev/ttyS1: '/bin/bash'
### Application running ...
bash-3.00# ]
bash: ]: command not found
bash-3.00#
bash-3.00#
bash-3.00#
bash-3.00#
bash-3.00# ftp 192.168.65.143
ftp: ftp/tcp: unknown service
bash-3.00# telnet 192.168.65.143
telnet: telnet: bad port
Starting pid 29, console /dev/ttyS1: '/bin/application'
Starting pid 30, console /dev/ttyS1: '/bin/bash'
### Application running ...
Starting pid 33, console /dev/ttyS1: '/bin/bash'
Starting pid 32, console /dev/ttyS1: '/bin/application'
### Application running ...
bash-3.00#
Thanks!
- Denny
[-- Attachment #2: Type: text/html, Size: 1873 bytes --]
^ permalink raw reply
* Re: [RFC 01/12] snd-powermac: no longer handle anything with a layout-id property
From: Andreas Schwab @ 2006-06-26 20:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel, netstar
In-Reply-To: <20060607130910.156412000@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> This patch removes from snd-powermac the code that check for the layout-id
> and instead adds code that makes it refuse loading when a layout-id property
> is present, nothing that snd-aoa should be used.
Can we get snd-powermac back as long as snd-aoa is lacking all those
features from snd-powermac?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: zero-copy support on TSEC?
From: Andy Fleming @ 2006-06-26 19:56 UTC (permalink / raw)
To: Bizhan Gholikhamseh; +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA9112796415019ED1C6@xmb-sjc-212.amer.cisco.com>
On Jun 26, 2006, at 13:26, Bizhan Gholikhamseh ((bgholikh)) wrote:
> Hi ALL,
> We have developed a custom board mother board based on
> MPC8541 processor running Linux 2.6.11.
>
> In our system, most of the ingress UDP packets are retransmitted
> with one modification to data portion of the packet (one byte). As you
> see there are many copy overhead due to copy from system to userland
> and vise versa which has impacted our system performance.
>
> Is there a zero-copy support for TSEC
> to eliminate the buffer copy from kernel to userland and vise versa?
I'm not sure there's any way, at present, in Linux to avoid the user/
kernel copying. You might want to ask on the netdev@vger.kernel.org
list, though.
Andy
^ permalink raw reply
* [PATCH] powerpc: build fix for ppc32 with CONFIG_KEXEC
From: Haren Myneni @ 2006-06-26 19:14 UTC (permalink / raw)
To: vgoyal
Cc: linuxppc-dev, Fastboot mailing list, linux-kernel,
Troy Benjegerdes, ellerman
In-Reply-To: <20060626135801.GC8985@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
Vivek Goyal wrote:
>On Mon, Jun 26, 2006 at 01:31:28AM -0500, Troy Benjegerdes wrote:
>
>
>>various things like 'reserve_crashkernel' are referenced, but only
>>exist in arch/powerpc/kernel/machine_kexec_64.c.
>>
>>
>>
>
>I think for ppc32 the framework is present for kexec/kdump but nobody
>is actively testing/maintaining it as of today.
>
>
At present, even though kexec support is included for PPC32, I believe,
it has been actively tested/maintained only on gamecube.
Michael, if you are OK with this patch, please send it to upstream.
Thanks
Haren
arch/powerpc/kernel/built-in.o(.init.text+0x1c98): In function
`early_init_devtree':
: undefined reference to `reserve_crashkernel'
arch/powerpc/kernel/built-in.o(.init.text+0x1d90): In function
`early_init_devtree':
: undefined reference to `overlaps_crashkernel'
This patch will fix the above build errors on ppc32 with CONFIG_KEXEC.
Both reserve_crashkernel() and overlaps_crashkernel() should be moved to
machine_kexec.c() after the kdump support is included on ppc32.
Signed-off-by: Haren Myneni <haren@us.ibm.com>
>Thanks
>Vivek
>_______________________________________________
>fastboot mailing list
>fastboot@lists.osdl.org
>https://lists.osdl.org/mailman/listinfo/fastboot
>
>
[-- Attachment #2: ppc32-kexec-build-fix.patch --]
[-- Type: text/x-patch, Size: 527 bytes --]
--- linux-2.6.17-git10/arch/powerpc/kernel/machine_kexec_32.c.orig 2006-06-26 05:33:51.000000000 -0700
+++ linux-2.6.17-git10/arch/powerpc/kernel/machine_kexec_32.c 2006-06-26 05:47:04.000000000 -0700
@@ -63,3 +63,16 @@ int default_machine_kexec_prepare(struct
{
return 0;
}
+
+/*
+ * FIXME: Move the following functions to machine_kexec.c after
+ * kdump support is included on ppc32.
+ */
+void __init reserve_crashkernel(void)
+{
+}
+
+int overlaps_crashkernel(unsigned long start, unsigned long size)
+{
+ return 0;
+}
^ permalink raw reply
* zero-copy support on TSEC?
From: Bizhan Gholikhamseh (bgholikh) @ 2006-06-26 18:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
Hi ALL,
We have developed a custom board mother board based on
MPC8541 processor running Linux 2.6.11.
In our system, most of the ingress UDP packets are retransmitted
with one modification to data portion of the packet (one byte). As you
see there are many copy overhead due to copy from system to userland
and vise versa which has impacted our system performance.
Is there a zero-copy support for TSEC
to eliminate the buffer copy from kernel to userland and vise versa?
Are there any other technique that we need to do to eliminate packet
coping?
Many thanks in advance,
Bizhan
[-- Attachment #2: Type: text/html, Size: 3018 bytes --]
^ permalink raw reply
* Re: Need help ragarding MPC8360 Kernel bootup failure
From: David Hawkins @ 2006-06-26 17:28 UTC (permalink / raw)
To: sudheer; +Cc: linuxppc-embedded
In-Reply-To: <44A00EF4.6000109@gmail.com>
> CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.00.0 | VT102 | Offline
Your minicom is set to 115200, so your U-Boot must be using that,
but you'll need to tell Linux too, try:
console=ttyS0,115200
Dave
^ permalink raw reply
* Need help ragarding MPC8360 Kernel bootup failure
From: sudheer @ 2006-06-26 16:44 UTC (permalink / raw)
To: linuxppc-embedded
Hello all,
I need help regarding the bootup of linux on MPC8360 MDS Board.
After doing tftp the uImage from u-boot, with the bootm command the
kernel gets uncompressed and stops there.
The serial output from kernel could not be seen.
Source being used:
uboot - U-Boot-1.1.3
linux - Linux-2.6.11 supporting mpc8360epb.
board - MPC8360 MDS
The dump is below:
U-Boot 1.1.3 (ppc83xx-20050315-dev) (Dec 14 2005 - 09:37:59) MPC83XX
Clock configuration:
Coherent System Bus: 264 MHz
Core: 528 MHz
QE: 396 MHz
Local Bus Controller: 264 MHz
Local Bus: 66 MHz
DDR: 264 MHz
DDR Secondary: 264 MHz
I2C: 264 MHz
CPU: MPC83xx, Rev: 20 at 528 MHz
Board: Freescale MPC8360EPB
I2C: ready
DRAM:
SDRAM on Local Bus: 64 MB
DDR RAM: 256 MB
FLASH: 16 MB
In: serial
Out: serial
Err: serial
Net: FSL GETH0
Hit any key to stop autoboot: 0
=> printenv
bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netrramboot=setenv
bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp
$ramdiskaddr $ramdiskfile;tftp $loarnfsboot=setenv bootargs root=/dev/nfs
rw nfsroot=$serverip:$rootpath
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netrbootdelay=6
baudrate=115200
loads_echo=1
ethaddr=00:04:9f:11:22:33
eth1addr=00:E0:0C:00:7D:01
hostname=unknown
loadaddr=200000
netdev=eth0
consoledev=ttyS0
ramdiskaddr=400000
ramdiskfile=ramfs.83xx
ethact=FSL GETH0
filesize=2d030a
fileaddr=20000
gatewayip=192.168.3.1
netmask=255.255.255.0
serverip=192.168.3.81
bootfile=/tftpboot/vmlinux.gz
ipaddr=192.168.3.253
stdin=serial
stdout=serial
stderr=serial
Environment size: 1005/8188 bytes
=> setenv bootargs console=ttyS1 root=/dev/ram
=> tftp 200000 uImage_test
Auto negotiating done
switching to rgmii 100
duplexity: full
mac speed set to: 100
Using FSL GETH0 device
TFTP from server 192.168.3.81; our IP address is 192.168.3.253
Filename 'uImage_test'.
Load address: 0x200000
Loading: #################################################################
#################################################################
#################################################################
#######
done
Bytes transferred = 1033098 (fc38a hex)
=> bootm 200000
## Booting image at 00200000 ...
Image Name: Linux-2.6.11.12
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1033034 Bytes = 1008.8 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.00.0 | VT102 | Offline
------------
After Uncompressing kernel, nothing comes onto the minicom.
I have tried the console env in bootargs to ttyS0, ttyS1, ttyCPM0, ttyCPM1, ttyUCC0. But could not succeed.
Anyone Please help me in this regard.
Thanks & Regards
Sudheer
^ permalink raw reply
* Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Florian Boelstler @ 2006-06-26 14:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060626172546.6bc37173@vitb.ru.mvista.com>
Vitaly Bordug schrieb:
> From what I know, yes, 2/24 is the latest. But you'll need some tricks in order to utilize PCI-xp...
Thanks for your response. I will contact FSL.
May you share those tricks for PCIe utilization? :)
Florian
^ permalink raw reply
* Re: [PATCH 6/6] [RFC] POWERPC: Add mpc8560 board support
From: Kumar Gala @ 2006-06-26 13:35 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20060624211708.0d6039b2@localhost.localdomain>
[snip]
>>> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/
>>> Makefile
>>> index cef95b0..75dfe12 100644
>>> --- a/arch/powerpc/sysdev/Makefile
>>> +++ b/arch/powerpc/sysdev/Makefile
>>> @@ -12,3 +12,10 @@ obj-$(CONFIG_U3_DART) +=
>>> dart_iommu.o obj-$(CONFIG_MMIO_NVRAM) += mmio_nvram.o
>>> obj-$(CONFIG_PPC_83xx) += ipic.o
>>> obj-$(CONFIG_FSL_SOC) += fsl_soc.o
>>> +
>>> +# Temporary hack until we have migrated to asm-powerpc
>>> +ifeq ($(ARCH),powerpc)
>>> +obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o
>>> +endif
>>
>> See earlier comments about just building in arch/powerpc
>>
> Hrm, here I am not completely sure it's a good thing. The point is
> that
> currently some OF-specific stuff is under construction to go into
> cpm2_common at least (for instance, getting rid of CPM_MAP_ADDR
> ioremap because the offset is available via oftree, and things like
> that).
If that's the case, make a duplicate of cpm2_common.c, however I dont
think you need the ifeq... to make that work.
>>> +
>>> +#obj-$(CONFIG_CPM2) += cpm2/
what's in the cpm2 directory?
[snip]
>>> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/
>>> fsl_soc.c
>>> index ceb5846..bab202d 100644
>>> --- a/arch/powerpc/sysdev/fsl_soc.c
>>> +++ b/arch/powerpc/sysdev/fsl_soc.c
>>> @@ -21,6 +21,8 @@ #include <linux/module.h>
>>> #include <linux/device.h>
>>> #include <linux/platform_device.h>
>>> #include <linux/fsl_devices.h>
>>> +#include <linux/fs_enet_pd.h>
>>> +#include <linux/fs_uart_pd.h>
>>>
>>> #include <asm/system.h>
>>> #include <asm/atomic.h>
>>> @@ -30,6 +32,10 @@ #include <asm/prom.h>
>>> #include <sysdev/fsl_soc.h>
>>> #include <mm/mmu_decl.h>
>>>
>>> +#ifdef CONFIG_CPM2
>>> +#include <asm/cpm2.h>
>>> +#endif
>>> +
>>> static phys_addr_t immrbase = -1;
>>>
>>> phys_addr_t get_immrbase(void)
>>> @@ -43,7 +49,9 @@ phys_addr_t get_immrbase(void)
>>> if (soc) {
>>> unsigned int size;
>>> void *prop = get_property(soc, "reg", &size);
>>> - immrbase = of_translate_address(soc, prop);
>>> +
>>> + if (prop)
>>> + immrbase = of_translate_address(soc, prop);
>>> of_node_put(soc);
>>> };
>>>
>>> @@ -51,7 +59,79 @@ phys_addr_t get_immrbase(void)
>>> }
>>>
>>> EXPORT_SYMBOL(get_immrbase);
>>> +
>>> +static u32 brgfreq = -1;
>>> +
>>> +u32 get_brgfreq(void)
>>> +{
>>> + struct device_node *node;
>>> +
>>> + if (brgfreq != -1)
>>> + return brgfreq;
>>> +
>>> + node = of_find_node_by_type(NULL, "serial");
>>> + if (node) {
>>> + unsigned int size;
>>> + unsigned int *prop = (unsigned
>>> int*)get_property(node, "clock- frequency", &size);
>>> +
>>> + if (prop)
>>> + brgfreq = *prop;
>>> + of_node_put(node);
>>> + };
>>> +
>>> + return brgfreq;
>>> +}
>>
>> These seems broken on a system w/both CPM & 8250 style uarts.
>>
> Yeah, missed that.
>
>>> +
>>> +EXPORT_SYMBOL(get_brgfreq);
>>> +
>>> +static u32 fs_baudrate = -1;
>>> +
>>> +u32 get_baudrate(void)
>>> +{
>>> + struct device_node *node;
>>>
>>> + if (fs_baudrate != -1)
>>> + return fs_baudrate;
>>> +
>>> + node = of_find_node_by_type(NULL, "serial");
>>> + if (node) {
>>> + unsigned int size;
>>> + unsigned int *prop = (unsigned
>>> int*)get_property(node, "current- speed", &size);
>>> +
>>> + if (prop)
>>> + fs_baudrate = *prop;
>>> + of_node_put(node);
>>> + };
>>> +
>>> + return fs_baudrate;
>>> +}
>>> +
>>> +EXPORT_SYMBOL(get_baudrate);
>>> +
>>> +static u32 intfreq = -1;
>>> +
>>> +u32 get_intfreq(void)
>>> +{
>>> + struct device_node *node;
>>> +
>>> + if (intfreq != -1)
>>> + return intfreq;
>>> +
>>> + node = of_find_node_by_type(NULL, "cpu");
>>> + if (node) {
>>> + unsigned int size;
>>> + unsigned int *prop = (unsigned
>>> int*)get_property(node, "clock- frequency", &size);
>>> + if (prop)
>>> + intfreq = *prop;
>>> + of_node_put(node);
>>> + }
>>> +
>>> + return intfreq;
>>> +}
>>> +
>>> +EXPORT_SYMBOL(get_intfreq);
>>> +
>>
>> Don't we have something that reports "clock-frequency" elsewhere?
>>
>
> If yes, I haven't found... Mind pointing where to look at?
ppc_proc_freq in kernel/time.c
>>> +
>>> static int __init gfar_mdio_of_init(void)
>>> {
>>> struct device_node *np;
>>> @@ -491,3 +571,211 @@ err:
>>> }
>>>
>>> arch_initcall(fsl_usb_dr_of_init);
>>> +
>>> +static const char *fcc_regs = "fcc_regs";
>>> +static const char *fcc_regs_c = "fcc_regs_c";
>>> +static const char *fcc_pram = "fcc_pram";
>>> +static char bus_id[9][BUS_ID_SIZE];
>>> +
>>> +static int __init fs_enet_of_init(void)
>>> +{
>>> + struct device_node *np;
>>> + unsigned int i;
>>> + struct platform_device *fs_enet_dev;
>>> + struct resource res;
>>> + int ret;
>>> +
>>> + for (np = NULL, i = 0;
>>> + (np = of_find_compatible_node(np, "network",
>>> "fs_enet")) != NULL;
>>> + i++) {
>>> + struct resource r[4];
>>> + struct device_node *phy, *mdio;
>>> + struct fs_platform_info fs_enet_data;
>>> + unsigned int *id, *phy_addr;
>>> + void *mac_addr;
>>> + phandle *ph;
>>> + char *model;
>>> +
>>> + memset(r, 0, sizeof(r));
>>> + memset(&fs_enet_data, 0, sizeof(fs_enet_data));
>>> +
>>> + ret = of_address_to_resource(np, 0, &r[0]);
>>> + if (ret)
>>> + goto err;
>>> + r[0].name = fcc_regs;
>>> +
>>> + ret = of_address_to_resource(np, 1, &r[1]);
>>> + if (ret)
>>> + goto err;
>>> + r[1].name = fcc_pram;
>>> +
>>> + ret = of_address_to_resource(np, 2, &r[2]);
>>> + if (ret)
>>> + goto err;
>>> + r[2].name = fcc_regs_c;
>>> +
>>> + r[3].start = np->intrs[0].line;
>>> + r[3].end = np->intrs[0].line;
>>> + r[3].flags = IORESOURCE_IRQ;
>>> +
>>> + fs_enet_dev =
>>> + platform_device_register_simple("fsl-cpm-fcc",
>>> i, &r[0], 4); +
>>> + if (IS_ERR(fs_enet_dev)) {
>>> + ret = PTR_ERR(fs_enet_dev);
>>> + goto err;
>>> + }
>>> +
>>> + model = get_property(np, "model", NULL);
>>> + if (model == NULL) {
>>> + ret = -ENODEV;
>>> + goto unreg;
>>> + }
>>> +
>>> + mac_addr = get_property(np, "mac-address", NULL);
>>> + memcpy(fs_enet_data.macaddr, mac_addr, 6);
>>> +
>>> + ph = (phandle *) get_property(np, "phy-handle",
>>> NULL);
>>> + phy = of_find_node_by_phandle(*ph);
>>> +
>>> + if (phy == NULL) {
>>> + ret = -ENODEV;
>>> + goto unreg;
>>> + }
>>> +
>>> + phy_addr = (u32 *) get_property(phy, "reg", NULL);
>>> + fs_enet_data.phy_addr = *phy_addr;
>>> +
>>> + id = (u32 *) get_property(np, "device-id", NULL);
>>> + fs_enet_data.fs_no = *id;
>>> +
>>> + mdio = of_get_parent(phy);
>>> + ret = of_address_to_resource(mdio, 0, &res);
>>> + if (ret) {
>>> + of_node_put(phy);
>>> + of_node_put(mdio);
>>> + goto unreg;
>>> + }
>>> +
>>> + switch (*id) {
>>> + case fsid_fcc1:
>>> + fs_enet_data.mem_offset = FCC1_MEM_OFFSET,
>>> + snprintf((char*)&bus_id[2], BUS_ID_SIZE,
>>> "%x:%02x", (u32) res.start, fs_enet_data.phy_addr);
>>> + fs_enet_data.bus_id = (char*)&bus_id[2];
>>> + fs_enet_data.cp_page = CPM_CR_FCC1_PAGE;
>>> + fs_enet_data.cp_block = CPM_CR_FCC1_SBLOCK;
>>> + break;
>>> + case fsid_fcc2:
>>> + fs_enet_data.mem_offset = FCC2_MEM_OFFSET,
>>> + snprintf((char*)&bus_id[3], BUS_ID_SIZE,
>>> "%x:%02x", (u32) res.start, fs_enet_data.phy_addr);
>>> + fs_enet_data.bus_id = (char*)&bus_id[3];
>>> + fs_enet_data.cp_page = CPM_CR_FCC2_PAGE;
>>> + fs_enet_data.cp_block = CPM_CR_FCC2_SBLOCK;
>>> + break;
>>> + case fsid_fcc3:
>>> + fs_enet_data.mem_offset = FCC3_MEM_OFFSET,
>>> + snprintf((char*)&bus_id[4], BUS_ID_SIZE,
>>> "%x:%02x", (u32) res.start, fs_enet_data.phy_addr);
>>> + fs_enet_data.bus_id = (char*)&bus_id[4];
>>> + fs_enet_data.cp_page = CPM_CR_FCC3_PAGE;
>>> + fs_enet_data.cp_block = CPM_CR_FCC3_SBLOCK;
>>> + break;
>>> + }
>>
>> this looks like a lot of effort to just encode a single integer (1,
>> 2, 3) and then lookup the other information based on it.
>>
>
> Not sure I am following what is suggested here. Could it be elaborated
> a little bit ?
I saying all you need to store is the fact that its a FCC and its
number 1, 2, 3... after which we can have some table in cpm2_common.c
that provides back cp_page, cp_block based on type and number.
Encoding it fs_enet_data is just a duplication.
>>> +
>>> + if (strstr(model, "FCC")) {
>>> + fs_enet_data.dpram_offset =
>>> (u32)cpm2_immr->im_dprambase;
>>> + fs_enet_data.rx_ring = 32;
>>> + fs_enet_data.tx_ring = 32;
>>> + fs_enet_data.rx_copybreak = 240;
>>> + fs_enet_data.use_napi = 0;
>>> + fs_enet_data.napi_weight = 17;
>>> + }
>>> +
>>> + of_node_put(phy);
>>> + of_node_put(mdio);
>>> +
>>> + ret = platform_device_add_data(fs_enet_dev,
>>> &fs_enet_data,
>>> + sizeof(struct
>>> +
>>> fs_platform_info));
>>> + if (ret)
>>> + goto unreg;
>>> + }
>>> + return 0;
>>> +
>>> +unreg:
>>> + platform_device_unregister(fs_enet_dev);
>>> +err:
>>> + return ret;
>>> +}
>>> +
>>> +arch_initcall(fs_enet_of_init);
>>> +
>>> +static const char *scc_regs = "regs";
>>> +static const char *scc_pram = "pram";
>>> +
>>> +static int __init cpm_uart_of_init(void)
>>> +{
>>> + struct device_node *np;
>>> + unsigned int i;
>>> + struct platform_device *cpm_uart_dev;
>>> + int ret;
>>> +
>>> +
>>> + for (np = NULL, i = 0;
>>> + (np = of_find_compatible_node(np, "serial",
>>> "cpm_uart")) != NULL;
>>> + i++) {
>>> + struct resource r[3];
>>> + struct fs_uart_platform_info cpm_uart_data;
>>> + int *id;
>>> +
>>> + memset(r, 0, sizeof(r));
>>> + memset(&cpm_uart_data, 0, sizeof(cpm_uart_data));
>>> +
>>> + ret = of_address_to_resource(np, 0, &r[0]);
>>> + if (ret)
>>> + goto err;
>>> +
>>> + r[0].name = scc_regs;
>>> +
>>> + ret = of_address_to_resource(np, 1, &r[1]);
>>> + if (ret)
>>> + goto err;
>>> + r[1].name = scc_pram;
>>> +
>>> + r[2].start = np->intrs[0].line;
>>> + r[2].end = np->intrs[0].line;
>>> + r[2].flags = IORESOURCE_IRQ;
>>> +
>>> + cpm_uart_dev =
>>> +
>>> platform_device_register_simple("fsl-cpm-scc:uart", i, &r [0], 3);
>>> +
>>> + if (IS_ERR(cpm_uart_dev)) {
>>> + ret = PTR_ERR(cpm_uart_dev);
>>> + goto err;
>>> + }
>>> +
>>> + id = get_property(np, "device-id", NULL);
>>> + cpm_uart_data.fs_no = *id;
>>> + cpm_uart_data.uart_clk = get_intfreq();
>>> +
>>> + cpm_uart_data.tx_num_fifo = 4;
>>> + cpm_uart_data.tx_buf_size = 32;
>>> + cpm_uart_data.rx_num_fifo = 4;
>>> + cpm_uart_data.rx_buf_size = 32;
>>> +
>>> + ret =
>>> + platform_device_add_data(cpm_uart_dev,
>>> &cpm_uart_data,
>>> + sizeof(struct
>>> +
>>> fs_uart_platform_info));
>>> + if (ret)
>>> + goto unreg;
>>> + }
>>> +
>>> + return 0;
>>> +
>>> +unreg:
>>> + platform_device_unregister(cpm_uart_dev);
>>> +err:
>>> + return ret;
>>> +}
>>> +
>>> +arch_initcall(cpm_uart_of_init);
>>> diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
>>> index f6a7ff0..8e6840b 100644
>>> --- a/include/asm-ppc/cpm2.h
>>> +++ b/include/asm-ppc/cpm2.h
>>> @@ -1186,7 +1186,7 @@ #define PC3_DIRC1 (PC3_TXDAT)
>>> #define FCC_MEM_OFFSET(x) (CPM_FCC_SPECIAL_BASE + (x*128))
>>> #define FCC1_MEM_OFFSET FCC_MEM_OFFSET(0)
>>> #define FCC2_MEM_OFFSET FCC_MEM_OFFSET(1)
>>> -#define FCC2_MEM_OFFSET FCC_MEM_OFFSET(2)
>>> +#define FCC3_MEM_OFFSET FCC_MEM_OFFSET(2)
>>>
>>> #endif /* __CPM2__ */
>>> #endif /* __KERNEL__ */
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>
^ permalink raw reply
* Re: MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Vitaly Bordug @ 2006-06-26 13:25 UTC (permalink / raw)
To: Florian Boelstler; +Cc: linuxppc-embedded
In-Reply-To: <e7oe1r$k2o$1@sea.gmane.org>
On Mon, 26 Jun 2006 12:48:27 +0200
Florian Boelstler <euphoria@arcor.de> wrote:
> Hi,
>=20
> I am currently working on a MPC8548-based development system.
> Linux kernel version is 2.6.11 with patches delivered from Freescale=20
> (BSP MPC8548CDS 02/24/2006).
>=20
> Kernel configuration contains a warning message for CONFIG_PEX:
> "This requires hardware modification to work correctly if your CPU=20
> version < 2.0 and will break the PCI bus. [...]"
>=20
> I was wondering whether enabling PCIe makes PCI bus functionality=20
> unusable at all (including kernel functionality for detecting devices=20
> behind a transparent PCI-to-PCI bridge).
>=20
IIRC,yes.
> Our setup connects a transparent PLX8516 PCI-to-PCI bridge to the PCIe=20
> port of the MPC8548 daughter board. Behind that bridge is another PCIe=20
> capable device.
> MPC8548 is configured to run as PCIe host mode.
>=20
> When trying to lookup the PCIe devices using lspci I can only see the=20
> PPC itself and the bridge.
> However I cannot see the device(s) behind the bridge.
>=20
That's highly depends on silicon and Arcadia rev. you are using. There are =
some other details=20
about PCI-XP, but to inquire the certain information, you should contact FS=
L support.
> Is there another method for detecting PCI(e) devices?
> Is "BSP MPC8548CDS 02/24/2006" the latest version corresponding to that=20
> hardware?
>=20
=46rom what I know, yes, 2/24 is the latest. But you'll need some tricks in o=
rder to utilize PCI-xp...
--=20
Sincerely,=20
Vitaly
^ permalink raw reply
* MPC8548 PCIe / PCI support with BSP MPC8548CDS 02/24/2006
From: Florian Boelstler @ 2006-06-26 10:48 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am currently working on a MPC8548-based development system.
Linux kernel version is 2.6.11 with patches delivered from Freescale
(BSP MPC8548CDS 02/24/2006).
Kernel configuration contains a warning message for CONFIG_PEX:
"This requires hardware modification to work correctly if your CPU
version < 2.0 and will break the PCI bus. [...]"
I was wondering whether enabling PCIe makes PCI bus functionality
unusable at all (including kernel functionality for detecting devices
behind a transparent PCI-to-PCI bridge).
Our setup connects a transparent PLX8516 PCI-to-PCI bridge to the PCIe
port of the MPC8548 daughter board. Behind that bridge is another PCIe
capable device.
MPC8548 is configured to run as PCIe host mode.
When trying to lookup the PCIe devices using lspci I can only see the
PPC itself and the bridge.
However I cannot see the device(s) behind the bridge.
Is there another method for detecting PCI(e) devices?
Is "BSP MPC8548CDS 02/24/2006" the latest version corresponding to that
hardware?
Thanks in advance,
Florian
^ permalink raw reply
* [PATCH] Skip the "copy down" of the kernel if it is already at zero.
From: Jimi Xenidis @ 2006-06-26 8:56 UTC (permalink / raw)
To: linuxppc-dev
This patch allows the kernel to recognized that it was loaded at zero
and the copy down of the image is unnecessary. This is useful for
Simulators and kexec models.
On a typical 3.8 MiB vmlinux.strip this saves about 2.3 million instructions.
---
arch/powerpc/kernel/head_64.S | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
88f9d7e234b31d5b06decf266414ba2e920ede3e
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index b7d1404..cd57a6b 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -1654,6 +1654,9 @@ _STATIC(__after_prom_start)
/* i.e. where we are running */
/* the source addr */
+ cmpdi r4,0 /* In some cases the loader may */
+ beq .start_here_multiplatform /* have already put us at zero */
+ /* so we can skip the copy. */
LOAD_REG_IMMEDIATE(r5,copy_to_here) /* # bytes of memory to copy */
sub r5,r5,r27
--
1.3.3
^ permalink raw reply related
* Re: [PATCH 5/5] spufs: fix spufs_mfc_flush prototype
From: Arnd Bergmann @ 2006-06-25 23:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, cbe-oss-dev, linux-kernel
In-Reply-To: <20060623185825.158050000@klappe.arndb.de>
On Friday 23 June 2006 20:57, arnd@arndb.de wrote:
> The prototype for the flush file operation now has another
> argument in 2.6.18.
Al Viro already submitted this one, please ignore it.
Arnd <><
^ permalink raw reply
* Re: Current DTC home
From: Jon Loeliger @ 2006-06-25 15:32 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <C9D27666-9F77-41AE-9D77-A2E788E1ACD2@watson.ibm.com>
So, like, the other day Jimi Xenidis mumbled:
> Shall we continue sending patches to linuxppc-dev?
> -JX
Please.
If you feel so inclined, a CC: to jdl@jdl.com works too.
jdl
^ permalink raw reply
* Re: Current DTC home
From: Jimi Xenidis @ 2006-06-25 15:22 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1FuVZ4-0002SZ-An@jdl.com>
Shall we continue sending patches to linuxppc-dev?
-JX
On Jun 25, 2006, at 10:26 AM, Jon Loeliger wrote:
> So, like, the other day Josh Boyer mumbled:
>> Hi,
>>
>> I found multiple pages/trees while I was looking around for where the
>> most current homepage/release for the DTC was. So far, there's:
>>
>> http://dtc.ozlabs.org/
>>
>> which I think should be the homepage. However it has no links to the
>> git tree of which I found two:
>>
>> git://ozlabs.org/srv/projects/dtc/dtc.git
>>
>> and
>>
>> git://www.jdl.com/software/dtc.git
>>
>> So, where is the official tree currently at, and can we get a link
>> to it
>> from the dtc.ozlabs.org page?
>
> I am the current maintainer. The most current version is
> the one on jdl.com, here:
>
> git://www.jdl.com/software/dtc.git
>
> I am delinquent in not reflecting that up to ozlabs yet.
>
> jdl
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Current DTC home
From: Jon Loeliger @ 2006-06-25 14:26 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1151240193.7929.10.camel@vader.jdub.homelinux.org>
So, like, the other day Josh Boyer mumbled:
> Hi,
>
> I found multiple pages/trees while I was looking around for where the
> most current homepage/release for the DTC was. So far, there's:
>
> http://dtc.ozlabs.org/
>
> which I think should be the homepage. However it has no links to the
> git tree of which I found two:
>
> git://ozlabs.org/srv/projects/dtc/dtc.git
>
> and
>
> git://www.jdl.com/software/dtc.git
>
> So, where is the official tree currently at, and can we get a link to it
> from the dtc.ozlabs.org page?
I am the current maintainer. The most current version is
the one on jdl.com, here:
git://www.jdl.com/software/dtc.git
I am delinquent in not reflecting that up to ozlabs yet.
jdl
^ permalink raw reply
* Re: Current DTC home
From: Josh Boyer @ 2006-06-25 13:10 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20060625170639.435819dd@localhost.localdomain>
On Sun, 2006-06-25 at 17:06 +0400, Vitaly Bordug wrote:
> =D0=9D=D0=B0 Sun, 25 Jun 2006 07:56:33 -0500
> Josh Boyer <jwboyer@jdub.homelinux.org> =D0=B7=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0=D0=BD=D0=BE:
>=20
> > So, where is the official tree currently at, and can we get a link to
> > it from the dtc.ozlabs.org page?
> >=20
> IIRC, Jon took over the dtc move-on, hence the most current seems the
> latter to me. Jon, correct me if I'm wrong.
Right, that is what I remember as well. I'm just looking to get some
kind of official page to point people at that has all the most recent
information.
josh
^ permalink raw reply
* Re: Current DTC home
From: Vitaly Bordug @ 2006-06-25 13:06 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1151240193.7929.10.camel@vader.jdub.homelinux.org>
На Sun, 25 Jun 2006 07:56:33 -0500
Josh Boyer <jwboyer@jdub.homelinux.org> записано:
> Hi,
>
> I found multiple pages/trees while I was looking around for where the
> most current homepage/release for the DTC was. So far, there's:
>
> http://dtc.ozlabs.org/
>
> which I think should be the homepage. However it has no links to the
> git tree of which I found two:
>
> git://ozlabs.org/srv/projects/dtc/dtc.git
>
> and
>
> git://www.jdl.com/software/dtc.git
>
> So, where is the official tree currently at, and can we get a link to
> it from the dtc.ozlabs.org page?
>
IIRC, Jon took over the dtc move-on, hence the most current seems the
latter to me. Jon, correct me if I'm wrong.
--
Sincerely, Vitaly
^ permalink raw reply
* Current DTC home
From: Josh Boyer @ 2006-06-25 12:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jdl
Hi,
I found multiple pages/trees while I was looking around for where the
most current homepage/release for the DTC was. So far, there's:
http://dtc.ozlabs.org/
which I think should be the homepage. However it has no links to the
git tree of which I found two:
git://ozlabs.org/srv/projects/dtc/dtc.git
and
git://www.jdl.com/software/dtc.git
So, where is the official tree currently at, and can we get a link to it
from the dtc.ozlabs.org page?
thx,
josh
^ permalink raw reply
* [PATCH] Remove extra local_bh_disable/enable from arch do_softirq
From: Paul Mackerras @ 2006-06-25 12:13 UTC (permalink / raw)
To: akpm, mingo, schwidefsky; +Cc: linuxppc-dev, linux-kernel
At the moment, powerpc and s390 have their own versions of do_softirq
which include local_bh_disable() and __local_bh_enable() calls. They
end up calling __do_softirq (in kernel/softirq.c) which also does
local_bh_disable/enable.
Apparently the two levels of disable/enable trigger a warning from
some validation code that Ingo is working on, and he would like to see
the outer level removed. But to do that, we have to move the
account_system_vtime calls that are currently in the arch do_softirq()
implementations for powerpc and s390 into the generic __do_softirq()
(this is a no-op for other archs because account_system_vtime is
defined to be an empty inline function on all other archs). This
patch does that.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
The s390 change here needs to be acked by the s390 folks, in case
there's a subtlety on s390 that I have missed.
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 40d4c14..2b52802 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -425,13 +425,8 @@ void do_softirq(void)
local_irq_save(flags);
- if (local_softirq_pending()) {
- account_system_vtime(current);
- local_bh_disable();
+ if (local_softirq_pending())
do_softirq_onstack();
- account_system_vtime(current);
- __local_bh_enable();
- }
local_irq_restore(flags);
}
diff --git a/arch/s390/kernel/irq.c b/arch/s390/kernel/irq.c
index 480b6a5..1eef509 100644
--- a/arch/s390/kernel/irq.c
+++ b/arch/s390/kernel/irq.c
@@ -69,10 +69,6 @@ asmlinkage void do_softirq(void)
local_irq_save(flags);
- account_system_vtime(current);
-
- local_bh_disable();
-
if (local_softirq_pending()) {
/* Get current stack pointer. */
asm volatile("la %0,0(15)" : "=a" (old));
@@ -95,10 +91,6 @@ asmlinkage void do_softirq(void)
__do_softirq();
}
- account_system_vtime(current);
-
- __local_bh_enable();
-
local_irq_restore(flags);
}
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 336f92d..20922c5 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -81,6 +81,7 @@ asmlinkage void __do_softirq(void)
pending = local_softirq_pending();
+ account_system_vtime(current);
local_bh_disable();
cpu = smp_processor_id();
restart:
@@ -109,6 +110,7 @@ restart:
if (pending)
wakeup_softirqd();
+ account_system_vtime(current);
__local_bh_enable();
}
^ permalink raw reply related
* Re: [PATCH] powerpc: kdump: Reserve the existing TCE mappings left by the first kernel
From: Olof Johansson @ 2006-06-24 23:23 UTC (permalink / raw)
To: Haren Myneni; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <449B8B9E.2050802@us.ibm.com>
On Thu, Jun 22, 2006 at 11:35:10PM -0700, Haren Myneni wrote:
> Paul, Olof,
>
> tce_union got removed in powerpc.git tree. Hence reposting the patch
> created against this tree. This patch is implemented based on Olof's
> suggestion of reserving TCE entries and use only available ones in the
> kdump boot and tested on P5, P4, JS20 and JS21 machines.
>
> If you are OK with this patch, please send it to upstream.
Looks good to me. Other platforms can add get_tce pointers later as
needed.
> sending to remote machine). Hence, this patch will make sure that
> minimum of 2048 entries will be available such that kdump boot could be
> successful in some cases.
Heh, I was pretty sure 10 was way too little. Good to see a number.
> Signed-off-by: Haren Myneni <haren@us.ibm.com>
Acked-by: Olof Johansson <olof@lixom.net>
-Olof
^ permalink raw reply
* Re: CPU 1 refused to die!
From: Giuliano Pochini @ 2006-06-24 20:18 UTC (permalink / raw)
To: Giuliano Pochini; +Cc: linuxppc-dev, ntl
In-Reply-To: <XFMail.20060525144619.pochini@shiny.it>
On Thu, 25 May 2006 14:46:19 +0200 (CEST)
Giuliano Pochini <pochini@shiny.it> wrote:
Problem solved with 2.6.17
--
Giuliano.
^ 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