* Problems compiling Linux for MPC8272ADS
From: Manil Gaouar @ 2007-09-24 16:26 UTC (permalink / raw)
To: linuxppc-dev
Hi there,
I am trying to compile the latest Linux from the git repos: git clone
git://www.denx.de/git/linux-2.6-denx.git linux-2.6-denx, I checked out
the code a few weeks ago and was able to build my uImage no problems. I
did a git pull this morning and I can not compile anymore, here is the
error message I have:
BOOTCC arch/powerpc/boot/ps3.o
BOOTCC arch/powerpc/boot/treeboot-bamboo.o
BOOTCC arch/powerpc/boot/cuboot-sequoia.o
BOOTCC arch/powerpc/boot/treeboot-walnut.o
{standard input}: Assembler messages:
{standard input}:184: Error: Unrecognized opcode: `mfdcr'
{standard input}:185: Error: Unrecognized opcode: `mfdcr'
{standard input}:186: Error: Unrecognized opcode: `mfdcr'
{standard input}:217: Error: Unrecognized opcode: `mtdcr'
make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
make: *** [uImage] Error 2
here are the commands I am using:
make mrproper
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- mpc8272_ads_defconfig
make ARCH=3Dpowerpc CROSS_COMPILE=3Dppc_6xx- uImage
Do you have any ideas, or I should check out the 2.6.22 stable release
instead and try again???
Thx
^ permalink raw reply
* Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
From: Scott Wood @ 2007-09-24 15:57 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <46F6C9DC.90008@scram.de>
Jochen Friedrich wrote:
>
> In cpm_uart_core, functions cpm_uart_init_bd and cpm_uart_init_scc
> an offset into DP RAM is calculated by substracting a physical
> memory constant from an virtual address. This patch fixes the
> problem by converting the virtual address into a physical
> first.
Huh? DPRAM_BASE is a virtual address. With this patch, you'd be
subtracting a virtual address from a physical address.
-Scott
^ permalink raw reply
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
From: Scott Wood @ 2007-09-24 14:52 UTC (permalink / raw)
To: Peter Korsgaard, Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <20070924050709.GM8058@localhost.localdomain>
David Gibson wrote:
>> i2c@3100 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> device_type = "i2c";
>
> Hrm... we probably want an "i2c" device_type class, but I don't think
> we've actually defined one, which is a problem
Right... but we need to get the kernel to stop expecting the device type
to be there before we yell at people for including it. :-)
> The fact that NVRAM+RTC chips are so common is a bit of an issue from
> the point of view of defining a device class binding - a device can't
> have type "rtc" and "nvram".
This is one of the reasons that I'd prefer to use compatible for such
things.
-Scott
^ permalink raw reply
* Cypress C67x00 driver connects ?
From: Robertson, Joseph M. @ 2007-09-24 14:29 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1933 bytes --]
Hi,
Can I connect the c67x00 driver directly to the USB bus?
I have a device, a virtex4 fpga, with no PCI bus. I have a fpga bus to the cypress chip (c67300).
I have compiled the core USB code (but no uhci ohci).
It loads ok, detects and loads 2 host sies. I get interrupts for all that (and the 3 mailbox puts I do).
But I was just connecting to 'platfom_bus_type'. After all that I get no more interrupts.
The kernel drivers textbook doesn't quite match anymore, links to .hotplug in structs have moved.
Pointers to websites and papers appreciated.
I am using a custom kernel tree, 2.6.17.1, some of Grant Likely stuff is already in there (from the original developer on this project).
Thanks,
Joe Robertson
Joseph.Robertson@sanmina-sci.com
CONFIDENTIALITY
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
[-- Attachment #2: Type: text/html, Size: 2423 bytes --]
^ permalink raw reply
* DMA Generic Task API
From: Pedro Luis D. L. @ 2007-09-24 14:06 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
As I wrote before, I'm trying to use the DMA API to copy audio data to the =
PSC1 which has a digital - analog - converter attached to it.
I read the explanation that Sylvain wrote at: http://ozlabs.org/pipermail/l=
inuxppc-dev/2007-May/036229.html and programmed the following code:
static void SPI_setup(void)
{
int psc_num =3D 1;
phys_addr_t rx_fifo;
phys_addr_t tx_fifo;
struct bcom_bd *bd;
uint32 SICR;
psc =3D ioremap(MPC52xx_PA(MPC52xx_PSCx_OFFSET(1)), MPC52xx_PSC_SIZE);
=09
gpio =3D ioremap(MPC52xx_PA(MPC52xx_GPIO_OFFSET), MPC52xx_GPIO_SIZE);
=09
cdm =3D ioremap(MPC52xx_PA(MPC52xx_CDM_OFFSET), MPC52xx_CDM_SIZE);
switch(psc_num) {
case 1:
initiator_tx =3D BCOM_INITIATOR_PSC1_TX;
initiator_rx =3D BCOM_INITIATOR_PSC1_RX;
break;
case 2:
initiator_tx =3D BCOM_INITIATOR_PSC2_TX;
initiator_rx =3D BCOM_INITIATOR_PSC2_RX;
break;
default:
panic("snd-SPImgt.o: invalid value for psc_num (%i)\n",psc_num);
break;
};
=09
printk("Before gpio->port_config\n");
gpio->port_config |=3D PORT_CONFIG_PSC1;
printk("Before cdm->clk_enables\n");
cdm->clk_enables |=3D PSC1_CLK_EN;
printk("Before cdm->mclken_div_psc1\n");
cdm->mclken_div_psc1 =3D MCLKEN_DIV;
=09
SICR =3D 0x02000000;
SICR |=3D 0x00002000;
SICR |=3D 0x0090C000;
=09
psc->command =3D 0x0A;
psc->sicr =3D SICR;
psc->ctur =3D 0x00;
psc->ctlr =3D 0x84;
psc->ccr &=3D 0xFF0000FF;
psc->rfalarm =3D 0x000C; /* alarm occurs if 12 bytes space in the RxFIFO =
*/
psc->tfalarm =3D 0x0010; /* alarm occurs if 16 bytes are in the TxFIFO */
psc->rfcntl &=3D 0xF8; /* set granularity to 0 */
psc->tfcntl &=3D 0xF8; /* set granularity to 0 */
psc->isr_imr.isr =3D 0x01;
psc->isr_imr.imr =3D 0x00; /* enable TxRDY interrupt */=20
psc->mode =3D 0x00; /* set RX interrupt to RxRDY */
psc->command =3D 0x05; /* enable Tx and Rx */
psc->tfdata =3D 0xF001;
wait(1000);
psc->tfdata =3D 0xF000;
printk("Before bcom_gen_bd_rx_init\n");
rx_bcom =3D bcom_gen_bd_rx_init(64, (phys_addr_t)&(psc->rfdata), initiato=
r_rx, 6, 1024);
printk("Before bcom_gen_bd_tx_init\n");
tx_bcom =3D bcom_gen_bd_tx_init(64, (phys_addr_t)&(psc->tfdata), initiato=
r_tx, 6);
printk("txtask is %d rxtask is %d\n", tx_bcom->tasknum, rx_bcom->tasknum);
r_irq =3D bcom_get_task_irq(rx_bcom);
t_irq =3D bcom_get_task_irq(tx_bcom);
=09
printk("t_irq is %d r_irq is %d\n", t_irq, r_irq);
if (request_irq(r_irq, &SPI_rx_irq, IRQF_DISABLED, "SPI rx dma", NULL)) {
printk(KERN_ERR "SPI: SDMA rx irq allocation failed\n");
return;
} else printk("SPI: SDA rx irq allocation succeded\n");
if (request_irq(t_irq, &SPI_tx_irq, IRQF_DISABLED, "SPI tx dma", NULL)) {
printk(KERN_ERR "SPI: SDMA tx irq allocation failed\n");
return;
} else printk("SPI: SDA tx irq allocation succeded\n");
bcom_gen_bd_tx_reset(tx_bcom);
bcom_gen_bd_rx_reset(rx_bcom);
bcom_retrieve_buffer(tx_bcom, NULL, NULL);
bd =3D bcom_prepare_next_buffer(tx_bcom);
bd->status =3D 1024;
bd->data[0] =3D (void *)SPI_tx_silence.pa;
bcom_submit_next_buffer(tx_bcom, (void *)SPI_tx_silence.pa);
bcom_dump_bdring(tx_bcom);
bcom_dump_bdring(rx_bcom);
printk("Tasks enabled\n");
psc->command =3D MPC52xx_PSC_TX_ENABLE | MPC52xx_PSC_RX_ENABLE;
=09
}
Although everything seems to be executed without problems, the interrupt ro=
utines are never called, and no data seems to be copied to the PSC.
Could it be that I don=B4t understand the purpose of bd->data and bd->stat=
us correctly? Is there any other Documentation or example code I can take a=
look and learn how to use the API?
Thanks,
Pedro L. Dominguez
carcadiz@hotmail.com
_________________________________________________________________
Consigue el nuevo Windows Live Messenger
http://get.live.com/messenger/overview=
^ permalink raw reply
* Re: [PATCH0/4] Various bug fixes
From: Marcelo Tosatti @ 2007-09-24 12:43 UTC (permalink / raw)
To: Jochen Friedrich, Paul Mackerras; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <46F6C9B0.8020200@scram.de>
Paul, please apply.
On Sun, Sep 23, 2007 at 10:16:48PM +0200, Jochen Friedrich wrote:
> Here is a series fixing some bugs for 8xx powerpc CPUs.
>
> 1. [POWERPC] Fix copy'n'paste typo in commproc.c
> 2. [PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
> 3. [PPC] Compile fix for 8xx CPM Ehernet driver
> 4. [POWERPC] Fix cpm_uart driver
>
> This series can be pulled from git://git.bocc.de/dbox2.git ppc-fixes
>
> Thanks,
> Jochen
^ permalink raw reply
* 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Andy Whitcroft @ 2007-09-24 12:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20070924021716.9bfe7dfb.akpm@linux-foundation.org>
Seeing the following from an older power LPAR, pretty sure we had
this in the previous -mm also:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc000000000047ac8
cpu 0x0: Vector: 300 (Data Access) at [c00000000058f750]
pc: c000000000047ac8: .pSeries_log_error+0x364/0x420
lr: c000000000047a4c: .pSeries_log_error+0x2e8/0x420
sp: c00000000058f9d0
msr: 8000000000001032
dar: 0
dsisr: 42000000
current = 0xc0000000004a9b30
paca = 0xc0000000004aa700
pid = 0, comm = swapper
enter ? for help
[c00000000058faf0] c000000000021164 .rtas_call+0x200/0x250
[c00000000058fba0] c000000000049cd0 .early_enable_eeh+0x168/0x360
[c00000000058fc70] c00000000002f674 .traverse_pci_devices+0x8c/0x138
[c00000000058fd10] c000000000460ce8 .eeh_init+0x1a8/0x200
[c00000000058fdb0] c00000000045fb70 .pSeries_setup_arch+0x128/0x234
[c00000000058fe40] c00000000044f830 .setup_arch+0x214/0x24c
[c00000000058fee0] c000000000446a38 .start_kernel+0xd4/0x3e4
[c00000000058ff90] c000000000373194 .start_here_common+0x54/0x58
This machine is a:
processor : 0
cpu : POWER4+ (gq)
clock : 1703.965296MHz
revision : 19.0
[...]
timebase : 212995662
machine : CHRP IBM,7040-681
-apw
^ permalink raw reply
* Re: [patch 6/6] Walnut zImage wrapper
From: Josh Boyer @ 2007-09-24 12:25 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <46F7AB94.9060007@grandegger.com>
On Mon, 24 Sep 2007 14:20:36 +0200
Wolfgang Grandegger <wg@grandegger.com> wrote:
> Josh Boyer wrote:
> > On Mon, 24 Sep 2007 09:49:33 +0200
> > Wolfgang Grandegger <wg@grandegger.com> wrote:
> >> The addition of treeboot-walnut.c breaks compilation of Linux-2.6 for
> >> the lite5200 using the ppc_6xx toolchain of the ELDK 4.1:
> >>
> >> MODPOST vmlinux.o
> >> WARNING: vmlinux.o(.text+0x14): Section mismatch: reference to
> >> .init.text:prom_init (between '__start' and '__after_mmu_off')
> >> WARNING: vmlinux.o(.text+0x28): Section mismatch: reference to
> >> .init.text:early_init (between '__start' and '__after_mmu_off')
> >> WARNING: vmlinux.o(.text+0x340c): Section mismatch: reference to
> >> .init.text:machine_init (between 'start_here' and 'set_context')
> >> WARNING: vmlinux.o(.text+0x3414): Section mismatch: reference to
> >> .init.text:MMU_init (between 'start_here' and 'set_context')
> >> WARNING: vmlinux.o(.text+0x343e): Section mismatch: reference to
> >> .init.text:start_kernel (between 'start_here' and 'set_context')
> >> WARNING: vmlinux.o(.text+0x3442): Section mismatch: reference to
> >> .init.text:start_kernel (between 'start_here' and 'set_context')
> >> GEN .version
> >> CHK include/linux/compile.h
> >> UPD include/linux/compile.h
> >> CC init/version.o
> >> LD init/built-in.o
> >> LD vmlinux
> >> SYSMAP System.map
> >> BOOTAS arch/powerpc/boot/string.o
> >> BOOTAS arch/powerpc/boot/crt0.o
> >> BOOTCC arch/powerpc/boot/stdio.o
> >> BOOTCC arch/powerpc/boot/main.o
> >> BOOTCC arch/powerpc/boot/flatdevtree.o
> >> BOOTCC arch/powerpc/boot/flatdevtree_misc.o
> >> BOOTCC arch/powerpc/boot/ns16550.o
> >> BOOTCC arch/powerpc/boot/serial.o
> >> BOOTCC arch/powerpc/boot/simple_alloc.o
> >> BOOTAS arch/powerpc/boot/div64.o
> >> BOOTAS arch/powerpc/boot/util.o
> >> BOOTCC arch/powerpc/boot/gunzip_util.o
> >> BOOTCC arch/powerpc/boot/elf_util.o
> >> BOOTCC arch/powerpc/boot/inffast.o
> >> BOOTCC arch/powerpc/boot/inflate.o
> >> BOOTCC arch/powerpc/boot/inftrees.o
> >> BOOTCC arch/powerpc/boot/devtree.o
> >> BOOTCC arch/powerpc/boot/oflib.o
> >> BOOTCC arch/powerpc/boot/ofconsole.o
> >> BOOTCC arch/powerpc/boot/4xx.o
> >> BOOTCC arch/powerpc/boot/ebony.o
> >> BOOTCC arch/powerpc/boot/mv64x60.o
> >> BOOTCC arch/powerpc/boot/mpsc.o
> >> BOOTCC arch/powerpc/boot/mv64x60_i2c.o
> >> BOOTCC arch/powerpc/boot/cuboot.o
> >> BOOTCC arch/powerpc/boot/bamboo.o
> >> BOOTAR arch/powerpc/boot/wrapper.a
> >> BOOTCC arch/powerpc/boot/of.o
> >> BOOTCC arch/powerpc/boot/cuboot-83xx.o
> >> BOOTCC arch/powerpc/boot/cuboot-85xx.o
> >> BOOTCC arch/powerpc/boot/holly.o
> >> BOOTCC arch/powerpc/boot/cuboot-ebony.o
> >> BOOTCC arch/powerpc/boot/treeboot-ebony.o
> >> BOOTCC arch/powerpc/boot/prpmc2800.o
> >> BOOTAS arch/powerpc/boot/ps3-head.o
> >> BOOTAS arch/powerpc/boot/ps3-hvcall.o
> >> BOOTCC arch/powerpc/boot/ps3.o
> >> BOOTCC arch/powerpc/boot/treeboot-bamboo.o
> >> BOOTCC arch/powerpc/boot/cuboot-sequoia.o
> >> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> >> {standard input}: Assembler messages:
> >> {standard input}:184: Error: Unrecognized opcode: `mfdcr'
> >> {standard input}:185: Error: Unrecognized opcode: `mfdcr'
> >> {standard input}:186: Error: Unrecognized opcode: `mfdcr'
> >> {standard input}:217: Error: Unrecognized opcode: `mtdcr'
> >> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
> >> make: *** [uImage] Error 2
> >>
> >> It looks like the ppc_6xx toolchain does not know the opcode above. I
> >> wonder why files for other PowerPC sub-archs like 4xx are compiled with
> >> the wrong compiler. Have I missed something?
> >
> > No, you haven't missed anything. I need a one line patch to fix it.
> > Could you try the patch below to make sure it works for you?
>
> It works for me with one typo corrected (see below).
Ah, yes. That's what I get for coding before coffee.
Thanks Wolfgang.
josh
^ permalink raw reply
* Re: [patch 6/6] Walnut zImage wrapper
From: Wolfgang Grandegger @ 2007-09-24 12:20 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20070924070312.3dee3dd9@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Mon, 24 Sep 2007 09:49:33 +0200
> Wolfgang Grandegger <wg@grandegger.com> wrote:
>> The addition of treeboot-walnut.c breaks compilation of Linux-2.6 for
>> the lite5200 using the ppc_6xx toolchain of the ELDK 4.1:
>>
>> MODPOST vmlinux.o
>> WARNING: vmlinux.o(.text+0x14): Section mismatch: reference to
>> .init.text:prom_init (between '__start' and '__after_mmu_off')
>> WARNING: vmlinux.o(.text+0x28): Section mismatch: reference to
>> .init.text:early_init (between '__start' and '__after_mmu_off')
>> WARNING: vmlinux.o(.text+0x340c): Section mismatch: reference to
>> .init.text:machine_init (between 'start_here' and 'set_context')
>> WARNING: vmlinux.o(.text+0x3414): Section mismatch: reference to
>> .init.text:MMU_init (between 'start_here' and 'set_context')
>> WARNING: vmlinux.o(.text+0x343e): Section mismatch: reference to
>> .init.text:start_kernel (between 'start_here' and 'set_context')
>> WARNING: vmlinux.o(.text+0x3442): Section mismatch: reference to
>> .init.text:start_kernel (between 'start_here' and 'set_context')
>> GEN .version
>> CHK include/linux/compile.h
>> UPD include/linux/compile.h
>> CC init/version.o
>> LD init/built-in.o
>> LD vmlinux
>> SYSMAP System.map
>> BOOTAS arch/powerpc/boot/string.o
>> BOOTAS arch/powerpc/boot/crt0.o
>> BOOTCC arch/powerpc/boot/stdio.o
>> BOOTCC arch/powerpc/boot/main.o
>> BOOTCC arch/powerpc/boot/flatdevtree.o
>> BOOTCC arch/powerpc/boot/flatdevtree_misc.o
>> BOOTCC arch/powerpc/boot/ns16550.o
>> BOOTCC arch/powerpc/boot/serial.o
>> BOOTCC arch/powerpc/boot/simple_alloc.o
>> BOOTAS arch/powerpc/boot/div64.o
>> BOOTAS arch/powerpc/boot/util.o
>> BOOTCC arch/powerpc/boot/gunzip_util.o
>> BOOTCC arch/powerpc/boot/elf_util.o
>> BOOTCC arch/powerpc/boot/inffast.o
>> BOOTCC arch/powerpc/boot/inflate.o
>> BOOTCC arch/powerpc/boot/inftrees.o
>> BOOTCC arch/powerpc/boot/devtree.o
>> BOOTCC arch/powerpc/boot/oflib.o
>> BOOTCC arch/powerpc/boot/ofconsole.o
>> BOOTCC arch/powerpc/boot/4xx.o
>> BOOTCC arch/powerpc/boot/ebony.o
>> BOOTCC arch/powerpc/boot/mv64x60.o
>> BOOTCC arch/powerpc/boot/mpsc.o
>> BOOTCC arch/powerpc/boot/mv64x60_i2c.o
>> BOOTCC arch/powerpc/boot/cuboot.o
>> BOOTCC arch/powerpc/boot/bamboo.o
>> BOOTAR arch/powerpc/boot/wrapper.a
>> BOOTCC arch/powerpc/boot/of.o
>> BOOTCC arch/powerpc/boot/cuboot-83xx.o
>> BOOTCC arch/powerpc/boot/cuboot-85xx.o
>> BOOTCC arch/powerpc/boot/holly.o
>> BOOTCC arch/powerpc/boot/cuboot-ebony.o
>> BOOTCC arch/powerpc/boot/treeboot-ebony.o
>> BOOTCC arch/powerpc/boot/prpmc2800.o
>> BOOTAS arch/powerpc/boot/ps3-head.o
>> BOOTAS arch/powerpc/boot/ps3-hvcall.o
>> BOOTCC arch/powerpc/boot/ps3.o
>> BOOTCC arch/powerpc/boot/treeboot-bamboo.o
>> BOOTCC arch/powerpc/boot/cuboot-sequoia.o
>> BOOTCC arch/powerpc/boot/treeboot-walnut.o
>> {standard input}: Assembler messages:
>> {standard input}:184: Error: Unrecognized opcode: `mfdcr'
>> {standard input}:185: Error: Unrecognized opcode: `mfdcr'
>> {standard input}:186: Error: Unrecognized opcode: `mfdcr'
>> {standard input}:217: Error: Unrecognized opcode: `mtdcr'
>> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
>> make: *** [uImage] Error 2
>>
>> It looks like the ppc_6xx toolchain does not know the opcode above. I
>> wonder why files for other PowerPC sub-archs like 4xx are compiled with
>> the wrong compiler. Have I missed something?
>
> No, you haven't missed anything. I need a one line patch to fix it.
> Could you try the patch below to make sure it works for you?
It works for me with one typo corrected (see below).
>
>> And the WARNING above on "Section mismatch" looks strange as well (still
>> present in 2.6.23-rc7).
>
> Those warnings should be gone with Paul's latest tree. (They will
> remain for 2.6.23.)
OK.
> Pass the correct -mcpu option for treeboot-walnut.o to avoid
> unrecognized opcodes.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
> index c1582b6..8e6d36b 100644
> --- a/arch/powerpc/boot/Makefile
> +++ b/arch/powerpc/boot/Makefile
> @@ -33,6 +33,7 @@ BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
>
> $(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
> $(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
> +$(obj)/treeboot-walnut.o: BOOTFLAGS += -mcpu=405
^^^^^^^^^ typo, should be BOOTCFLAGS
Thanks.
Wolfgang.
^ permalink raw reply
* Re: [patch 6/6] Walnut zImage wrapper
From: Josh Boyer @ 2007-09-24 12:03 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <46F76C0D.5090006@grandegger.com>
On Mon, 24 Sep 2007 09:49:33 +0200
Wolfgang Grandegger <wg@grandegger.com> wrote:
>
> The addition of treeboot-walnut.c breaks compilation of Linux-2.6 for
> the lite5200 using the ppc_6xx toolchain of the ELDK 4.1:
>
> MODPOST vmlinux.o
> WARNING: vmlinux.o(.text+0x14): Section mismatch: reference to
> .init.text:prom_init (between '__start' and '__after_mmu_off')
> WARNING: vmlinux.o(.text+0x28): Section mismatch: reference to
> .init.text:early_init (between '__start' and '__after_mmu_off')
> WARNING: vmlinux.o(.text+0x340c): Section mismatch: reference to
> .init.text:machine_init (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x3414): Section mismatch: reference to
> .init.text:MMU_init (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x343e): Section mismatch: reference to
> .init.text:start_kernel (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x3442): Section mismatch: reference to
> .init.text:start_kernel (between 'start_here' and 'set_context')
> GEN .version
> CHK include/linux/compile.h
> UPD include/linux/compile.h
> CC init/version.o
> LD init/built-in.o
> LD vmlinux
> SYSMAP System.map
> BOOTAS arch/powerpc/boot/string.o
> BOOTAS arch/powerpc/boot/crt0.o
> BOOTCC arch/powerpc/boot/stdio.o
> BOOTCC arch/powerpc/boot/main.o
> BOOTCC arch/powerpc/boot/flatdevtree.o
> BOOTCC arch/powerpc/boot/flatdevtree_misc.o
> BOOTCC arch/powerpc/boot/ns16550.o
> BOOTCC arch/powerpc/boot/serial.o
> BOOTCC arch/powerpc/boot/simple_alloc.o
> BOOTAS arch/powerpc/boot/div64.o
> BOOTAS arch/powerpc/boot/util.o
> BOOTCC arch/powerpc/boot/gunzip_util.o
> BOOTCC arch/powerpc/boot/elf_util.o
> BOOTCC arch/powerpc/boot/inffast.o
> BOOTCC arch/powerpc/boot/inflate.o
> BOOTCC arch/powerpc/boot/inftrees.o
> BOOTCC arch/powerpc/boot/devtree.o
> BOOTCC arch/powerpc/boot/oflib.o
> BOOTCC arch/powerpc/boot/ofconsole.o
> BOOTCC arch/powerpc/boot/4xx.o
> BOOTCC arch/powerpc/boot/ebony.o
> BOOTCC arch/powerpc/boot/mv64x60.o
> BOOTCC arch/powerpc/boot/mpsc.o
> BOOTCC arch/powerpc/boot/mv64x60_i2c.o
> BOOTCC arch/powerpc/boot/cuboot.o
> BOOTCC arch/powerpc/boot/bamboo.o
> BOOTAR arch/powerpc/boot/wrapper.a
> BOOTCC arch/powerpc/boot/of.o
> BOOTCC arch/powerpc/boot/cuboot-83xx.o
> BOOTCC arch/powerpc/boot/cuboot-85xx.o
> BOOTCC arch/powerpc/boot/holly.o
> BOOTCC arch/powerpc/boot/cuboot-ebony.o
> BOOTCC arch/powerpc/boot/treeboot-ebony.o
> BOOTCC arch/powerpc/boot/prpmc2800.o
> BOOTAS arch/powerpc/boot/ps3-head.o
> BOOTAS arch/powerpc/boot/ps3-hvcall.o
> BOOTCC arch/powerpc/boot/ps3.o
> BOOTCC arch/powerpc/boot/treeboot-bamboo.o
> BOOTCC arch/powerpc/boot/cuboot-sequoia.o
> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> {standard input}: Assembler messages:
> {standard input}:184: Error: Unrecognized opcode: `mfdcr'
> {standard input}:185: Error: Unrecognized opcode: `mfdcr'
> {standard input}:186: Error: Unrecognized opcode: `mfdcr'
> {standard input}:217: Error: Unrecognized opcode: `mtdcr'
> make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 1
> make: *** [uImage] Error 2
>
> It looks like the ppc_6xx toolchain does not know the opcode above. I
> wonder why files for other PowerPC sub-archs like 4xx are compiled with
> the wrong compiler. Have I missed something?
No, you haven't missed anything. I need a one line patch to fix it.
Could you try the patch below to make sure it works for you?
> And the WARNING above on "Section mismatch" looks strange as well (still
> present in 2.6.23-rc7).
Those warnings should be gone with Paul's latest tree. (They will
remain for 2.6.23.)
josh
Pass the correct -mcpu option for treeboot-walnut.o to avoid
unrecognized opcodes.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index c1582b6..8e6d36b 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -33,6 +33,7 @@ BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
+$(obj)/treeboot-walnut.o: BOOTFLAGS += -mcpu=405
zlib := inffast.c inflate.c inftrees.c
zlibheader := inffast.h inffixed.h inflate.h inftrees.h infutil.h
^ permalink raw reply related
* multicast in MPC8272ADS
From: Nethra @ 2007-09-24 11:53 UTC (permalink / raw)
To: linuxppc-embedded
hi,
I have written a multicast test application in which there is a multicast
sender and receiver.
The multicast sender sends multicast packets on a specified interface and
the multicast
receiver receives multicast packets. I have tested this application on my
network with
x86 machines. But when I run a multicast receiver (which has been cross
compiled for
MPC8272ADS) on my MPC board, it is unable to receive multicast packets (the
recvfrom
call is waiting for ever for packets to arrive). The MPC board is able to
send multicast
packets to without any problems. The /proc/net/dev_mcast shows the
appropriate
entries for the multicast address being enabled for the interface of
interest(esentially
group joining appear to work).
My configuration is a MPC8272ADS board rp_filter =0 for all interfaces (ie
no source
filtering).I am wondering where the problem could be, configurations or the
ethernet
driver itself? Are there some known issues ?
By the way with loopback enabled the reception of packets works
in case the sender and receiver are on the same machine
waiting for ur comments..
thnks
--
View this message in context: http://www.nabble.com/multicast-in-MPC8272ADS-tf4508713.html#a12858422
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Valentine Barshak @ 2007-09-24 11:36 UTC (permalink / raw)
To: linuxppc-dev
Currently zImage is linked at the 4MB base address.
Some platforms (using cuboot, treeboot) need the zImage's
entry point and base address. They place zImage exactly
at the base address it's been linked to. Sometimes 4MB left
at the start of the memory is simply not enough to unpack zImage.
This could happen with initramfs enabled, since the kernel image
packed along with initramfs.cpio could be over 5MB in size.
This patch checks vmlinux image size and links zImage at
the base address that is equal to the unpacked image size
aligned to 4MB boundary. This way zImage base address is 4MB
only if unpacked kernel image size is less then 4MB.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/boot/wrapper | 6 ++++--
arch/powerpc/boot/zImage.lds.S | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff -ruN linux-2.6.orig/arch/powerpc/boot/wrapper linux-2.6/arch/powerpc/boot/wrapper
--- linux-2.6.orig/arch/powerpc/boot/wrapper 2007-09-22 00:48:08.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/wrapper 2007-09-22 04:03:40.000000000 +0400
@@ -215,8 +215,10 @@
fi
if [ "$platform" != "miboot" ]; then
- ${CROSS}ld -m elf32ppc -T $lds -o "$ofile" \
- $platformo $tmp $object/wrapper.a
+ kstart=0x`${CROSS}nm "$kernel" | grep ' _start$' | cut -d' ' -f1`
+ kend=0x`${CROSS}nm "$kernel" | grep ' _end$' | cut -d' ' -f1`
+ ${CROSS}ld -m elf32ppc --defsym _kstart=$kstart --defsym _kend=$kend \
+ -T $lds -o "$ofile" $platformo $tmp $object/wrapper.a
rm $tmp
fi
diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S linux-2.6/arch/powerpc/boot/zImage.lds.S
--- linux-2.6.orig/arch/powerpc/boot/zImage.lds.S 2007-09-22 00:48:08.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/zImage.lds.S 2007-09-22 04:03:58.000000000 +0400
@@ -3,7 +3,7 @@
EXTERN(_zimage_start)
SECTIONS
{
- . = (4*1024*1024);
+ . = ALIGN((_kend - _kstart), (4*1024*1024));
_start = .;
.text :
{
^ permalink raw reply
* Re: AMCC yosemite 440ep PCI slot doesn't work.
From: Valentine Barshak @ 2007-09-24 11:20 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200709241314.18123.sr@denx.de>
Stefan Roese wrote:
> On Monday 24 September 2007, Andrew Liu wrote:
>> By default, it is IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE
>
> And that should be correct for PCI interrupts.
>
>> I change it to IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE or
>> IRQ_SENSE_EDGE | IRQ_POLARITY_POSITIVE.
>> It displays:
>> eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
>> eth2: no IPv6 routers present
>> NETDEV WATCHDOG: eth2: transmit timed out
>> eth2: Transmit timeout, status 0c 0005 c07f media 10.
>> eth2: Tx queue start entry 4 dirty entry 0.
>> eth2: Tx descriptor 0 is 0008a05a. (queue head)
>> eth2: Tx descriptor 1 is 0008a04e.
>> eth2: Tx descriptor 2 is 0008a046.
>> eth2: Tx descriptor 3 is 0008a05a.
>> eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
>>
>> and
>> root@localhost:/root> ifconfig eth2
>> eth2 Link encap:Ethernet HWaddr 00:0E:2E:7E:F5:E6
>> inet addr:128.224.149.13 Bcast:128.224.255.255 Mask:255.255.0.0
>> inet6 addr: fe80::20e:2eff:fe7e:f5e6/64 Scope:Link
>> UP BROADCAST RUNNING 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)
>> Interrupt:25 Base address:0x6f00
>>
>>
>> and
>> root@localhost:/root> cat /proc/interrupts
>> CPU0
>> 2: 0 UIC0 Edge IBM IIC
>> 7: 0 UIC0 Edge IBM IIC
>> 10: 11961 UIC0 Edge MAL TX EOB
>> 11: 18471 UIC0 Edge MAL RX EOB
>> 25: 0 UIC0 Edge eth2
>> 32: 0 UIC1 Edge MAL SERR
>> 33: 0 UIC1 Edge MAL TX DE
>> 34: 0 UIC1 Edge MAL RX DE
>> 40: 32 UIC1 Edge ohci_hcd:usb1
>> 60: 0 UIC1 Edge EMAC
>> BAD: 0
>>
>>
>> Can PCI slot use level trigger?
>>
>> give me some advice.
This could be caused by misseting the IRQ_lEVEL flag in desc->status.
There have been a commit 4dc7b4b0405fd7320940849b6e31ea8ea68fd0df that
fixes the problem.
Thanks,
Valentine.
>
> Hmmm. Did you try an earlier Linux version too? For example 2.6.22 or even
> earlier? Please give it a try and let us know if the same problem occurs.
>
> Best regards,
> Stefan
>
> =====================================================================
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
> =====================================================================
^ permalink raw reply
* Re: AMCC yosemite 440ep PCI slot doesn't work.
From: Stefan Roese @ 2007-09-24 11:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <46F784B0.1040600@windriver.com>
On Monday 24 September 2007, Andrew Liu wrote:
> By default, it is IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE
And that should be correct for PCI interrupts.
> I change it to IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE or
> IRQ_SENSE_EDGE | IRQ_POLARITY_POSITIVE.
> It displays:
> eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
> eth2: no IPv6 routers present
> NETDEV WATCHDOG: eth2: transmit timed out
> eth2: Transmit timeout, status 0c 0005 c07f media 10.
> eth2: Tx queue start entry 4 dirty entry 0.
> eth2: Tx descriptor 0 is 0008a05a. (queue head)
> eth2: Tx descriptor 1 is 0008a04e.
> eth2: Tx descriptor 2 is 0008a046.
> eth2: Tx descriptor 3 is 0008a05a.
> eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
>
> and
> root@localhost:/root> ifconfig eth2
> eth2 Link encap:Ethernet HWaddr 00:0E:2E:7E:F5:E6
> inet addr:128.224.149.13 Bcast:128.224.255.255 Mask:255.255.0.0
> inet6 addr: fe80::20e:2eff:fe7e:f5e6/64 Scope:Link
> UP BROADCAST RUNNING 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)
> Interrupt:25 Base address:0x6f00
>
>
> and
> root@localhost:/root> cat /proc/interrupts
> CPU0
> 2: 0 UIC0 Edge IBM IIC
> 7: 0 UIC0 Edge IBM IIC
> 10: 11961 UIC0 Edge MAL TX EOB
> 11: 18471 UIC0 Edge MAL RX EOB
> 25: 0 UIC0 Edge eth2
> 32: 0 UIC1 Edge MAL SERR
> 33: 0 UIC1 Edge MAL TX DE
> 34: 0 UIC1 Edge MAL RX DE
> 40: 32 UIC1 Edge ohci_hcd:usb1
> 60: 0 UIC1 Edge EMAC
> BAD: 0
>
>
> Can PCI slot use level trigger?
>
> give me some advice.
Hmmm. Did you try an earlier Linux version too? For example 2.6.22 or even
earlier? Please give it a try and let us know if the same problem occurs.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: 2.6.23-rc6-mm1: Build failures on ppc64_defconfig
From: Mel Gorman @ 2007-09-24 11:12 UTC (permalink / raw)
To: Satyam Sharma
Cc: linuxppc-dev, Andrew Morton, Linux Kernel Mailing List, jeff,
Linux Netdev Mailing List
In-Reply-To: <alpine.LFD.0.999.0709221221500.22517@enigma.security.iitk.ac.in>
On (22/09/07 12:24), Satyam Sharma didst pronounce:
>
>
> On Thu, 20 Sep 2007, Satyam Sharma wrote:
> >
> > BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> > IIRC I got build failures in:
>
> > drivers/net/spider_net.c
>
>
> [PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
>
> Unbreak the following:
>
> drivers/net/spider_net.c: In function 'spider_net_release_tx_chain':
> drivers/net/spider_net.c:818: error: 'dev' undeclared (first use in this function)
> drivers/net/spider_net.c:818: error: (Each undeclared identifier is reported only once
> drivers/net/spider_net.c:818: error: for each function it appears in.)
> drivers/net/spider_net.c: In function 'spider_net_xmit':
> drivers/net/spider_net.c:922: error: 'dev' undeclared (first use in this function)
> drivers/net/spider_net.c: In function 'spider_net_pass_skb_up':
> drivers/net/spider_net.c:1018: error: 'dev' undeclared (first use in this function)
> drivers/net/spider_net.c: In function 'spider_net_decode_one_descr':
> drivers/net/spider_net.c:1215: error: 'dev' undeclared (first use in this function)
> make[2]: *** [drivers/net/spider_net.o] Error 1
>
> Signed-off-by: Satyam Sharma <satyam@infradead.org>
I've confirmed that this patch fixes the build error in question.
Acked-by: Mel Gorman <mel@csn.ul.ie>
>
> ---
>
> drivers/net/spider_net.c | 24 +++++++++++-------------
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff -ruNp a/drivers/net/spider_net.c b/drivers/net/spider_net.c
> --- a/drivers/net/spider_net.c 2007-09-22 06:26:39.000000000 +0530
> +++ b/drivers/net/spider_net.c 2007-09-22 12:12:23.000000000 +0530
> @@ -795,6 +795,7 @@ spider_net_set_low_watermark(struct spid
> static int
> spider_net_release_tx_chain(struct spider_net_card *card, int brutal)
> {
> + struct net_device *dev = card->netdev;
> struct spider_net_descr_chain *chain = &card->tx_chain;
> struct spider_net_descr *descr;
> struct spider_net_hw_descr *hwdescr;
> @@ -919,7 +920,7 @@ spider_net_xmit(struct sk_buff *skb, str
> spider_net_release_tx_chain(card, 0);
>
> if (spider_net_prepare_tx_descr(card, skb) != 0) {
> - dev->stats.tx_dropped++;
> + netdev->stats.tx_dropped++;
> netif_stop_queue(netdev);
> return NETDEV_TX_BUSY;
> }
> @@ -979,16 +980,12 @@ static void
> spider_net_pass_skb_up(struct spider_net_descr *descr,
> struct spider_net_card *card)
> {
> - struct spider_net_hw_descr *hwdescr= descr->hwdescr;
> - struct sk_buff *skb;
> - struct net_device *netdev;
> - u32 data_status, data_error;
> -
> - data_status = hwdescr->data_status;
> - data_error = hwdescr->data_error;
> - netdev = card->netdev;
> + struct spider_net_hw_descr *hwdescr = descr->hwdescr;
> + struct sk_buff *skb = descr->skb;
> + struct net_device *netdev = card->netdev;
> + u32 data_status = hwdescr->data_status;
> + u32 data_error = hwdescr->data_error;
>
> - skb = descr->skb;
> skb_put(skb, hwdescr->valid_size);
>
> /* the card seems to add 2 bytes of junk in front
> @@ -1015,8 +1012,8 @@ spider_net_pass_skb_up(struct spider_net
> }
>
> /* update netdevice statistics */
> - dev->stats.rx_packets++;
> - dev->stats.rx_bytes += skb->len;
> + netdev->stats.rx_packets++;
> + netdev->stats.rx_bytes += skb->len;
>
> /* pass skb up to stack */
> netif_receive_skb(skb);
> @@ -1184,6 +1181,7 @@ static int spider_net_resync_tail_ptr(st
> static int
> spider_net_decode_one_descr(struct spider_net_card *card)
> {
> + struct net_device *dev = card->netdev;
> struct spider_net_descr_chain *chain = &card->rx_chain;
> struct spider_net_descr *descr = chain->tail;
> struct spider_net_hw_descr *hwdescr = descr->hwdescr;
> @@ -1210,7 +1208,7 @@ spider_net_decode_one_descr(struct spide
> (status == SPIDER_NET_DESCR_PROTECTION_ERROR) ||
> (status == SPIDER_NET_DESCR_FORCE_END) ) {
> if (netif_msg_rx_err(card))
> - dev_err(&card->netdev->dev,
> + dev_err(&dev->dev,
> "dropping RX descriptor with state %d\n", status);
> dev->stats.rx_dropped++;
> goto bad_desc;
>
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: 2.6.23-rc6-mm1: Build failure on ppc64 drivers/ata/pata_scc.c
From: Mel Gorman @ 2007-09-24 11:01 UTC (permalink / raw)
To: Satyam Sharma
Cc: jeff, linuxppc-dev, Linux Kernel Mailing List, kamalesh,
linux-ide, Andrew Morton, Alan Cox
In-Reply-To: <alpine.LFD.0.999.0709220816170.14412@enigma.security.iitk.ac.in>
On (22/09/07 08:20), Satyam Sharma didst pronounce:
> Hi,
>
>
> On Thu, 20 Sep 2007, Alan Cox wrote:
> >
> > On Thu, 20 Sep 2007 14:13:15 +0100
> > mel@skynet.ie (Mel Gorman) wrote:
> >
> > > PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
> > > doesn't show up on other arches because this driver is specific to the
> > > architecture.
> > >
> > > drivers/ata/pata_scc.c: In function `scc_bmdma_status'
> >
> > Its not been updated to match the libata core changes. Try something like
> > this. Whoever is maintaining it should also remove the prereset cable handling
> > code and use the proper cable detect method.
>
> It appears you forgot to fix scc_std_softreset() and one of its callsites
> in scc_bdma_stop(). A complete patch is attempted below -- please review.
>
I can confirm it builds without warnings or errors, so thanks. I'm not in
the position to review it for correctness.
>
> [PATCH -mm] pata_scc: Keep up with libata core API changes
>
> Little fixlets, that the build started erroring / warning about:
>
> drivers/ata/pata_scc.c: In function 'scc_bmdma_status':
> drivers/ata/pata_scc.c:734: error: structure has no member named 'active_tag'
> drivers/ata/pata_scc.c: In function 'scc_pata_prereset':
> drivers/ata/pata_scc.c:866: warning: passing arg 1 of 'ata_std_prereset' from incompatible pointer type
> drivers/ata/pata_scc.c: In function 'scc_error_handler':
> drivers/ata/pata_scc.c:908: warning: passing arg 2 of 'ata_bmdma_drive_eh' from incompatible pointer type
> drivers/ata/pata_scc.c:908: warning: passing arg 3 of 'ata_bmdma_drive_eh' from incompatible pointer type
> drivers/ata/pata_scc.c:908: warning: passing arg 5 of 'ata_bmdma_drive_eh' from incompatible pointer type
> make[2]: *** [drivers/ata/pata_scc.o] Error 1
>
> Signed-off-by: Satyam Sharma <satyam@infradead.org>
> Cc: Alan Cox <alan@redhat.com>
> Cc: Mel Gorman <mel@skynet.ie>
>
> ---
>
> Andrew, this includes (supercedes) the previous two ones from Mel / Alan.
>
> drivers/ata/pata_scc.c | 21 ++++++++++++---------
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff -ruNp a/drivers/ata/pata_scc.c b/drivers/ata/pata_scc.c
> --- a/drivers/ata/pata_scc.c 2007-09-22 06:26:37.000000000 +0530
> +++ b/drivers/ata/pata_scc.c 2007-09-22 08:04:42.000000000 +0530
> @@ -594,16 +594,17 @@ static unsigned int scc_bus_softreset(st
> * Note: Original code is ata_std_softreset().
> */
>
> -static int scc_std_softreset (struct ata_port *ap, unsigned int *classes,
> - unsigned long deadline)
> +static int scc_std_softreset(struct ata_link *link, unsigned int *classes,
> + unsigned long deadline)
> {
> + struct ata_port *ap = link->ap;
> unsigned int slave_possible = ap->flags & ATA_FLAG_SLAVE_POSS;
> unsigned int devmask = 0, err_mask;
> u8 err;
>
> DPRINTK("ENTER\n");
>
> - if (ata_link_offline(&ap->link)) {
> + if (ata_link_offline(link)) {
> classes[0] = ATA_DEV_NONE;
> goto out;
> }
> @@ -692,7 +693,7 @@ static void scc_bmdma_stop (struct ata_q
> printk(KERN_WARNING "%s: Internal Bus Error\n", DRV_NAME);
> out_be32(bmid_base + SCC_DMA_INTST, INTSTS_BMSINT);
> /* TBD: SW reset */
> - scc_std_softreset(ap, &classes, deadline);
> + scc_std_softreset(&ap->link, &classes, deadline);
> continue;
> }
>
> @@ -731,7 +732,7 @@ static u8 scc_bmdma_status (struct ata_p
> void __iomem *mmio = ap->ioaddr.bmdma_addr;
> u8 host_stat = in_be32(mmio + SCC_DMA_STATUS);
> u32 int_status = in_be32(mmio + SCC_DMA_INTST);
> - struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag);
> + struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->link.active_tag);
> static int retry = 0;
>
> /* return if IOS_SS is cleared */
> @@ -860,10 +861,10 @@ static void scc_bmdma_freeze (struct ata
> * @deadline: deadline jiffies for the operation
> */
>
> -static int scc_pata_prereset(struct ata_port *ap, unsigned long deadline)
> +static int scc_pata_prereset(struct ata_link *link, unsigned long deadline)
> {
> - ap->cbl = ATA_CBL_PATA80;
> - return ata_std_prereset(ap, deadline);
> + link->ap->cbl = ATA_CBL_PATA80;
> + return ata_std_prereset(link, deadline);
> }
>
> /**
> @@ -874,8 +875,10 @@ static int scc_pata_prereset(struct ata_
> * Note: Original code is ata_std_postreset().
> */
>
> -static void scc_std_postreset (struct ata_port *ap, unsigned int *classes)
> +static void scc_std_postreset(struct ata_link *link, unsigned int *classes)
> {
> + struct ata_port *ap = link->ap;
> +
> DPRINTK("ENTER\n");
>
> /* is double-select really necessary? */
>
--
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: Sequoia kernel crash workaround.
From: Valentine Barshak @ 2007-09-24 10:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Olof Johansson, Josh Boyer, Stefan Roese,
David Gibson
In-Reply-To: <1190535664.3723.16.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Thu, 2007-09-20 at 12:29 -0500, Josh Boyer wrote:
>> On Thu, 20 Sep 2007 12:25:06 -0500
>> Olof Johansson <olof@lixom.net> wrote:
>>
>>> On Thu, Sep 20, 2007 at 08:56:32PM +0400, Valentine Barshak wrote:
>>>> I was thinking about it. Looks like it's the best place, but the code that
>>>> actually calls setup_cpu is under ifdef CONFIG_PPC64, while lots of
>>>> cpu_setup functions are defined for ppc32 processors.
>>>> Is it OK to remove this ifdef, or should I do CONFIG_PPC64 || CONFIG_44x?
>>> Sounds like something that went wrong at the merge of ppc and ppc64.
>>>
>>> Take out the ifdef, even if there's fallout we should deal with it
>>> instead of adding more complex ifdefs.
>> Yeah. Looks like BenH did this in commit:
>>
>> 42c4aaadb737e0e672b3fb86b2c41ff59f0fb8bc
>>
>> Ben, any reason you ifdef'd it for ppc64?
>
> I'll have to check on monday what's up there, but isn't setup_cpu called
> from a different place on 32 bits? There are some subtle difference with
> the way the cpu feature stuff is initialized /done between 32 and 64
> bits that we haven't fully reconciled yet.
>
> Ben.
>
From what I've seen, setup_cpu is never called for BOOKE.
Currently It's called from cputable.c for PPC64 and from head_32.S for 6xx.
Thanks,
Valentine.
>
^ permalink raw reply
* Re: [PATCH 0/3] usb: ehci ppc device-tree-aware driver
From: Valentine Barshak @ 2007-09-24 10:33 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <fd46qj$s6r$1@sea.gmane.org>
Hollis Blanchard wrote:
> On Mon, 17 Sep 2007 16:50:39 +0400, Valentine Barshak wrote:
>
>> Some PowerPC systems have a built-in EHCI controller.
>> This is a device tree aware version of the EHCI controller driver.
>> Currently it's been tested on the PowerPC 440EPx Sequoia board.
>> Other platforms can be added later.
>> The code is based on the ehci-ppc-soc driver by Stefan Roese <sr@denx.de>.
>
> We're having a strange issue on our Sequoia where the network stops
> functioning when USB is active. Jerone can supply more detail...
OK.
This possibly could be caused by the plb write pipelining errata.
Please, take a look at:
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042999.html
>
> Have you seen anything like that?
No, I haven't.
>
Thanks,
Valentine.
^ permalink raw reply
* [PATCH v2] bootwrapper: adds cuboot for MPC7448HPC2 platform
From: Zang Roy-r61911 @ 2007-09-24 10:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, David Gibson
In-Reply-To: <1184144056.23579.16.camel@localhost.localdomain>
From: Roy Zang <tie-fei.zang@freescale.com>
This patch adds cuboot support for MPC7448HPC2 platform.
The cuImage can be used with legacy u-boot without FDT support.
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
---
This is the third time for me to generate the patch.
I do not get any negative comment since my previous commit .
Hope your guys can pick it up and merge it into 2.6.24.
The original were pasted at:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036834.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-July/038952.html
Cheers
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/cuboot-hpc2.c | 48 ++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc7448hpc2.dts | 5 +++
arch/powerpc/platforms/embedded6xx/Kconfig | 1 +
4 files changed, 56 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-hpc2.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index cffef14..6ed1415 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -49,7 +49,7 @@ src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
- cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
+ cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-hpc2.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -146,6 +146,7 @@ image-$(CONFIG_8260) += cuImage.pq2
image-$(CONFIG_PPC_83xx) += cuImage.83xx
image-$(CONFIG_PPC_85xx) += cuImage.85xx
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
+image-$(CONFIG_MPC7448HPC2) += cuImage.hpc2
image-$(CONFIG_BAMBOO) += treeImage.bamboo
image-$(CONFIG_SEQUOIA) += cuImage.sequoia
image-$(CONFIG_WALNUT) += treeImage.walnut
diff --git a/arch/powerpc/boot/cuboot-hpc2.c b/arch/powerpc/boot/cuboot-hpc2.c
new file mode 100644
index 0000000..d333898
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-hpc2.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Roy Zang <tie-fei.zang@freescale.com>
+ *
+ * Description:
+ * Old U-boot compatibility for mpc7448hpc2 board
+ * Based on the code of Scott Wood <scottwood@freescale.com>
+ * for 83xx and 85xx.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "cuboot.h"
+
+#define TARGET_HAS_ETH1
+#include "ppcboot.h"
+
+static bd_t bd;
+extern char _dtb_start[], _dtb_end[];
+
+static void platform_fixups(void)
+{
+ void *tsi;
+
+ dt_fixup_memory(bd.bi_memstart, bd.bi_memsize);
+ dt_fixup_mac_addresses(bd.bi_enetaddr, bd.bi_enet1addr);
+ dt_fixup_cpu_clocks(bd.bi_intfreq, bd.bi_busfreq / 4, bd.bi_busfreq);
+ tsi = find_node_by_devtype(NULL, "tsi-bridge");
+ if (tsi)
+ setprop(tsi, "bus-frequency", &bd.bi_busfreq,
+ sizeof(bd.bi_busfreq));
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/dts/mpc7448hpc2.dts b/arch/powerpc/boot/dts/mpc7448hpc2.dts
index 70e8a2e..0b58136 100644
--- a/arch/powerpc/boot/dts/mpc7448hpc2.dts
+++ b/arch/powerpc/boot/dts/mpc7448hpc2.dts
@@ -79,6 +79,7 @@
};
ethernet@6200 {
+ linux,network-index = <0>;
#size-cells = <0>;
device_type = "network";
compatible = "tsi109-ethernet", "tsi108-ethernet";
@@ -91,6 +92,7 @@
};
ethernet@6600 {
+ linux,network-index = <1>;
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
@@ -184,5 +186,8 @@
};
};
};
+ chosen {
+ linux,stdout-path = "/tsi108@c0000000/serial@7808";
+ };
};
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index 2d12f77..6d10e84 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -20,6 +20,7 @@ config MPC7448HPC2
select TSI108_BRIDGE
select DEFAULT_UIMAGE
select PPC_UDBG_16550
+ select WANT_DEVICE_TREE
help
Select MPC7448HPC2 if configuring for Freescale MPC7448HPC2 (Taiga)
platform
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 1/2] qemu platform, v2
From: Milton Miller @ 2007-09-24 9:48 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Paul Mackerras, Rob Landley
In-Reply-To: <20070924074602.GA19514@lst.de>
On Sep 24, 2007, at 2:46 AM, Christoph Hellwig wrote:
> On Mon, Sep 24, 2007 at 02:00:47PM +1000, David Gibson wrote:
>> Basically because PReP support doesn't work under arch/powerpc.
>> Getting it working properly is something that should happen, but will
>> take a while. In the meantime, getting something that's sufficient to
>> get working under just qemu's version of prep, without using the
>> abominable openhackware is a quicker path to a usable arch/powerpc
>> kernel under qemu.
>
> Sounds fair. Care to add something like this to the Kconfig help
> text?
I suppose I could, but actually I wasn't asking for the two qemu
patches to be merged. Instead I was posting "here's something that
provides minimal function for me, hope you can use it too". For
instance, someone should track down pci memory so that ohci and/or
video works. Then test the isa ne2ks, or better yet get qemu to change
them to pci (except then it only works on the latest qemu).
I didn't put it under prep because it could be changed for the other
qemu platforms and doesn't use any thing that makes the machine prep
other than some memory map information. I kept prep because I didn't
want to deal with io to the scc on b&w G3, the other long-term platform
(or with hackware to see if that would just boot as pmac).
milton
^ permalink raw reply
* Re: AMCC yosemite 440ep PCI slot doesn't work.
From: Andrew Liu @ 2007-09-24 9:34 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46F3DFCA.1040700@ru.mvista.com>
By default, it is IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE
I change it to IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE or
IRQ_SENSE_EDGE | IRQ_POLARITY_POSITIVE.
It displays:
eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
eth2: no IPv6 routers present
NETDEV WATCHDOG: eth2: transmit timed out
eth2: Transmit timeout, status 0c 0005 c07f media 10.
eth2: Tx queue start entry 4 dirty entry 0.
eth2: Tx descriptor 0 is 0008a05a. (queue head)
eth2: Tx descriptor 1 is 0008a04e.
eth2: Tx descriptor 2 is 0008a046.
eth2: Tx descriptor 3 is 0008a05a.
eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
and
root@localhost:/root> ifconfig eth2
eth2 Link encap:Ethernet HWaddr 00:0E:2E:7E:F5:E6
inet addr:128.224.149.13 Bcast:128.224.255.255 Mask:255.255.0.0
inet6 addr: fe80::20e:2eff:fe7e:f5e6/64 Scope:Link
UP BROADCAST RUNNING 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)
Interrupt:25 Base address:0x6f00
and
root@localhost:/root> cat /proc/interrupts
CPU0
2: 0 UIC0 Edge IBM IIC
7: 0 UIC0 Edge IBM IIC
10: 11961 UIC0 Edge MAL TX EOB
11: 18471 UIC0 Edge MAL RX EOB
25: 0 UIC0 Edge eth2
32: 0 UIC1 Edge MAL SERR
33: 0 UIC1 Edge MAL TX DE
34: 0 UIC1 Edge MAL RX DE
40: 32 UIC1 Edge ohci_hcd:usb1
60: 0 UIC1 Edge EMAC
BAD: 0
Can PCI slot use level trigger?
give me some advice.
Thanks.
Valentine Barshak wrote:
> Andrew Liu wrote:
>> Hello All,
>>
>> when insert a RealTek RTL8139 network card into PCI slot,
>> After system boot up,
>>
>> root@localhost:/root> ifconfig eth2 192.168.17.12
>> irq 25: nobody cared (try booting with the "irqpoll" option)
>> Call Trace:
>> [cf135af0] [c0008820] show_stack+0x48/0x190 (unreliable)
>> [cf135b20] [c003c414] __report_bad_irq+0x34/0xac
>> [cf135b40] [c003c714] note_interrupt+0x288/0x2c8
>> [cf135b70] [c003b818] __do_IRQ+0x104/0x110
>> [cf135b90] [c0006900] do_IRQ+0xbc/0xc0
>> [cf135ba0] [c00020c0] ret_from_except+0x0/0x18
>> [cf135c60] [00000019] 0x19
>> [cf135c90] [c000668c] do_softirq+0x54/0x58
>> [cf135ca0] [c001df40] irq_exit+0x48/0x58
>> [cf135cb0] [c00068b4] do_IRQ+0x70/0xc0
>> [cf135cc0] [c00020c0] ret_from_except+0x0/0x18
>> [cf135d80] [c003c2b4] setup_irq+0x1ac/0x200
>> [cf135da0] [c003c3cc] request_irq+0xc4/0xd8
>> [cf135dd0] [c0122328] rtl8139_open+0x38/0x210
>> [cf135df0] [c0187500] dev_open+0x7c/0xcc
>> [cf135e10] [c0187420] dev_change_flags+0x16c/0x1d0
>> [cf135e30] [c01cbff0] devinet_ioctl+0x604/0x720
>> [cf135ea0] [c01cc1f8] inet_ioctl+0x98/0xbc
>> [cf135eb0] [c0179328] sock_ioctl+0x60/0x260
>> [cf135ed0] [c006c360] do_ioctl+0x38/0x84
>> [cf135ee0] [c006c438] vfs_ioctl+0x8c/0x40c
>> [cf135f10] [c006c7f8] sys_ioctl+0x40/0x74
>> [cf135f40] [c0001a84] ret_from_syscall+0x0/0x3c
>> handlers:
>> [<c0122bd4>] (rtl8139_interrupt+0x0/0x52c)
>> Disabling IRQ #25
>> root@localhost:/root>
>> Message from syslogd@localhost at Thu Jan 1 00:02:13 1970 ...
>> localhost kernel: Disabling IRQ #25
>>
>> root@localhost:/root>
>>
>>
>> The system boot up information as follows:
>> root@localhost:/root> dmesg
>> Linux version 2.6.23-rc6-gea60adb5 (sliu@localhost.localdomain) (gcc
>> version 4.0.0 (DENX ELDK 4.1 4.0.0)) #3 Fri Sep 21 18:37:59 CST 2007
>> AMCC PowerPC 440EP Yosemite Platform
>> Entering add_active_range(0, 0, 65536) 0 entries of 256 used
>> Zone PFN ranges:
>> DMA 0 -> 65536
>> Normal 65536 -> 65536
>> Movable zone start PFN for each node
>> early_node_map[1] active PFN ranges
>> 0: 0 -> 65536
>> On node 0 totalpages: 65536
>> DMA zone: 512 pages used for memmap
>> DMA zone: 0 pages reserved
>> DMA zone: 65024 pages, LIFO batch:15
>> Normal zone: 0 pages used for memmap
>> Movable zone: 0 pages used for memmap
>> Built 1 zonelists in Zone order. Total pages: 65024
>> Kernel command line: root=/dev/nfs rw
>> nfsroot=128.224.149.6:/tftpboot/sliu/rootfs
>> ip=128.224.149.11::128.224.149.1:255.255.255.0:yosemite:eth0:off
>> console=ttyS0,9600
>> PID hash table entries: 1024 (order: 10, 4096 bytes)
>> console [ttyS0] enabled
>> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
>> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
>> Memory: 256896k available (2052k kernel code, 716k data, 152k init, 0k
>> highmem)
>> Calibrating delay loop... 798.72 BogoMIPS (lpj=1597440)
>> Mount-cache hash table entries: 512
>> NET: Registered protocol family 16
>> PCI: Probing PCI hardware
>> PCI: Scanning bus 0000:00
>> PCI: Found 0000:00:0c.0 [10ec/8139] 000200 00
>> PCI: Calling quirk c000444c for 0000:00:0c.0
>> PCI: Fixups for bus 0000:00
>> PCI: Bus scan for 0000:00 returning with max=00
>> PCI: fixup irq: (0000:00:0c.0) got 25
>> SCSI subsystem initialized
>> usbcore: registered new interface driver usbfs
>> usbcore: registered new interface driver hub
>> usbcore: registered new device driver usb
>> NET: Registered protocol family 2
>> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
>> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
>> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
>> TCP: Hash tables configured (established 8192 bind 8192)
>> TCP reno registered
>> io scheduler noop registered
>> io scheduler anticipatory registered (default)
>> io scheduler deadline registered
>> io scheduler cfq registered
>> PCI: Calling quirk c00fbab4 for 0000:00:0c.0
>> PCI: Calling quirk c02ae3b8 for 0000:00:0c.0
>> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
>> serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
>> serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
>> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
>> PPC 4xx OCP EMAC driver, version 3.54
>> mal0: initialized, 4 TX channels, 2 RX channels
>> zmii0: bridge in RMII mode
>> eth0: emac0, MAC 00:10:ec:00:87:42
>> eth0: found Generic MII PHY (0x01)
>> eth1: emac1, MAC 00:00:00:00:00:00
>> eth1: found Generic MII PHY (0x03)
>> 8139too Fast Ethernet driver 0.9.28
>> eth2: RealTek RTL8139 at 0xd1012f00, 00:0e:2e:7e:f5:e6, IRQ 25
>> eth2: Identified 8139 chip type 'RTL-8100B/8139D'
>> pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver
>> usbcore: registered new interface driver pegasus
>> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
>> ide: Assuming 33MHz system bus speed for PIO modes; override with
>> idebus=xx
>> usbmon: debugfs is not available
>> ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
>> 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: configuration #1 chosen from 1 choice
>> hub 1-0:1.0: USB hub found
>> hub 1-0:1.0: 2 ports detected
>> Initializing USB Mass Storage driver...
>> usbcore: registered new interface driver usb-storage
>> USB Mass Storage support registered.
>> ether gadget: using random self ethernet address
>> ether gadget: using random host ethernet address
>> usb0: Ethernet Gadget, version: May Day 2005
>> usb0: using musbhsfc_udc, OUT ep2 IN ep1 STATUS ep3
>> usb0: MAC 66:91:74:ab:fb:61
>> usb0: HOST MAC 1a:b5:87:5d:8f:00
>> usb0: RNDIS ready
>> musbhsfc_udc: registered gadget driver 'ether'
>> TCP cubic registered
>> NET: Registered protocol family 1
>> NET: Registered protocol family 17
>> usb 1-1: new full speed USB device using ppc-soc-ohci and address 2
>> usb 1-1: configuration #1 chosen from 1 choice
>> eth0: link is up, 100 FDX, pause enabled
>> scsi0 : SCSI emulation for USB Mass Storage devices
>> usb-storage: device found at 2
>> usb-storage: waiting for device to settle before scanning
>> IP-Config: Complete:
>> device=eth0, addr=128.224.149.11, mask=255.255.255.0,
>> gw=128.224.149.1,
>> host=yosemite, domain=, nis-domain=(none),
>> bootserver=255.255.255.255, rootserver=128.224.149.6, rootpath=
>> Looking up port of RPC 100003/2 on 128.224.149.6
>> Looking up port of RPC 100005/1 on 128.224.149.6
>> VFS: Mounted root (nfs filesystem).
>> Freeing unused kernel memory: 152k init
>> scsi 0:0:0:0: Direct-Access Kingston DataTraveler 2.0 6.16 PQ: 0
>> ANSI: 0 CCS
>> sd 0:0:0:0: [sda] 244735 512-byte hardware sectors (125 MB)
>> sd 0:0:0:0: [sda] Write Protect is off
>> sd 0:0:0:0: [sda] Mode Sense: 45 00 00 08
>> sd 0:0:0:0: [sda] Assuming drive cache: write through
>> sd 0:0:0:0: [sda] 244735 512-byte hardware sectors (125 MB)
>> sd 0:0:0:0: [sda] Write Protect is off
>> sd 0:0:0:0: [sda] Mode Sense: 45 00 00 08
>> sd 0:0:0:0: [sda] Assuming drive cache: write through
>> sda: sda1
>> sd 0:0:0:0: [sda] Attached SCSI removable disk
>> sd 0:0:0:0: Attached scsi generic sg0 type 0
>> usb-storage: device scan complete
>> irq 25: nobody cared (try booting with the "irqpoll" option)
>> Call Trace:
>> [cf135af0] [c0008820] show_stack+0x48/0x190 (unreliable)
>> [cf135b20] [c003c414] __report_bad_irq+0x34/0xac
>> [cf135b40] [c003c714] note_interrupt+0x288/0x2c8
>> [cf135b70] [c003b818] __do_IRQ+0x104/0x110
>> [cf135b90] [c0006900] do_IRQ+0xbc/0xc0
>> [cf135ba0] [c00020c0] ret_from_except+0x0/0x18
>> [cf135c60] [00000019] 0x19
>> [cf135c90] [c000668c] do_softirq+0x54/0x58
>> [cf135ca0] [c001df40] irq_exit+0x48/0x58
>> [cf135cb0] [c00068b4] do_IRQ+0x70/0xc0
>> [cf135cc0] [c00020c0] ret_from_except+0x0/0x18
>> [cf135d80] [c003c2b4] setup_irq+0x1ac/0x200
>> [cf135da0] [c003c3cc] request_irq+0xc4/0xd8
>> [cf135dd0] [c0122328] rtl8139_open+0x38/0x210
>> [cf135df0] [c0187500] dev_open+0x7c/0xcc
>> [cf135e10] [c0187420] dev_change_flags+0x16c/0x1d0
>> [cf135e30] [c01cbff0] devinet_ioctl+0x604/0x720
>> [cf135ea0] [c01cc1f8] inet_ioctl+0x98/0xbc
>> [cf135eb0] [c0179328] sock_ioctl+0x60/0x260
>> [cf135ed0] [c006c360] do_ioctl+0x38/0x84
>> [cf135ee0] [c006c438] vfs_ioctl+0x8c/0x40c
>> [cf135f10] [c006c7f8] sys_ioctl+0x40/0x74
>> [cf135f40] [c0001a84] ret_from_syscall+0x0/0x3c
>> handlers:
>> [<c0122bd4>] (rtl8139_interrupt+0x0/0x52c)
>> Disabling IRQ #25
>> eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
>>
>>
>> Who can give some advice?
>>
>> Thanks.
>> BRs,
>> Andrew.
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
> Looks like wrong external interrupt settings (trigger/level) for PCI
> interrupt.
>
^ permalink raw reply
* Re: [PATCH 5/15] bootwrapper: occuppied memory ranges
From: Milton Miller @ 2007-09-24 9:33 UTC (permalink / raw)
To: David Gibson; +Cc: ppcdev, Paul Mackerras
In-Reply-To: <20070924030937.GF8058@localhost.localdomain>
On Sep 23, 2007, at 10:09 PM, David Gibson wrote:
> On Fri, Sep 21, 2007 at 06:04:18PM -0500, Milton Miller wrote:
>> Add a set of library routines to manage gross memory allocations.
>>
>> This code uses an array in bss to store upto 32 entrys with merging
>> representing a range of memory below rma_end (aka end of real mode
>> memory at 0).
>>
>> To use this code, a platform would set rma_end (find_rma_end), mark
>> memory ranges occupied (add_known_ranges et al), initialize malloc in
>> the spaces between (ranges_init_malloc), and optionally use the
>> supplied
>> vmlinux_alloc may be used.
>
> Urg. It's an awful lot of code for the bootwrapper. Am I right in
> understanding that the only reason to use the ranges code is for the
> ranges based malloc() and vmlinux_alloc() you get out of it?
Yes.
The ranges based malloc is simple_alloc after finding a sutable chunk
to operate in.
When doing a kexec, there are several chunks of memory to avoid. There
are at least the wrapper, the initrd, the input device tree, and
possibly rtas and tce tables. The last two are avoided by parsing the
memory resrve list in the flat tree blob.
In practice, on 64 bit powerpc kexec-tools loads the kernel (in this
case zImage) immediately following the old kernel _end (becauset the
kernel doesnt' allow otherwise, like 32 bit and most other platforms
do). If the kernel being execd is larger than the kernel invoking
kexec, then the vmlinux will not fit below the wrapper, but when they
are the same it will fit. So in the malloc region we need space for
random temps, the final device tree, the kernel, and possibly the
initrd -- especially if its attached to the zImage instead of supplied
by kexec-tools.
While I titled this platform kexec, in reality, it is a generic chain
looading platform for flat device trees in that it is invoked with the
same calling conveintions as it calls the kernel. With the current
policy of run-where-loadeed, the wrapper has to be able to find out
what memory is available. It may be above or below itself, and the
bulk of available memory may be after any of the above mentioned
ranges. The only information is the the flat device tree and its
knowledge of itself. Most of this code deals with building the sorted
list of what memory is used.
Actually, there is a hole in that malloc may be initialzed below the
vmlinux.size and the initrd and deviece tree could end up overwritten.
This can't be eliminated without doing something like prpmc2800 where
the kernel decompression is started and the elf header is read before
initializing malloc. In practice has not triggered because the
vmlinux will be malloced before the device tree without an initrd, and
with it the kernel is likely smaller than the wrapper (since the memory
chunk at 0 is avoided, it requires the end of some other chunk to be
low in memory).
At one point you had mentioned considering changes to run out of bss
and handling the initrd and kernel with calls to memmove; any such
movement would requrie similar information to what is being built into
the storted structure in this code to support externally loaded initrds
and device-trees, which could not be allocated into the bss wihout
arbitrarilly limiting their size.
I've made several changes to the split btween memranges.c and kexec.c
over time. Perhaps there are more left. There is a bit of policy in
the ranges malloc initialilzation; that could probably be eliminated by
query functions for the largest chunk. The vmlinux alloc could try just
0 and malloc(). And the area from the last occupied range to roa_end
should be available for malloc as well as the kernel.
milton
^ permalink raw reply
* Re: [PATCH] fix mace_handle_misc_intrs compilation
From: Andrew Morton @ 2007-09-24 8:22 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, netdev
In-Reply-To: <20070924081501.GA1797@aepfle.de>
On Mon, 24 Sep 2007 10:15:01 +0200 Olaf Hering <olaf@aepfle.de> wrote:
> Fix compilation after incomplete struct net_device changes.
yup, thanks, Kamalesh Babulal has already sent in an identical
patch.
^ permalink raw reply
* [PATCH] fix mace_handle_misc_intrs compilation
From: Olaf Hering @ 2007-09-24 8:15 UTC (permalink / raw)
To: Andrew Morton, linuxppc-dev, netdev
Fix compilation after incomplete struct net_device changes.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
drivers/net/mace.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/net/mace.c
+++ b/drivers/net/mace.c
@@ -633,7 +633,7 @@ static void mace_set_multicast(struct ne
spin_unlock_irqrestore(&mp->lock, flags);
}
-static void mace_handle_misc_intrs(struct mace_data *mp, int intr)
+static void mace_handle_misc_intrs(struct mace_data *mp, int intr, struct net_device *dev)
{
volatile struct mace __iomem *mb = mp->mace;
static int mace_babbles, mace_jabbers;
@@ -669,7 +669,7 @@ static irqreturn_t mace_interrupt(int ir
spin_lock_irqsave(&mp->lock, flags);
intr = in_8(&mb->ir); /* read interrupt register */
in_8(&mb->xmtrc); /* get retries */
- mace_handle_misc_intrs(mp, intr);
+ mace_handle_misc_intrs(mp, intr, dev);
i = mp->tx_empty;
while (in_8(&mb->pr) & XMTSV) {
@@ -682,7 +682,7 @@ static irqreturn_t mace_interrupt(int ir
*/
intr = in_8(&mb->ir);
if (intr != 0)
- mace_handle_misc_intrs(mp, intr);
+ mace_handle_misc_intrs(mp, intr, dev);
if (mp->tx_bad_runt) {
fs = in_8(&mb->xmtfs);
mp->tx_bad_runt = 0;
@@ -817,7 +817,7 @@ static void mace_tx_timeout(unsigned lon
goto out;
/* update various counters */
- mace_handle_misc_intrs(mp, in_8(&mb->ir));
+ mace_handle_misc_intrs(mp, in_8(&mb->ir), dev);
cp = mp->tx_cmds + NCMDS_TX * mp->tx_empty;
^ permalink raw reply
* Re: [PATCH 1/15] boot: find initrd location from device-tree
From: Milton Miller @ 2007-09-24 8:02 UTC (permalink / raw)
To: David Gibson; +Cc: ppcdev, Paul Mackerras
In-Reply-To: <20070924025824.GD8058@localhost.localdomain>
On Sep 23, 2007, at 9:58 PM, David Gibson wrote:
> On Fri, Sep 21, 2007 at 06:03:24PM -0500, Milton Miller wrote:
>> Some platforms have a boot agent that can create or modify properties
>> in
>> the device-tree and load images into memory. Provide a helper to set
>> loader_info used by prep_initrd().
>>
>> Signed-off-by: Milton Miller <miltonm@bga.com>
>> Acked-by: David Gibson <david@gibson.dropbear.id.au>
>
> Hrm, despite my earlier ack, I'm going to whinge about a few nits
> here.
>
>> ---
>> re 12168
>> rediffed types.h, offset in ops.h
>>
>> Index: kernel/arch/powerpc/boot/ops.h
>> ===================================================================
>> --- kernel.orig/arch/powerpc/boot/ops.h 2007-09-17 22:12:47.000000000
>> -0500
>> +++ kernel/arch/powerpc/boot/ops.h 2007-09-17 22:12:51.000000000 -0500
>> @@ -163,6 +163,7 @@ void dt_fixup_clock(const char *path, u3
>> void __dt_fixup_mac_addresses(u32 startindex, ...);
>> #define dt_fixup_mac_addresses(...) \
>> __dt_fixup_mac_addresses(0, __VA_ARGS__, NULL)
>> +void dt_find_initrd(void);
>>
>>
>> static inline void *find_node_by_linuxphandle(const u32 linuxphandle)
>> Index: kernel/arch/powerpc/boot/types.h
>> ===================================================================
>> --- kernel.orig/arch/powerpc/boot/types.h 2007-09-17
>> 22:12:47.000000000 -0500
>> +++ kernel/arch/powerpc/boot/types.h 2007-09-17 22:12:51.000000000
>> -0500
>> @@ -12,6 +12,8 @@ typedef short s16;
>> typedef int s32;
>> typedef long long s64;
>>
>> +#define UINT_MAX 0xFFFFFFFF
>
> I actually don't like this constant - at the point you compare you
> care, explicitly, about the value not being over 32-bits, rather than
> whether it fits a uint, so the named constant is more misleading than
> helpful.
Arguable, I don't like counting F's or zeros in C code.
It is used as the max address that the wrapper deals with, both here
and memranges, which happens to be 32 bits.
Actually it cares about overflowing the unsigned long in loader_info,
not that the address fits in 32 bits.
So it should be ULONG_MAX now (malloc and all the address code was
changed to use unsigned long instead of unsigned int since the patch
was written).
And dt_xlate needs the same information. Its is using a hardcoded 64
bit constant to provide the a simiar check.
>> +
>> #define min(x,y) ({ \
>> typeof(x) _x = (x); \
>> typeof(y) _y = (y); \
>> Index: kernel/arch/powerpc/boot/devtree.c
>> ===================================================================
>> --- kernel.orig/arch/powerpc/boot/devtree.c 2007-09-17
>> 22:12:47.000000000 -0500
>> +++ kernel/arch/powerpc/boot/devtree.c 2007-09-17 22:12:51.000000000
>> -0500
>> @@ -1,6 +1,7 @@
>> /*
>> * devtree.c - convenience functions for device tree manipulation
>> * Copyright 2007 David Gibson, IBM Corporation.
>> + * Copyright 2007 Milton Miller, IBM Corporation.
>> * Copyright (c) 2007 Freescale Semiconductor, Inc.
>> *
>> * Authors: David Gibson <david@gibson.dropbear.id.au>
>> @@ -333,3 +334,68 @@ int dt_is_compatible(void *node, const c
>>
>> return 0;
>> }
>> +
>> +/**
>> + * dt_find_initrd - set loader initrd location based on existing
>> properties
>> + *
>> + * finds the linux,initrd-start and linux,initrd-end properties in
>> + * the /chosen node and sets the loader initrd fields accordingly.
>> + *
>> + * Use this if your loader sets the properties to allow other code to
>> + * relocate the tree and/or cause r3 and r4 to be set on true OF
>> + * platforms.
>
> I am unable to make sense of the paragraph above.
The phrase "relocate the tree" should be "relocate the initrd", which
the wrapper will do if it located below vmlinux.size. Also, r3 and r4
need to be set when booting the kernel from a client interface with an
initrd so it can take it into consideration when choosing the location
to build the flat tree.
How about:
Filling in the loader info allows main.c to be aware of the initrd,
meaning prep_initrd will move the initrd if it will be overwritten when
the kernel is copied to its runtime location. In addition, if you are
booting the kernel from a client interface instead of a flat device
tree, this also causes r3 and r4 to be set so the kernel can avoid
overwriting the initrd when creating the flat tree.
>
>> + */
>> +void dt_find_initrd(void)
>> +{
>> + int rc;
>> + unsigned long long initrd_start, initrd_end;
>> + void *devp;
>> + static const char start_prop[] = "linux,initrd-start";
>> + static const char end_prop[] = "linux,initrd-end";
>
> I think these constants are more obscuring than useful.
They are useful to the extent they reduce the number of source
characters causing about 8 less line wraps. Since they are used
multiple places, the compiler only needs to emit one copy of this byte
sequence. Admitedly you made this point in a prior review.
>
>> +
>> + devp = finddevice("/chosen");
>> + if (! devp) {
>> + return;
>> + }
>
> CodingStyle would not put { } here.
Yea, nit. not sure why I have the braces there, I usually follow that
one. And what's that space doing after !?
>
>> +
>> + rc = getprop(devp, start_prop, &initrd_start, sizeof(initrd_start));
>> + if (rc < 0)
>> + return; /* not found */
>> + /* The properties had to be 8 bytes until 2.6.22 */
>> + if (rc == sizeof(unsigned long)) {
>> + unsigned long tmp;
>> + memcpy(&tmp, &initrd_start, rc);
>> + initrd_start = tmp;
>> + } else if (rc != sizeof(initrd_start)) { /* now they
>> can be 4 */
>
> Right. 8 bytes and 4 bytes, so you should be using explicit length
> types instead of long and long long.
Ok, I guess we ahve u32 and u64 in types.h now. But there is other
code in the wrapper that assumes its compiled 32 bit ILP.
>
>> + printf("unexpected length of %s in /chosen!\n\r", start_prop);
>> + return;
>
> All these printf() / return stanzas add a lot of verbosity to this
> function. Any way they can be consolidated a bit, maybe a single
> error path that just prints the property values, so the user can
> figure out what was wrong with them.
On a prior review I got asked to split the reasons for ingoring the
values below (the > 32 bit address from end < start cases). Admitedly
without all the detailed errors the justification for the string
varables is reduced.
>
>> + }
>> +
>> + rc = getprop(devp, end_prop, &initrd_end, sizeof(initrd_end));
>> + if (rc < 0) {
>> + printf("chosen has %s but no %s!\n\r", start_prop, end_prop);
>> + return;
>> + }
>> + if (rc == sizeof(unsigned long)) {
>> + unsigned long tmp;
>> + memcpy(&tmp, &initrd_end, rc);
>> + initrd_end = tmp;
>> + } else if (rc != sizeof(initrd_end)) {
>> + printf("unexpected length of %s in /chosen!\n\r", end_prop);
>> + return;
>> + }
>> +
>> + /* Check for presence, ignore if (partially) loaded above 32 bits */
>> + if (initrd_start == initrd_end) {
>> + printf("ignoring empty device-tree supplied initrd\n");
>> + } else if (initrd_start > initrd_end) {
>> + printf("ignoring device-tree supplied initrd: start 0x%llx"
>> + " > end 0x%llx \n", initrd_start, initrd_end);
>> + } else if (initrd_end > UINT_MAX) {
>> + printf("ignoring device-tree supplied initrd:"
>> + " end 0x%llx > 32 bits\n", initrd_end);
>> + } else {
>> + loader_info.initrd_addr = initrd_start;
>> + loader_info.initrd_size = initrd_end - initrd_start;
>> + }
>> +}
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>
> --
> 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/~dgibson
>
^ 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