* Re: [CFT] Don't use ASYNC_* nor SERIAL_IO_* with serial_core
From: Russell King @ 2006-02-05 0:01 UTC (permalink / raw)
To: Hirokazu Takata; +Cc: pfg, linux-mips, linux-kernel, linuxppc-dev
In-Reply-To: <20060202.231033.1059963967.takata.hirokazu@renesas.com>
On Thu, Feb 02, 2006 at 11:10:33PM +0900, Hirokazu Takata wrote:
> On m32r,
> compile and boot test: OK
Is that an Acked-by ?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [PATCH] powerpc: Fix PowerMac sound i2c
From: Benjamin Herrenschmidt @ 2006-02-04 22:56 UTC (permalink / raw)
To: Paul Collins; +Cc: Andrew Morton, linuxppc-dev list, linuxppc64-dev
In-Reply-To: <87y80rkmk7.fsf@briny.internal.ondioline.org>
On Sat, 2006-02-04 at 18:26 +0000, Paul Collins wrote:
> Hi Ben,
>
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > My patch reworking the PowerMac i2c code break the sound drivers as they
> > used to rely on some broken behaviour of i2c-keywest that is gone now.
> > This patch should fix them (tested on a g5 with alsa only). It might
> > also fix an oops if the alsa driver hits an unsupported chip.
>
> Applied Linus's current git tree, this patch makes ALSA sound on my
> PowerBook5,4 work again. The second patch does not work because the
> i2c wrapper (I assume that's what i2c_smbus_write_i2c_block_data is)
> has apparently not yet returned.
>
> It would be nice to have this fix in 2.6.16 if possible.
The second patch is the one that should go in, but it relies on an i2c
fix (undoing some Bunk damage) that is still staging in Greg tree... I
don't know what's up with that, I'll ask around.
Ben.
^ permalink raw reply
* [PATCH] Don't check pointer for NULL before passing it to kfree [arch/powerpc/kernel/rtas_flash.c]
From: Jesper Juhl @ 2006-02-04 19:35 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: linuxppc-dev
Checking a pointer for NULL before passing it to kfree is pointless, kfree
does its own NULL checking of input.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---
arch/powerpc/kernel/rtas_flash.c | 3 +--
1 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.16-rc2-git1-orig/arch/powerpc/kernel/rtas_flash.c 2006-01-03 04:21:10.000000000 +0100
+++ linux-2.6.16-rc2-git1/arch/powerpc/kernel/rtas_flash.c 2006-02-04 20:30:21.000000000 +0100
@@ -672,8 +672,7 @@ static void rtas_flash_firmware(int rebo
static void remove_flash_pde(struct proc_dir_entry *dp)
{
if (dp) {
- if (dp->data != NULL)
- kfree(dp->data);
+ kfree(dp->data);
dp->owner = NULL;
remove_proc_entry(dp->name, dp->parent);
}
^ permalink raw reply
* Re: [PATCH] powerpc: Fix PowerMac sound i2c
From: Paul Collins @ 2006-02-04 18:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <1136695956.30123.44.camel@localhost.localdomain>
Hi Ben,
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> My patch reworking the PowerMac i2c code break the sound drivers as they
> used to rely on some broken behaviour of i2c-keywest that is gone now.
> This patch should fix them (tested on a g5 with alsa only). It might
> also fix an oops if the alsa driver hits an unsupported chip.
Applied Linus's current git tree, this patch makes ALSA sound on my
PowerBook5,4 work again. The second patch does not work because the
i2c wrapper (I assume that's what i2c_smbus_write_i2c_block_data is)
has apparently not yet returned.
It would be nice to have this fix in 2.6.16 if possible.
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Index: linux-work/sound/ppc/tumbler.c
> ===================================================================
> --- linux-work.orig/sound/ppc/tumbler.c 2005-11-24 17:19:14.000000000 +1100
> +++ linux-work/sound/ppc/tumbler.c 2006-01-08 15:18:09.000000000 +1100
> @@ -137,6 +137,22 @@ static int send_init_client(pmac_keywest
> return 0;
> }
>
> +static int tumbler_write_block(struct i2c_client *client, u8 reg, int len,
> + u8 *values)
> +{
> + union i2c_smbus_data data;
> + int err;
> +
> + data.block[0] = len;
> + memcpy(&data.block[1], values, len);
> + err = i2c_smbus_xfer(client->adapter, client->addr, client->flags,
> + I2C_SMBUS_WRITE, reg, I2C_SMBUS_I2C_BLOCK_DATA,
> + &data);
> + return err;
> +}
> +
> +
> +
>
> static int tumbler_init_client(pmac_keywest_t *i2c)
> {
> @@ -239,8 +255,7 @@ static int tumbler_set_master_volume(pma
> block[4] = (right_vol >> 8) & 0xff;
> block[5] = (right_vol >> 0) & 0xff;
>
> - if (i2c_smbus_write_block_data(mix->i2c.client, TAS_REG_VOL,
> - 6, block) < 0) {
> + if (tumbler_write_block(mix->i2c.client, TAS_REG_VOL, 6, block) < 0) {
> snd_printk("failed to set volume \n");
> return -EINVAL;
> }
> @@ -340,8 +355,7 @@ static int tumbler_set_drc(pmac_tumbler_
> val[1] = 0;
> }
>
> - if (i2c_smbus_write_block_data(mix->i2c.client, TAS_REG_DRC,
> - 2, val) < 0) {
> + if (tumbler_write_block(mix->i2c.client, TAS_REG_DRC, 2, val) < 0) {
> snd_printk("failed to set DRC\n");
> return -EINVAL;
> }
> @@ -376,8 +390,7 @@ static int snapper_set_drc(pmac_tumbler_
> val[4] = 0x60;
> val[5] = 0xa0;
>
> - if (i2c_smbus_write_block_data(mix->i2c.client, TAS_REG_DRC,
> - 6, val) < 0) {
> + if (tumbler_write_block(mix->i2c.client, TAS_REG_DRC, 6, val) < 0) {
> snd_printk("failed to set DRC\n");
> return -EINVAL;
> }
> @@ -481,8 +494,8 @@ static int tumbler_set_mono_volume(pmac_
> vol = info->table[vol];
> for (i = 0; i < info->bytes; i++)
> block[i] = (vol >> ((info->bytes - i - 1) * 8)) & 0xff;
> - if (i2c_smbus_write_block_data(mix->i2c.client, info->reg,
> - info->bytes, block) < 0) {
> + if (tumbler_write_block(mix->i2c.client, info->reg,
> + info->bytes, block) < 0) {
> snd_printk("failed to set mono volume %d\n", info->index);
> return -EINVAL;
> }
> @@ -611,7 +624,7 @@ static int snapper_set_mix_vol1(pmac_tum
> for (j = 0; j < 3; j++)
> block[i * 3 + j] = (vol >> ((2 - j) * 8)) & 0xff;
> }
> - if (i2c_smbus_write_block_data(mix->i2c.client, reg, 9, block) < 0) {
> + if (tumbler_write_block(mix->i2c.client, reg, 9, block) < 0) {
> snd_printk("failed to set mono volume %d\n", reg);
> return -EINVAL;
> }
> Index: linux-work/sound/oss/dmasound/tas_common.h
> ===================================================================
> --- linux-work.orig/sound/oss/dmasound/tas_common.h 2005-11-24 17:19:14.000000000 +1100
> +++ linux-work/sound/oss/dmasound/tas_common.h 2006-01-08 15:33:29.000000000 +1100
> @@ -157,6 +157,21 @@ tas_mono_to_stereo(uint mono)
> return mono | (mono<<8);
> }
>
> +static int tas_write_block(struct i2c_client *client, u8 reg, int len, u8 *vals)
> +{
> + union i2c_smbus_data data;
> + int err;
> +
> + data.block[0] = len;
> + memcpy(&data.block[1], vals, len);
> + err = i2c_smbus_xfer(client->adapter, client->addr, client->flags,
> + I2C_SMBUS_WRITE, reg, I2C_SMBUS_I2C_BLOCK_DATA,
> + &data);
> + return err;
> +}
> +
> +
> +
> /*
> * Todo: make these functions a bit more efficient !
> */
> @@ -178,10 +193,8 @@ tas_write_register( struct tas_data_t *s
> if (write_mode & WRITE_SHADOW)
> memcpy(self->shadow[reg_num],data,reg_width);
> if (write_mode & WRITE_HW) {
> - rc=i2c_smbus_write_block_data(self->client,
> - reg_num,
> - reg_width,
> - data);
> + rc = tas_write_block(self->client, reg_num,
> + reg_width, data);
> if (rc < 0) {
> printk("tas: I2C block write failed \n");
> return rc;
> @@ -199,10 +212,8 @@ tas_sync_register( struct tas_data_t *se
>
> if (reg_width==0 || self==NULL)
> return -EINVAL;
> - rc=i2c_smbus_write_block_data(self->client,
> - reg_num,
> - reg_width,
> - self->shadow[reg_num]);
> + rc = tas_write_block(self->client, reg_num,
> + reg_width, self->shadow[reg_num]);
> if (rc < 0) {
> printk("tas: I2C block write failed \n");
> return rc;
> Index: linux-work/sound/ppc/pmac.c
> ===================================================================
> --- linux-work.orig/sound/ppc/pmac.c 2005-12-19 16:13:48.000000000 +1100
> +++ linux-work/sound/ppc/pmac.c 2006-01-08 15:37:10.000000000 +1100
> @@ -74,7 +74,7 @@ static int snd_pmac_dbdma_alloc(pmac_t *
>
> static void snd_pmac_dbdma_free(pmac_t *chip, pmac_dbdma_t *rec)
> {
> - if (rec) {
> + if (rec->space) {
> unsigned int rsize = sizeof(struct dbdma_cmd) * (rec->size + 1);
>
> dma_free_coherent(&chip->pdev->dev, rsize, rec->space, rec->dma_base);
> @@ -895,6 +895,7 @@ static int __init snd_pmac_detect(pmac_t
> chip->can_capture = 1;
> chip->num_freqs = ARRAY_SIZE(awacs_freqs);
> chip->freq_table = awacs_freqs;
> + chip->pdev = NULL;
>
> chip->control_mask = MASK_IEPC | MASK_IEE | 0x11; /* default */
>
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* [PATCH] fix compile warning in udbg_init_maple_realmode
From: Olaf Hering @ 2006-02-04 12:33 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
arch/powerpc/kernel/udbg_16550.c: In function `udbg_init_maple_realmode':
arch/powerpc/kernel/udbg_16550.c:162: warning: assignment from incompatible pointer type
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/udbg_16550.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.16-rc2-olh/arch/powerpc/kernel/udbg_16550.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/kernel/udbg_16550.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/kernel/udbg_16550.c
@@ -144,7 +144,7 @@ unsigned int udbg_probe_uart_speed(void
}
#ifdef CONFIG_PPC_MAPLE
-void udbg_maple_real_putc(unsigned char c)
+void udbg_maple_real_putc(char c)
{
if (udbg_comport) {
while ((real_readb(&udbg_comport->lsr) & LSR_THRE) == 0)
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* [PATCH] missing refcounting of of_find_node_by_name users
From: Olaf Hering @ 2006-02-04 12:20 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt, Paul Mackeras
In-Reply-To: <20060204115541.GB19392@suse.de>
drop the refcount of the node returned from of_find_node_by_name
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/platforms/powermac/feature.c | 5 +++++
arch/powerpc/platforms/powermac/pci.c | 1 +
arch/powerpc/platforms/powermac/pic.c | 1 +
arch/powerpc/platforms/powermac/smp.c | 1 +
arch/powerpc/platforms/pseries/eeh.c | 1 +
arch/powerpc/platforms/pseries/setup.c | 1 +
drivers/char/hvc_vio.c | 1 +
drivers/serial/pmac_zilog.c | 1 +
8 files changed, 12 insertions(+)
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/powermac/feature.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/feature.c
@@ -2772,6 +2772,7 @@ set_initial_features(void)
g5_gmac_enable(np, 0, 1);
np = of_find_node_by_name(np, "ethernet");
}
+ of_node_put(np);
/* Enable FW before PCI probe. Will be disabled later on
* Note: We should have a batter way to check that we are
@@ -2786,6 +2787,7 @@ set_initial_features(void)
}
np = of_find_node_by_name(np, "firewire");
}
+ of_node_put(np);
}
#else /* CONFIG_POWER4 */
@@ -2803,6 +2805,7 @@ set_initial_features(void)
core99_gmac_enable(np, 0, 1);
np = of_find_node_by_name(np, "ethernet");
}
+ of_node_put(np);
/* Enable FW before PCI probe. Will be disabled later on
* Note: We should have a batter way to check that we are
@@ -2821,6 +2824,7 @@ set_initial_features(void)
}
np = of_find_node_by_name(np, "firewire");
}
+ of_node_put(np);
/* Enable ATA-100 before PCI probe. */
np = of_find_node_by_name(NULL, "ata-6");
@@ -2832,6 +2836,7 @@ set_initial_features(void)
}
np = of_find_node_by_name(np, "ata-6");
}
+ of_node_put(np);
/* Switch airport off */
np = find_devices("radio");
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pci.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/powermac/pci.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pci.c
@@ -695,6 +695,7 @@ static void __init fixup_nec_usb2(void)
nec->intrs[0].line);
}
}
+ of_put_node(nec);
}
static void __init setup_bandit(struct pci_controller *hose,
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pic.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/powermac/pic.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/pic.c
@@ -658,6 +658,7 @@ static int pmacpic_find_viaint(void)
if (np == NULL)
goto not_found;
viaint = np->intrs[0].line;
+ of_node_put(np);
#endif /* CONFIG_ADB_PMU */
not_found:
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/smp.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/powermac/smp.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/powermac/smp.c
@@ -588,6 +588,7 @@ static void __init smp_core99_setup_i2c_
if (pmac_tb_freeze != NULL)
break;
}
+ of_node_put(cc);
if (pmac_tb_freeze != NULL) {
/* Open i2c bus for synchronous access */
if (pmac_i2c_open(pmac_tb_clock_chip_host, 1)) {
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/pseries/eeh.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/pseries/eeh.c
@@ -846,6 +846,7 @@ void __init eeh_init(void)
info.buid_hi = BUID_HI(buid);
traverse_pci_devices(phb, early_enable_eeh, &info);
}
+ of_node_put(phb);
if (eeh_subsystem_enabled)
printk(KERN_INFO "EEH: PCI Enhanced I/O Error Handling Enabled\n");
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/pseries/setup.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/pseries/setup.c
@@ -330,6 +330,7 @@ static void __init pSeries_discover_pic
break;
}
}
+ of_node_put(np);
if (ppc64_interrupt_controller == IC_INVALID)
printk("pSeries_discover_pic: failed to recognize"
" interrupt-controller\n");
Index: linux-2.6.16-rc2-olh/drivers/char/hvc_vio.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/drivers/char/hvc_vio.c
+++ linux-2.6.16-rc2-olh/drivers/char/hvc_vio.c
@@ -146,6 +146,7 @@ static int hvc_find_vtys(void)
++num_found;
}
}
+ of_node_put(vty);
return num_found;
}
Index: linux-2.6.16-rc2-olh/drivers/serial/pmac_zilog.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/drivers/serial/pmac_zilog.c
+++ linux-2.6.16-rc2-olh/drivers/serial/pmac_zilog.c
@@ -1767,6 +1767,7 @@ static int __init pmz_probe(void)
next:
node_p = of_find_node_by_name(node_p, "escc");
}
+ of_node_put(node_p);
pmz_ports_count = count;
return 0;
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* [PATCH] add refcounting to setup_peg2 and of_get_pci_address
From: Olaf Hering @ 2006-02-04 11:55 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt, Paul Mackeras
In-Reply-To: <20060118151840.GA24381@suse.de>
setup_peg2 must do some refcounting.
of_get_pci_address may need to drop the node
Pegasos l2cr : L2 cache was not active, activating
PCI bus 0 controlled by pci at 80000000
Badness in kref_get at /home/olaf/kernel/olh/ppc64/linux-2.6.16-rc2-olh/lib/kref.c:32
Call Trace:
[C037BD00] [C0007934] show_stack+0x5c/0x184 (unreliable)
[C037BD30] [C000E068] program_check_exception+0x184/0x584
[C037BD90] [C000F5F0] ret_from_except_full+0x0/0x4c
--- Exception: 700 at kref_get+0xc/0x24
LR = of_node_get+0x24/0x3c
[C037BE50] [C004FD94] __pte_alloc_kernel+0x64/0x80 (unreliable)
[C037BE70] [C000CA18] of_get_parent+0x34/0x58
[C037BE90] [C0009B18] of_get_address+0x24/0x174
[C037BED0] [C000A108] of_address_to_resource+0x24/0x68
[C037BF00] [C038B128] chrp_find_bridges+0x114/0x470
[C037BF90] [C038AE48] chrp_setup_arch+0x1fc/0x32c
[C037BFB0] [C03849B0] setup_arch+0x144/0x188
[C037BFD0] [C037C45C] start_kernel+0x34/0x1a8
[C037BFF0] [000037A0] 0x37a0
Badness in kref_get at /home/olaf/kernel/olh/ppc64/linux-2.6.16-rc2-olh/lib/kref.c:32
Call Trace:
[C037BC90] [C0007934] show_stack+0x5c/0x184 (unreliable)
[C037BCC0] [C000E068] program_check_exception+0x184/0x584
[C037BD20] [C000F5F0] ret_from_except_full+0x0/0x4c
--- Exception: 700 at kref_get+0xc/0x24
LR = of_node_get+0x24/0x3c
[C037BDE0] [00000000] 0x0 (unreliable)
[C037BE00] [C000CA18] of_get_parent+0x34/0x58
[C037BE20] [C0009CE8] of_translate_address+0x2c/0x2fc
[C037BEA0] [C0009FE8] __of_address_to_resource+0x30/0xc4
[C037BED0] [C000A130] of_address_to_resource+0x4c/0x68
[C037BF00] [C038B128] chrp_find_bridges+0x114/0x470
[C037BF90] [C038AE48] chrp_setup_arch+0x1fc/0x32c
[C037BFB0] [C03849B0] setup_arch+0x144/0x188
[C037BFD0] [C037C45C] start_kernel+0x34/0x1a8
[C037BFF0] [000037A0] 0x37a0
PCI bus 0 controlled by pci at c0000000
Top of RAM: 0x10000000, Total RAM: 0x10000000
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/prom_parse.c | 4 +++-
arch/powerpc/platforms/chrp/pci.c | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.16-rc2-olh/arch/powerpc/kernel/prom_parse.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/kernel/prom_parse.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/kernel/prom_parse.c
@@ -465,8 +465,10 @@ u32 *of_get_pci_address(struct device_no
if (parent == NULL)
return NULL;
bus = of_match_bus(parent);
- if (strcmp(bus->name, "pci"))
+ if (strcmp(bus->name, "pci")) {
+ of_node_put(parent);
return NULL;
+ }
bus->count_cells(dev, &na, &ns);
of_node_put(parent);
if (!OF_CHECK_COUNTS(na, ns))
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/pci.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/chrp/pci.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/pci.c
@@ -204,9 +204,11 @@ static void __init setup_peg2(struct pci
struct device_node *root = find_path_device("/");
struct device_node *rtas;
+ of_node_get(root);
rtas = of_find_node_by_name (root, "rtas");
if (rtas) {
hose->ops = &rtas_pci_ops;
+ of_node_put(rtas);
} else {
printk ("RTAS supporting Pegasos OF not found, please upgrade"
" your firmware\n");
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* [PATCH] remove pointer/integer confusion in of_find_node_by_name
From: Olaf Hering @ 2006-02-04 11:44 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
In-Reply-To: <20060204093456.GA15051@suse.de>
remove pointer/integer confusion
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/prom.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.16-rc2-olh/arch/powerpc/kernel/prom.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/kernel/prom.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/kernel/prom.c
@@ -1398,8 +1398,8 @@ struct device_node *of_find_node_by_name
read_lock(&devtree_lock);
np = from ? from->allnext : allnodes;
- for (; np != 0; np = np->allnext)
- if (np->name != 0 && strcasecmp(np->name, name) == 0
+ for (; np != NULL; np = np->allnext)
+ if (np->name != NULL && strcasecmp(np->name, name) == 0
&& of_node_get(np))
break;
if (from)
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: MPC5200, PCI, udelay(10)
From: Sylvain Munaut @ 2006-02-04 10:51 UTC (permalink / raw)
To: roman.kuzmenko; +Cc: Linuxppc-embedded
In-Reply-To: <1137745904.4631.17.camel@trust.auriga.ru>
Roman Kuzmenko wrote:
> Hello.
>
> Please, help me to investigate why the delays present in the
> "mpc5xxx_read_config_dword" and "mpc5xxx_write_config_dword" functions
> in the "arch/ppc/kernel/mpc52xx_pci.c" file.
>
> I.e.
> ==========================
> *(volatile u32 *)MPC5xxx_PCI_CAR = 0;
>
>>udelay(10);
>
> return 0;
> ==========================
>
> I was neither able to find any reference at the MPC5200 documentation
> supplied by FreeScale nor reproduce any error with these lines got
> removed.
I wasn't able to reproduce any problem either but people kept reporting
problems. But it seems that it's not a delay that's needed but a mb() to
ensure the write all _completly_ done before the next write. A
udelay(10) almost ensure that also but is a lot less elegant imho.
Sylvain
^ permalink raw reply
* [PATCH] restore clock speed in /proc/cpuinfo
From: Olaf Hering @ 2006-02-04 10:05 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
Use generic_calibrate_decr to restore missing clock: speed in /proc/cpuinfo
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/platforms/chrp/chrp.h | 1 -
arch/powerpc/platforms/chrp/setup.c | 2 +-
arch/powerpc/platforms/chrp/time.c | 21 ---------------------
3 files changed, 1 insertion(+), 23 deletions(-)
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/setup.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/chrp/setup.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/setup.c
@@ -506,7 +506,7 @@ void __init chrp_init(void)
ppc_md.halt = rtas_halt;
ppc_md.time_init = chrp_time_init;
- ppc_md.calibrate_decr = chrp_calibrate_decr;
+ ppc_md.calibrate_decr = generic_calibrate_decr;
/* this may get overridden with rtas routines later... */
ppc_md.set_rtc_time = chrp_set_rtc_time;
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/time.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/chrp/time.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/time.c
@@ -167,24 +167,3 @@ void chrp_get_rtc_time(struct rtc_time *
tm->tm_mon = mon;
tm->tm_year = year;
}
-
-
-void __init chrp_calibrate_decr(void)
-{
- struct device_node *cpu;
- unsigned int freq, *fp;
-
- /*
- * The cpu node should have a timebase-frequency property
- * to tell us the rate at which the decrementer counts.
- */
- freq = 16666000; /* hardcoded default */
- cpu = find_type_devices("cpu");
- if (cpu != 0) {
- fp = (unsigned int *)
- get_property(cpu, "timebase-frequency", NULL);
- if (fp != 0)
- freq = *fp;
- }
- ppc_tb_freq = freq;
-}
Index: linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/chrp.h
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/platforms/chrp/chrp.h
+++ linux-2.6.16-rc2-olh/arch/powerpc/platforms/chrp/chrp.h
@@ -5,7 +5,6 @@
extern void chrp_nvram_init(void);
extern void chrp_get_rtc_time(struct rtc_time *);
extern int chrp_set_rtc_time(struct rtc_time *);
-extern void chrp_calibrate_decr(void);
extern long chrp_time_init(void);
extern void chrp_find_bridges(void);
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* [PATCH] remove pointer/integer confusion in generic_calibrate_decr
From: Olaf Hering @ 2006-02-04 9:34 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
remove pointer/integer confusion
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/time.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.16-rc2-olh/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/kernel/time.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/kernel/time.c
@@ -612,10 +612,10 @@ void __init generic_calibrate_decr(void)
ppc_tb_freq = DEFAULT_TB_FREQ; /* hardcoded default */
node_found = 0;
- if (cpu != 0) {
+ if (cpu) {
fp = (unsigned int *)get_property(cpu, "timebase-frequency",
NULL);
- if (fp != 0) {
+ if (fp) {
node_found = 1;
ppc_tb_freq = *fp;
}
@@ -626,10 +626,10 @@ void __init generic_calibrate_decr(void)
ppc_proc_freq = DEFAULT_PROC_FREQ;
node_found = 0;
- if (cpu != 0) {
+ if (cpu) {
fp = (unsigned int *)get_property(cpu, "clock-frequency",
NULL);
- if (fp != 0) {
+ if (fp) {
node_found = 1;
ppc_proc_freq = *fp;
}
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* RE: Gdb with MPC85xx
From: atul.sabharwal @ 2006-02-03 21:28 UTC (permalink / raw)
To: dan, jcampos; +Cc: linuxppc-embedded
Thanks Dan. It helps clarify some debug problems. I was having similar
problem with BDI2000 to program the AM29F flash part on a 885 reference
board. Finally gave up. It's probably not supported or the config file
was
wrong. My actual board uses different flash, so BDI & the board work
well.
There is a bug in ddd (at least debugging u-boot) when code relocates
from flash to RAM (in_ram routine). The command add-symbol-file u-boot
<text address> to reload symbols did not work due to some ddd bug (it
could not find bounds of current function). Switched to manual decode
using BDI
peek/poke and objdump.
--
Atul
^ permalink raw reply
* Re: Gdb with MPC85xx
From: Dan Malek @ 2006-02-03 21:05 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201AC366C@us-bv-m23.global.tektronix.net>
On Feb 3, 2006, at 3:46 PM, <atul.sabharwal@exgate.tek.com> wrote:
> To the best of my knowledge, I had could single step but not run to a
> breakpoint in the initial u-boot code on PPC8540( an E500 core based)
This is a problem with many processors and has been discussed
at length too often. The quick response is that various initialization
code in both boot roms and Linux will disable/reset or otherwise
mess up debug registers the BDI has configured for it's use. So,
it isn't the fault of the BDI2000, you may have to temporarily disable
or modify the code under test in such a way to not do this. There are
several tricky places to debug code, that are completely inaccessible
without the use of the BDI2000, but that also require some common
sense and minor environment changes to properly debug. The e500
core (and Book-E in general) significantly complicated the ability
to debug in some modes of development, so you are most
likely to see problems with these processors than others.
Thanks.
-- Dan
^ permalink raw reply
* RE: Gdb with MPC85xx
From: atul.sabharwal @ 2006-02-03 20:46 UTC (permalink / raw)
To: fabidi, linuxppc-embedded
To the best of my knowledge, I had could single step but not run to a
breakpoint in the initial u-boot code on PPC8540( an E500 core based)
system
Esp. in the code in start.S. I had a problem where the flash was busted
and
The start.S was running from a DDR2 memory at 600+MHz rate. So, I had
to lock the TLB and define LAW for the DDR memory in BDI so that we
could run entire u-boot, kernel, ramdisk from RAM. =20
It seemed like a BDI bug to me unless the processor is designed to
always boot from a slow deviceflash or eeprom) till the initialization
sequence is=20
Completed. Did not try extensive debug with it, so not sure. If it
helps.
--
Atul
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Fahd Abidi
Sent: Friday, February 03, 2006 10:41 AM
To: linuxppc-embedded@ozlabs.org
Subject: Gdb with MPC85xx
Hello,
I am wondering if someone here is using GDB to debug code on an 85xx
platform with the BDI. I have been running into several issues with GDB
5.x and 6.x where the E500 core does not seem to either step properly to
the next line of code in the kernel or uboot or gets lost altogether.
Each version of GDB seems to have its own set of bugs. If someone has
been using a version of GDB that works pretty well then let me know what
version it is and I can try and download it and build it and see if it
behaves better.
This is probably more of a tools question then a Linux question, I'm
hoping I can get an answer anyway.
Thanks,
Fahd
=20
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Gdb with MPC85xx
From: Kumar Gala @ 2006-02-03 18:40 UTC (permalink / raw)
To: Fahd Abidi; +Cc: linuxppc-embedded
In-Reply-To: <81C69D96BDD30640952C7A404004AA2501954E@ultsol01.tewks.ultsol.local>
On Fri, 3 Feb 2006, Fahd Abidi wrote:
> Hello,
>
> I am wondering if someone here is using GDB to debug code on an 85xx
> platform with the BDI. I have been running into several issues with GDB
> 5.x and 6.x where the E500 core does not seem to either step properly to
> the next line of code in the kernel or uboot or gets lost altogether.
> Each version of GDB seems to have its own set of bugs. If someone has
> been using a version of GDB that works pretty well then let me know what
> version it is and I can try and download it and build it and see if it
> behaves better.
Are you able to get the registers in GDB properly? The e500 introduces a
different GDB register protocol than standard PPC. This either requires
the latest GDB and possibly BDI firmware. I forget how BDI handles the
different protocol layouts. I'm pretty sure they added support for "full
e500 GDB" recently.
You also, have to build u-boot and your kernel to handle the quicky debug
support on 85xx.
- kumar
^ permalink raw reply
* Gdb with MPC85xx
From: Fahd Abidi @ 2006-02-03 18:41 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am wondering if someone here is using GDB to debug code on an 85xx
platform with the BDI. I have been running into several issues with GDB
5.x and 6.x where the E500 core does not seem to either step properly to
the next line of code in the kernel or uboot or gets lost altogether.
Each version of GDB seems to have its own set of bugs. If someone has
been using a version of GDB that works pretty well then let me know what
version it is and I can try and download it and build it and see if it
behaves better.
This is probably more of a tools question then a Linux question, I'm
hoping I can get an answer anyway.
Thanks,
Fahd
=20
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Alex BASTOS @ 2006-02-03 15:53 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200602031346.52937.laurent.pinchart@tbox.biz>
All of them were labelled as USB 2.0, and where also recognized as
USB 2.0 devices in other systems, as x86 workstation with Fedora Core
Best regards
Alex
> > I don't know if it could be of interest for you.
> > I experienced same problem, but only with a subset of the USB storage
> > devices I have tested. There are same which worked fine.
>
> I tried with two USB Mass Storage devices. Both fail but at different stages.
> Do you know if the devices you were able to access were USB 1.1 or USB 2.0
> devices ?
>
> Laurent Pinchart
>
^ permalink raw reply
* AW: How to cross-build OpenSSL shared library
From: Marc.Bodmer @ 2006-02-03 13:59 UTC (permalink / raw)
To: linuxppc-embedded
Thanks Wolfgang, I will check it.
I guess I will need to "spy" there for many other packages.
kind regards
Marc
-----Urspr=FCngliche Nachricht-----
Von: wd@denx.de [mailto:wd@denx.de]
Gesendet: Freitag, 3. Februar 2006 14:44
An: Bodmer Marc, Securiton, ESS
Cc: linuxppc-embedded@ozlabs.org
Betreff: Re: How to cross-build OpenSSL shared library=0D
In message=
<5DDC68DD3569BB4D92D660326A9C095301728952@stnzolex1.securiton.int> you=
wrote:
>=0D
> I am using ELDK (3.1.1) and there is a built OpenSSL as shared library
> available.
> Does anybody know about how they managed to build this shared library?
The DULG describes in detail how to rebuild all ELDK RPMs from the
sources. Just download and install the Source RPM and check the
commands in the spec file.
Best regards,
Wolfgang Denk
--=0D
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Perl already has an IDE. It's called Unix.
-- Tom Christiansen in 375bd509@cs.colorado.edu
<html>
<body>
<font face =3D "arial" size =3D "1">
---------------------------------------------------------------------------=
------------------------------
This e-mail is confidential and may contain privileged information.
It is intended only for the addressees. If you have received this
e-mail in error, kindly notify us immediately by telephone or e-mail
and delete the message from your system.
---------------------------------------------------------------------------=
------------------------------
</font>
</body>
</html>
^ permalink raw reply
* Re: How to cross-build OpenSSL shared library
From: Wolfgang Denk @ 2006-02-03 13:43 UTC (permalink / raw)
To: Marc.Bodmer; +Cc: linuxppc-embedded
In-Reply-To: <5DDC68DD3569BB4D92D660326A9C095301728952@stnzolex1.securiton.int>
In message <5DDC68DD3569BB4D92D660326A9C095301728952@stnzolex1.securiton.int> you wrote:
>
> I am using ELDK (3.1.1) and there is a built OpenSSL as shared library
> available.
> Does anybody know about how they managed to build this shared library?
The DULG describes in detail how to rebuild all ELDK RPMs from the
sources. Just download and install the Source RPM and check the
commands in the spec file.
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
Perl already has an IDE. It's called Unix.
-- Tom Christiansen in 375bd509@cs.colorado.edu
^ permalink raw reply
* AW: How to cross-build OpenSSL shared library
From: Marc.Bodmer @ 2006-02-03 12:56 UTC (permalink / raw)
To: guilherme.mazzela, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3064 bytes --]
Hi, thanks for your answer.
Thats almost what I actually did. Here is my ./Configure call:
./Configure linux-ppc shared zlib-dynamic compiler:${CROSS_COMPILE}gcc --openssldir=$openssl_distdir --prefix=$openssl_bindir
I've tried what you proposed here and it works :-)
I made the mistake to give the compiler to the Configure script instead just at make time...
I did not use the "no-asm" option. Is this needed for PPC or is there mpc8xx asm available?
regards
Marc
-----Ursprüngliche Nachricht-----
Von: Guilherme Mazzela [mailto:guilherme.mazzela@asga.com.br]
Gesendet: Freitag, 3. Februar 2006 12:19
An: Bodmer Marc, Securiton, ESS
Betreff: RE: How to cross-build OpenSSL shared library
try this
./Configure
./Configure linux-ppc --prefix=/usr --openssldir=/etc shared no-asm
make clean
make CC=ppc-linux-gcc
after that you have to strip the libcrypto.so.X.X.X
-----Original Message-----
From: Marc.Bodmer@securiton.ch [ mailto:Marc.Bodmer@securiton.ch]
Sent: Fri 2/3/2006 7:45 AM
To: linuxppc-embedded@ozlabs.org
Cc:
Subject: How to cross-build OpenSSL shared library
Hello
I have a problem with cross compiling the OpenSSL library for PPC (mpc885) as a
shared library (Host x86, Linux).
I give the option "shared" to the "Configure" script delivered with OpenSSL. But it
always only builds me static libraries. After Configuration it shows me the text:
>You gave the option 'shared'. Normally, that would give you shared libraries.
>Unfortunately, the OpenSSL configuration doesn't include shared library support
>for this platform yet, so it will pretend you gave the option 'no-shared'
I am using ELDK (3.1.1) and there is a built OpenSSL as shared library
available.
Does anybody know about how they managed to build this shared library?
Thanks for any help
Marc
<html>
<body>
<font face = "arial" size = "1">
---------------------------------------------------------------------------------------------------------
This e-mail is confidential and may contain privileged information.
It is intended only for the addressees. If you have received this
e-mail in error, kindly notify us immediately by telephone or e-mail
and delete the message from your system.
---------------------------------------------------------------------------------------------------------
</font>
</body>
</html>
<html>
<body>
<font face = "arial" size = "1">
---------------------------------------------------------------------------------------------------------
This e-mail is confidential and may contain privileged information.
It is intended only for the addressees. If you have received this
e-mail in error, kindly notify us immediately by telephone or e-mail
and delete the message from your system.
---------------------------------------------------------------------------------------------------------
</font>
</body>
</html>
[-- Attachment #2: Type: text/html, Size: 5639 bytes --]
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Laurent Pinchart @ 2006-02-03 12:46 UTC (permalink / raw)
To: Alexandre BASTOS; +Cc: linuxppc-embedded
In-Reply-To: <1138972275.43e356730f889@webmail.televes.com:443>
> I don't know if it could be of interest for you.
> I experienced same problem, but only with a subset of the USB storage
> devices I have tested. There are same which worked fine.
I tried with two USB Mass Storage devices. Both fail but at different stages.
Do you know if the devices you were able to access were USB 1.1 or USB 2.0
devices ?
Laurent Pinchart
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Alexandre BASTOS @ 2006-02-03 13:11 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200602031234.58813.laurent.pinchart@tbox.biz>
I don't know if it could be of interest for you.
I experienced same problem, but only with a subset of the USB storage
devices I have tested. There are same which worked fine.
Best regards,
Alex
> Hi,
>
> after more testing, I found out that only the first 3 control URBs complete
> successfully. I tried to duplicate the first GET_DESCRIPTOR(CONFIG) request,
> and the second one which worked before now fails. If I unplug/replug the
> device, the first GET_DESCRIPTOR(DEVICE) request sent to device 0 from
> hub_port_init fails:
>
> c0450260 133702068 S Ci:000:00 s 80 06 0100 0000 0040 64 <
> c0450260 134700018 C Ci:000:00 -104 0
> c0450260 134700053 S Ci:000:00 s 80 06 0100 0000 0040 64 <
> c0450260 135700016 C Ci:000:00 -104 0
> c0450260 135700049 S Ci:000:00 s 80 06 0100 0000 0040 64 <
> c0450260 136700018 C Ci:000:00 -104 0
>
> Hope this helps to diagnose the problem,
>
> Laurent Pinchart
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: CPM2 USB driver & MPC8248
From: Laurent Pinchart @ 2006-02-03 11:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200602031210.12603.laurent.pinchart@tbox.biz>
Hi,
after more testing, I found out that only the first 3 control URBs complete
successfully. I tried to duplicate the first GET_DESCRIPTOR(CONFIG) request,
and the second one which worked before now fails. If I unplug/replug the
device, the first GET_DESCRIPTOR(DEVICE) request sent to device 0 from
hub_port_init fails:
c0450260 133702068 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c0450260 134700018 C Ci:000:00 -104 0
c0450260 134700053 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c0450260 135700016 C Ci:000:00 -104 0
c0450260 135700049 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c0450260 136700018 C Ci:000:00 -104 0
Hope this helps to diagnose the problem,
Laurent Pinchart
^ permalink raw reply
* CPM2 USB driver & MPC8248
From: Laurent Pinchart @ 2006-02-03 11:10 UTC (permalink / raw)
To: mike; +Cc: linuxppc-embedded
Hi Mike,
I'm having trouble using your CPM2 USB host controller driver on an Embedded
Planet EP8248 board with Linux 2.6.15.
The driver didn't compiler with 2.6.15 but the required changes were minor
(the root hub doesn't have to be registered by the host controller driver
anymore, and a few functions have been renamed). I modified the board setup
function according to my hardware (different BCSR registers) and the driver
loads properly.
When I connect a USB 2.0 Mass Storage device, initialization fails when trying
to fetch the string descriptors. Here's what USBMon produces (I decoded the
USB transactions with the device).
/* Initialization */
c054a860 62948014 C Ii:001:01 0 1 D
c054a860 62948089 S Ii:001:01 -115 2 D
c04500e0 62948126 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 62948134 C Ci:001:00 0 4 = 01010100
c04500e0 62948146 S Co:001:00 s 23 01 0010 0001 0000 0
c04500e0 62948151 C Co:001:00 0 0
c04500e0 62948158 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 62948163 C Ci:001:00 0 4 = 01010000
c04500e0 62980027 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 62980045 C Ci:001:00 0 4 = 01010000
c04500e0 63012025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63012042 C Ci:001:00 0 4 = 01010000
c04500e0 63044025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63044042 C Ci:001:00 0 4 = 01010000
c04500e0 63076025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63076043 C Ci:001:00 0 4 = 01010000
c04500e0 63076088 S Co:001:00 s 23 03 0004 0001 0000 0
c04500e0 63172013 C Co:001:00 0 0
c04500e0 63228024 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63228042 C Ci:001:00 0 4 = 03010000
c04500e0 63284035 S Co:001:00 s 23 01 0014 0001 0000 0
c04500e0 63284052 C Co:001:00 0 0
c04500e0 63456779 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c04500e0 63457301 C Ci:000:00 0 18 = 12010002 00000040 81075051 20000102 0301
c04500e0 63457338 S Co:001:00 s 23 03 0004 0001 0000 0
c04500e0 63552013 C Co:001:00 0 0
c04500e0 63608025 S Ci:001:00 s a3 00 0000 0001 0004 4 <
c04500e0 63608043 C Ci:001:00 0 4 = 03010000
c04500e0 63664025 S Co:001:00 s 23 01 0014 0001 0000 0
c04500e0 63664042 C Co:001:00 0 0
c04500e0 63664055 S Co:000:00 s 00 05 0002 0000 0000 0
c04500e0 63664590 C Co:000:00 0 0
/* GET_DESCRIPTOR DEVICE 0x12 bytes */
c04500e0 63680039 S Ci:002:00 s 80 06 0100 0000 0012 18 <
c04500e0 63680781 C Ci:002:00 0 18 = 12010002 00000040 81075051 20000102 0301
/* GET_DESCRIPTOR CONFIGURATION 0x09 bytes */
c04500e0 63680825 S Ci:002:00 s 80 06 0200 0000 0009 9 <
c04500e0 63681795 C Ci:002:00 0 9 = 09022000 01010080 32
/* GET_DESCRIPTOR CONFIGURATION 0x20 bytes */
c04500e0 63681832 S Ci:002:00 s 80 06 0200 0000 0020 32 <
c04500e0 63682820 C Ci:002:00 0 32 = 09022000 01010080 32090400 00020806
50000705 81024000 00070501 02400000
/* GET_DESCRIPTOR STRING 0xff bytes */
c0450140 63682877 S Ci:002:00 s 80 06 0300 0000 00ff 255 <
c0450140 68680032 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0x02 bytes */
c0450140 68680075 S Ci:002:00 s 80 06 0300 0000 0002 2 <
c0450140 73680032 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0xff bytes */
c0450140 73725213 S Ci:002:00 s 80 06 0300 0000 00ff 255 <
c0450140 78724036 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0x02 bytes */
c0450140 78724141 S Ci:002:00 s 80 06 0300 0000 0002 2 <
c0450140 83724019 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0xff bytes */
c0450140 83769592 S Ci:002:00 s 80 06 0300 0000 00ff 255 <
c0450140 88768017 C Ci:002:00 -104 0
/* GET_DESCRIPTOR STRING 0x02 bytes */
c0450140 88768053 S Ci:002:00 s 80 06 0300 0000 0002 2 <
c0450140 93768016 C Ci:002:00 -104 0
/* SET_CONFIGURATION 1 */
c0450140 93814145 S Co:002:00 s 00 09 0001 0000 0000 0
c0450140 98812017 C Co:002:00 -104 0
As you can see, the devices sends its device and configuration descriptors,
but something goes wrong with the string descriptors. I modified the core USB
code to request 0x40 bytes (which is the value of bMaxPacketSize0) or even
0x20 bytes, but the same problem occurs (same USBMon traces with 0xff
replaced by 0x40).
Could you help me ? Kernel coding is not a problem, so I can make experiments
if you point me to some direction. I'm also quite familiar with the USB specs
down to the various types of transfers (control, interrupt, bulk and
isochronous) but not with the lower-level protocol (frames, tokens, ...). I
can learn if needed.
Laurent Pinchart
^ permalink raw reply
* How to cross-build OpenSSL shared library
From: Marc.Bodmer @ 2006-02-03 9:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]
Hello
I have a problem with cross compiling the OpenSSL library for PPC (mpc885) as a
shared library (Host x86, Linux).
I give the option "shared" to the "Configure" script delivered with OpenSSL. But it
always only builds me static libraries. After Configuration it shows me the text:
>You gave the option 'shared'. Normally, that would give you shared libraries.
>Unfortunately, the OpenSSL configuration doesn't include shared library support
>for this platform yet, so it will pretend you gave the option 'no-shared'
I am using ELDK (3.1.1) and there is a built OpenSSL as shared library
available.
Does anybody know about how they managed to build this shared library?
Thanks for any help
Marc
<html>
<body>
<font face = "arial" size = "1">
---------------------------------------------------------------------------------------------------------
This e-mail is confidential and may contain privileged information.
It is intended only for the addressees. If you have received this
e-mail in error, kindly notify us immediately by telephone or e-mail
and delete the message from your system.
---------------------------------------------------------------------------------------------------------
</font>
</body>
</html>
[-- Attachment #2: Type: text/html, Size: 5156 bytes --]
^ 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