* Re: System crash on boot_e500.S
From: Scott Wood @ 2007-08-15 16:02 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <5c9cd53b0708150657k71531bdbl848375d5d80faf21@mail.gmail.com>
On Wed, Aug 15, 2007 at 09:57:59AM -0400, mike zheng wrote:
> Did you done similar work before? Current 2.6 code need many other files, I
> have following errors when I try to use the head_e500.S from 2.6 code:
>
>
> /kernel-> powerpc-linux-gnuspe-gcc -m32 -Wp,-MD,arch/ppc/kernel/.entry.o.d
> -nostdinc -isystem /opt/mtwk/usr/local/gcc-3_4-
> e500-glibc-2.3.4-dp/powerpc-linux-gnuspe/lib/gcc/powerpc-linux-gnuspe/3.4.3/include
> -D__KERNEL__ -Iinclude -Iarch/ppc -D__ASSEMBLY__ -Iarch/ppc -Wa,-me500 -c
> -o arch/ppc/kernel/entry.o arch/ppc/kernel/entry.S
> arch/ppc/kernel/entry.S: Assembler messages:
>
> entry.S:819: Error: unsupported relocation against CSRR0
> entry.S:820: Error: unsupported relocation against CSRR1
> entry.S:888: Error: unsupported relocation against MCSRR0
> entry.S:889: Error: unsupported relocation against MCSRR1
> entry.S:909: Error: unsupported relocation against CSRR0
> entry.S:911: Error: unsupported relocation against CSRR1
Try arch/powerpc; arch/ppc is deprecated.
-Scott
^ permalink raw reply
* RE: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEXboardsupport]
From: Stephen Neuendorffer @ 2007-08-15 16:14 UTC (permalink / raw)
To: Michal Simek; +Cc: microblaze-uclinux, linuxppc-embedded
In-Reply-To: <2934.5453-20654-824518122-1187160093@seznam.cz>
I don't have an EDK script. I'm currently using a hacked version of=20
Grant's gen_mhs_devtree.py script, and then I modified the resulting
device
tree in an effort to get things working. In the long term, I think
having
an EDK script will be necessary to ensure that all of the information is
in the device tree.
Michal: what do you need from me?
Steve
> -----Original Message-----
> From: Michal Simek [mailto:Monstr@seznam.cz]=20
> Sent: Tuesday, August 14, 2007 11:42 PM
> To: Stephen Neuendorffer
> Cc: Grant Likely; microblaze-uclinux@itee.uq.edu.au;=20
> linuxppc-embedded@ozlabs.org
> Subject: RE: Device Tree tool [was RE: [PATCH] Consolidate=20
> XILINX_VIRTEXboardsupport]
>=20
> Hi,
>=20
> >I've managed to get the first step working: a microblaze system
> >advertising of_devices in 2.6 using a flat device tree. =20
>=20
> It's great news.
>=20
> >Is there a concensus on how microblaze systems should get booted?
> >Currently,
> >I'm linking the device tree directly into the kernel itself,=20
> loading the
> >whole
> >mess using SystemAce and the start address jumps directly into the
> >kernel, which
> >is quite a bit different than the way powerpc works. It's certainly
> >simpler:
> >maybe too simple. At the same time, replicating
> >the complexity of arch/powerpc with separate boot code may=20
> or may not be
> >worth it...
> >Any thoughts?
>=20
> Microblaze can be boot via U-BOOT. U-BOOT supports FDT for=20
> some PowerPC boards.
> I would like to help with this part of bootloader code.=20
>=20
> Do you have any EDK script for generation FDT?=20
>=20
> Best regards,
> Michal Simek
>=20
>=20
^ permalink raw reply
* Re: System crash on boot_e500.S on 2.4Kernel
From: Becky Bruce @ 2007-08-15 16:17 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-embedded
In-Reply-To: <5c9cd53b0708150659u2ba88a9as5055b42fb1e2be67@mail.gmail.com>
On Aug 15, 2007, at 8:59 AM, mike zheng wrote:
> I use BDI to debug these two instructions. And here are the output
> of BDI just before the "rfi". The content of R6, R7 is different
> from SRR0(SPR26) and SRR1(SPR27).
I see you have not printed the pc/nia once you stop. Are you sure
you're stopped where you think? Please check this.
-B
>
> cds8548>res run
>
> - TARGET: processing user reset request
>
> - BDI asserts HRESET
>
> - Reset JTAG controller passed
>
> - JTAG exists check passed
>
> - IDCODE is 0x0003901D
>
> - SVR is 0x80390011
>
> - PVR is 0x80210010
>
> - CCSRBAR is 0x0_ff700000
>
> - BDI removes HRESET
>
> - TARGET: Target PVR is 0x80210010
>
> - TARGET: resetting target passed
>
> cds8548>halt
>
> Target CPU : MPC85xx (e500v2 rev.1)
>
> Target state : halted
>
> Debug entry cause : COP halt
>
> Current PC : 0xfff82560
>
> Current CR : 0x88000042
>
> Current MSR : 0x00021200
>
> Current LR : 0xfff8aa4c
>
> Current CCSRBAR : 0x0_e0000000
>
> cds8548>ci
>
> cds8548>bi 0x0000015c
>
> Breakpoint identification is 0
>
> cds8548>go
>
> - TARGET: stopped
>
> cds8548>rd
>
> GPR00: 00000000 0ffabd20 00000200 00000008
>
> GPR04: 00000000 00000001 00000020 00000160
>
> GPR08: 1f8b0808 00000148 0ffabace 0ffe08b0
>
> GPR12: 00000006 764deddb 10000300 007fff00
>
> GPR16: 00000001 ffffffff 007fff25 0ffff9d8
>
> GPR20: 007ffeb0 00000000 0fffaa3c 0ffae490
>
> GPR24: 00000000 00000003 02000040 007fff25
>
> GPR28: 007fff00 0ffab3b8 0fcd6000 007ffeb0
>
> CR : 24024022 MSR: 00021200
>
> cds8548>rdspr 26
>
> SPR 26 : 0xfff81300 - 519424
>
> cds8548>rdspr 27
>
> SPR 27 : 0x00001000 4096
>
> cds8548>
>
>
>
>
>
>
> On 8/14/07, Andy Fleming <afleming@freescale.com> wrote:
> On Aug 14, 2007, at 15:21, mike zheng wrote:
>
> >
> > Hi All,
> >
> > I am trying to bring up MPC8548 CDS board on 2.4 kernel. I have
> > problem in the head_e500.S. The "mtspr SRR0, r7; mtspr SRR1 r6"
> > does not work for me. The content of R7 and R6 are not moved to
> > SRR0 and SRR1. I am using the tool-chain from Freescale for 2.6
> > kernel.
> >
> > Any idea on this issue?
>
> Just to check...how do you know it doesn't work?
>
> Andy
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: System crash on boot_e500.S
From: Kumar Gala @ 2007-08-15 16:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070815160254.GA9049@ld0162-tx32.am.freescale.net>
On Aug 15, 2007, at 11:02 AM, Scott Wood wrote:
> On Wed, Aug 15, 2007 at 09:57:59AM -0400, mike zheng wrote:
>> Did you done similar work before? Current 2.6 code need many other
>> files, I
>> have following errors when I try to use the head_e500.S from 2.6
>> code:
>>
>>
>> /kernel-> powerpc-linux-gnuspe-gcc -m32 -Wp,-MD,arch/ppc/
>> kernel/.entry.o.d
>> -nostdinc -isystem /opt/mtwk/usr/local/gcc-3_4-
>> e500-glibc-2.3.4-dp/powerpc-linux-gnuspe/lib/gcc/powerpc-linux-
>> gnuspe/3.4.3/include
>> -D__KERNEL__ -Iinclude -Iarch/ppc -D__ASSEMBLY__ -Iarch/ppc -Wa,-
>> me500 -c
>> -o arch/ppc/kernel/entry.o arch/ppc/kernel/entry.S
>> arch/ppc/kernel/entry.S: Assembler messages:
>>
>> entry.S:819: Error: unsupported relocation against CSRR0
>> entry.S:820: Error: unsupported relocation against CSRR1
>> entry.S:888: Error: unsupported relocation against MCSRR0
>> entry.S:889: Error: unsupported relocation against MCSRR1
>> entry.S:909: Error: unsupported relocation against CSRR0
>> entry.S:911: Error: unsupported relocation against CSRR1
>
> Try arch/powerpc; arch/ppc is deprecated.
He's trying a 2.4 kernel.
- k
^ permalink raw reply
* Re: System crash on boot_e500.S
From: Scott Wood @ 2007-08-15 16:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <A9A39446-A8B0-44D7-ABF4-E9918FCC2843@kernel.crashing.org>
Kumar Gala wrote:
>
> On Aug 15, 2007, at 11:02 AM, Scott Wood wrote:
>
>> On Wed, Aug 15, 2007 at 09:57:59AM -0400, mike zheng wrote:
>>
>>> Did you done similar work before? Current 2.6 code need many other
>>> files, I
>>> have following errors when I try to use the head_e500.S from 2.6 code:
>>>
>>>
>>> /kernel-> powerpc-linux-gnuspe-gcc -m32 -Wp,-MD,arch/ppc/
>>> kernel/.entry.o.d
>>> -nostdinc -isystem /opt/mtwk/usr/local/gcc-3_4-
>>> e500-glibc-2.3.4-dp/powerpc-linux-gnuspe/lib/gcc/powerpc-linux-
>>> gnuspe/3.4.3/include
>>> -D__KERNEL__ -Iinclude -Iarch/ppc -D__ASSEMBLY__ -Iarch/ppc -Wa,-
>>> me500 -c
>>> -o arch/ppc/kernel/entry.o arch/ppc/kernel/entry.S
>>> arch/ppc/kernel/entry.S: Assembler messages:
>>>
>>> entry.S:819: Error: unsupported relocation against CSRR0
>>> entry.S:820: Error: unsupported relocation against CSRR1
>>> entry.S:888: Error: unsupported relocation against MCSRR0
>>> entry.S:889: Error: unsupported relocation against MCSRR1
>>> entry.S:909: Error: unsupported relocation against CSRR0
>>> entry.S:911: Error: unsupported relocation against CSRR1
>>
>>
>> Try arch/powerpc; arch/ppc is deprecated.
>
>
> He's trying a 2.4 kernel.
Sorry, I read the above as "I tried 2.6 and head_e500.S gave me these
errors", not "I copied head_e500.S from 2.6 and for some reason expected
it to work".
-Scott
^ permalink raw reply
* Re: System crash on boot_e500.S
From: Becky Bruce @ 2007-08-15 16:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <A9A39446-A8B0-44D7-ABF4-E9918FCC2843@kernel.crashing.org>
On Aug 15, 2007, at 11:28 AM, Kumar Gala wrote:
>
> On Aug 15, 2007, at 11:02 AM, Scott Wood wrote:
>
>> On Wed, Aug 15, 2007 at 09:57:59AM -0400, mike zheng wrote:
>>> Did you done similar work before? Current 2.6 code need many other
>>> files, I
>>> have following errors when I try to use the head_e500.S from 2.6
>>> code:
>>>
>>>
>>> /kernel-> powerpc-linux-gnuspe-gcc -m32 -Wp,-MD,arch/ppc/
>>> kernel/.entry.o.d
>>> -nostdinc -isystem /opt/mtwk/usr/local/gcc-3_4-
>>> e500-glibc-2.3.4-dp/powerpc-linux-gnuspe/lib/gcc/powerpc-linux-
>>> gnuspe/3.4.3/include
>>> -D__KERNEL__ -Iinclude -Iarch/ppc -D__ASSEMBLY__ -Iarch/ppc -Wa,-
>>> me500 -c
>>> -o arch/ppc/kernel/entry.o arch/ppc/kernel/entry.S
>>> arch/ppc/kernel/entry.S: Assembler messages:
>>>
>>> entry.S:819: Error: unsupported relocation against CSRR0
>>> entry.S:820: Error: unsupported relocation against CSRR1
>>> entry.S:888: Error: unsupported relocation against MCSRR0
>>> entry.S:889: Error: unsupported relocation against MCSRR1
>>> entry.S:909: Error: unsupported relocation against CSRR0
>>> entry.S:911: Error: unsupported relocation against CSRR1
>>
>> Try arch/powerpc; arch/ppc is deprecated.
>
> He's trying a 2.4 kernel.
I think maybe he misunderstood Jon's advive to "use 2.6" as using
just some files from 2.6. I think the above is probably some strange
mix of 2.4 and 2.6, which, of course, won't work.
Jon's real advice was "use 2.6", as in, the whole thing.
-B
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC 440EPx: Sequoia DTS
From: Valentine Barshak @ 2007-08-15 16:56 UTC (permalink / raw)
To: Valentine Barshak, linuxppc-dev
In-Reply-To: <20070815034359.GA22849@localhost.localdomain>
David Gibson wrote:
> On Tue, Aug 14, 2007 at 10:48:43PM +0400, Valentine Barshak wrote:
>> AMCC Sequoia device tree.
>>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> ---
>> arch/powerpc/boot/dts/sequoia.dts | 289 ++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 289 insertions(+)
>>
>> diff -ruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts linux-2.6/arch/powerpc/boot/dts/sequoia.dts
>> --- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts 1970-01-01 03:00:00.000000000 +0300
>> +++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-08-14 19:32:56.000000000 +0400
>> @@ -0,0 +1,289 @@
>> +/*
>> + * Device Tree Source for AMCC Sequoia
>> + *
>> + * Based on Bamboo code by Josh Boyer <jwboyer@linux.vnet.ibm.com>
>> + * Copyright (c) 2006, 2007 IBM Corp.
>> + *
>> + * FIXME: Draft only!
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without
>> + * any warranty of any kind, whether express or implied.
>> + *
>> + */
>> +
>> +/ {
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + model = "amcc,sequoia";
>> + compatible = "amcc,sequoia";
>> + dcr-parent = <&/cpus/PowerPC,440EPx@0>;
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + PowerPC,440EPx@0 {
>> + device_type = "cpu";
>> + reg = <0>;
>> + clock-frequency = <0>; /* Filled in by zImage */
>> + timebase-frequency = <0>; /* Filled in by zImage */
>> + i-cache-line-size = <20>;
>> + d-cache-line-size = <20>;
>> + i-cache-size = <8000>;
>> + d-cache-size = <8000>;
>> + dcr-controller;
>> + dcr-access-method = "native";
>> + };
>> + };
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0 0 0>; /* Filled in by zImage */
>> + };
>> +
>> + UIC0: interrupt-controller0 {
>> + compatible = "ibm,uic-440epx","ibm,uic";
>> + interrupt-controller;
>> + cell-index = <0>;
>> + dcr-reg = <0c0 009>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + UIC1: interrupt-controller1 {
>> + compatible = "ibm,uic-440epx","ibm,uic";
>> + interrupt-controller;
>> + cell-index = <1>;
>> + dcr-reg = <0d0 009>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + #interrupt-cells = <2>;
>> + interrupts = <1e 4 1f 4>; /* cascade */
>> + interrupt-parent = <&UIC0>;
>> + };
>> +
>> + UIC2: interrupt-controller2 {
>> + compatible = "ibm,uic-440epx","ibm,uic";
>> + interrupt-controller;
>> + cell-index = <2>;
>> + dcr-reg = <0e0 009>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + #interrupt-cells = <2>;
>> + interrupts = <1c 4 1d 4>; /* cascade */
>> + interrupt-parent = <&UIC0>;
>> + };
>> +
>> + SDR0: sdr {
>> + compatible = "ibm,sdr-440epx", "ibm,sdr-440ep";
>
> Ok, I take it the 440EP really does have SDR and CPR devices with
> which the EPx variants are compatible?
Right.
>
>> + dcr-reg = <00e 002>;
>> + };
>> +
>> + CPR0: cpr {
>> + compatible = "ibm,cpr-440epx", "ibm,sdr-440ep";
>> + dcr-reg = <00c 002>;
>> + };
>> +
>> + plb {
>> + compatible = "ibm,plb-440epx", "ibm,plb4";
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + ranges;
>> + clock-frequency = <0>; /* Filled in by zImage */
>> +
>> + SDRAM0: sdram {
>> + device_type = "memory-controller";
>> + compatible = "ibm,sdram-44x-ddr2denali";
>
> Should have an ibm,sdram-440epx entry as well, just in case of chip
> specific bugs / workarounds.
OK
>
>> + dcr-reg = <010 2>;
>> + };
>> +
>> + DMA0: dma {
>> + compatible = "ibm,dma-440epx", "ibm,dma-4xx";
>> + dcr-reg = <100 027>;
>> + };
>> +
>> + MAL0: mcmal {
>> + compatible = "ibm,mcmal-440epx", "ibm,mcmal-440spe", "ibm,mcmal2";
>
> What's the 440spe entry about?
Will remove. No need in 440spe with the updated EMAC driver.
>
>> + dcr-reg = <180 62>;
>> + num-tx-chans = <4>;
>> + num-rx-chans = <4>;
>> + interrupt-parent = <&MAL0>;
>> + interrupts = <0 1 2 3 4>;
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
>> + /*RXEOB*/ 1 &UIC0 b 4
>> + /*SERR*/ 2 &UIC1 0 4
>> + /*TXDE*/ 3 &UIC1 1 4
>> + /*RXDE*/ 4 &UIC1 2 4>;
>> + interrupt-map-mask = <ffffffff>;
>> + };
>> +
>> + POB0: opb {
>> + compatible = "ibm,opb-440epx", "ibm,opb";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + /* Bamboo is oddball in the 44x world and doesn't use the ERPN
>> + * bits.
>> + */
>
> This incorrect and outdated comment is still here.
Sorry :)
>
>> + ranges = <00000000 1 00000000 80000000
>> + 80000000 1 80000000 80000000>;
>> + interrupt-parent = <&UIC1>;
>> + interrupts = <7 4>;
>> + clock-frequency = <0>; /* Filled in by zImage */
>> +
>> + EBC0: ebc {
>> + compatible = "ibm,ebc-440epx";
>
> Should have "ibm,ebc" too.
OK
>
>> + dcr-reg = <012 2>;
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + clock-frequency = <0>; /* Filled in by zImage */
>> + interrupts = <5 1>;
>> + interrupt-parent = <&UIC1>;
>> +
>> + nor_flash@0,0 {
>> + device_type = "rom";
>> + compatible = "direct-mapped";
>> + probe-type = "CFI";
>> + bank-width = <2>;
>> + partitions = < 0 180000
>> + 180000 200000
>> + 380000 3aa0000
>> + 3e20000 140000
>> + 3f60000 40000
>> + 3fa0000 60000>;
>> + partition-names = "Kernel", "ramdisk", "file system",
>> + "kozio", "env", "u-boot";
>> + reg = <0 000000 4000000>;
>> + };
>> +
>> + };
>> +
>> + UART0: serial@ef600300 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <ef600300 8>;
>> + virtual-reg = <ef600300>;
>> + clock-frequency = <0>; /* Filled in by zImage */
>> + current-speed = <1c200>;
>> + interrupt-parent = <&UIC0>;
>> + interrupts = <0 4>;
>> + };
>> +
>> + UART1: serial@ef600400 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <ef600400 8>;
>> + virtual-reg = <ef600400>;
>> + clock-frequency = <0>;
>> + current-speed = <0>;
>> + interrupt-parent = <&UIC0>;
>> + interrupts = <1 4>;
>> + };
>> +
>> + UART2: serial@ef600500 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <ef600500 8>;
>> + virtual-reg = <ef600500>;
>> + clock-frequency = <0>;
>> + current-speed = <0>;
>> + interrupt-parent = <&UIC1>;
>> + interrupts = <3 4>;
>> + };
>> +
>> + UART3: serial@ef600600 {
>> + device_type = "serial";
>> + compatible = "ns16550";
>> + reg = <ef600600 8>;
>> + virtual-reg = <ef600600>;
>> + clock-frequency = <0>;
>> + current-speed = <0>;
>> + interrupt-parent = <&UIC1>;
>> + interrupts = <4 4>;
>> + };
>> +
>> + IIC0: i2c@ef600700 {
>> + device_type = "i2c";
>> + compatible = "ibm,iic-440epx", "ibm,iic";
>> + reg = <ef600700 14>;
>> + interrupt-parent = <&UIC0>;
>> + interrupts = <2 4>;
>> + };
>> +
>> + IIC1: i2c@ef600800 {
>> + device_type = "i2c";
>> + compatible = "ibm,iic-440epx", "ibm,iic";
>> + reg = <ef600800 14>;
>> + interrupt-parent = <&UIC0>;
>> + interrupts = <7 4>;
>> + };
>> +
>> + ZMII0: emac-zmii@ef600d00 {
>> + device_type = "zmii-interface";
>> + compatible = "ibm,zmii-440epx", "ibm,zmii";
>> + reg = <ef600d00 c>;
>> + };
>> +
>> + EMAC0: ethernet@ef600e00 {
>> + linux,network-index = <0>;
>> + device_type = "network";
>> + compatible = "ibm,emac-440epx", "ibm,emac-440spe", "ibm,emac4";
>
> Again what's the ibm,emac-440spe about?
It's about to be removed from here :)
>
>> + interrupt-parent = <&EMAC0>;
>> + interrupts = <0 1>;
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = </*Status*/ 0 &UIC0 18 4
>> + /*Wake*/ 1 &UIC1 1d 4>;
>> + reg = <ef600e00 70>;
>> + local-mac-address = [000000000000];
>> + mal-device = <&MAL0>;
>> + mal-tx-channel = <0 1>;
>> + mal-rx-channel = <0>;
>> + cell-index = <0>;
>> + max-frame-size = <5dc>;
>> + rx-fifo-size = <1000>;
>> + tx-fifo-size = <800>;
>> + phy-mode = "rmii";
>> + phy-map = <00000000>;
>> + zmii-device = <&ZMII0>;
>> + zmii-channel = <0>;
>> + };
>> +
>> + EMAC1: ethernet@ef600f00 {
>> + linux,network-index = <1>;
>> + device_type = "network";
>> + compatible = "ibm,emac-440epx", "ibm,emac-440spe", "ibm,emac4";
>> + interrupt-parent = <&EMAC1>;
>> + interrupts = <0 1>;
>> + #interrupt-cells = <1>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>> + interrupt-map = </*Status*/ 0 &UIC0 19 4
>> + /*Wake*/ 1 &UIC1 1f 4>;
>> + reg = <ef600f00 70>;
>> + local-mac-address = [000000000000];
>> + mal-device = <&MAL0>;
>> + mal-tx-channel = <2 3>;
>> + mal-rx-channel = <1>;
>> + cell-index = <1>;
>> + max-frame-size = <5dc>;
>> + rx-fifo-size = <1000>;
>> + tx-fifo-size = <800>;
>> + phy-mode = "rmii";
>> + phy-map = <00000000>;
>> + zmii-device = <&ZMII0>;
>> + zmii-channel = <1>;
>> + };
>> + };
>> + };
>> +
>> + chosen {
>> + linux,stdout-path = "/plb/opb/serial@ef600300";
>> + bootargs = "console=ttyS0,115200";
>> + };
>> +};
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC 440EPx: Sequoia bootwrapper
From: Jerone Young @ 2007-08-15 17:37 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070814185355.GA12472@ru.mvista.com>
What source tree patch based on? The latest kernel.org git tree does not
have arch/powerpc/boot/4xx.c or arch/powerpc/boot/4xx.h . This patch is
attempting to patch these files.
On Tue, 2007-08-14 at 22:53 +0400, Valentine Barshak wrote:
> Bootwrapper code for AMCC 440EPx Sequoia board.
> The DDR2 Denali controller support has been moved to
> arch/powerpc/boot/4xx.c
> The code also uses 440EP clocking fixups
> initially provided for 440EP Bamboo.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> arch/powerpc/boot/44x.h | 1
> arch/powerpc/boot/4xx.c | 108 +++++++++++++++++++++++++++++++++++++
> arch/powerpc/boot/4xx.h | 1
> arch/powerpc/boot/Makefile | 6 +-
> arch/powerpc/boot/cuboot-sequoia.c | 31 ++++++++++
> arch/powerpc/boot/sequoia.c | 48 ++++++++++++++++
> 6 files changed, 193 insertions(+), 2 deletions(-)
>
> diff -ruN linux-2.6.orig/arch/powerpc/boot/44x.h linux-2.6/arch/powerpc/boot/44x.h
> --- linux-2.6.orig/arch/powerpc/boot/44x.h 2007-08-14 17:11:16.000000000 +0400
> +++ linux-2.6/arch/powerpc/boot/44x.h 2007-08-14 17:25:37.000000000 +0400
> @@ -12,5 +12,6 @@
>
> void ebony_init(void *mac0, void *mac1);
> void bamboo_init(void);
> +void sequoia_init(void *mac0, void *mac1);
>
> #endif /* _PPC_BOOT_44X_H_ */
> diff -ruN linux-2.6.orig/arch/powerpc/boot/4xx.c linux-2.6/arch/powerpc/boot/4xx.c
> --- linux-2.6.orig/arch/powerpc/boot/4xx.c 2007-08-14 17:11:16.000000000 +0400
> +++ linux-2.6/arch/powerpc/boot/4xx.c 2007-08-14 20:16:57.000000000 +0400
> @@ -39,6 +39,114 @@
> dt_fixup_memory(0, memsize);
> }
>
> +/* 4xx DDR1/2 Denali memory controller support */
> +/* DDR0 registers */
> +#define DDR0_02 2
> +#define DDR0_08 8
> +#define DDR0_10 10
> +#define DDR0_14 14
> +#define DDR0_42 42
> +#define DDR0_43 43
> +
> +/* DDR0_02 */
> +#define DDR_START 0x1
> +#define DDR_START_SHIFT 0
> +#define DDR_MAX_CS_REG 0x3
> +#define DDR_MAX_CS_REG_SHIFT 24
> +#define DDR_MAX_COL_REG 0xf
> +#define DDR_MAX_COL_REG_SHIFT 16
> +#define DDR_MAX_ROW_REG 0xf
> +#define DDR_MAX_ROW_REG_SHIFT 8
> +/* DDR0_08 */
> +#define DDR_DDR2_MODE 0x1
> +#define DDR_DDR2_MODE_SHIFT 0
> +/* DDR0_10 */
> +#define DDR_CS_MAP 0x3
> +#define DDR_CS_MAP_SHIFT 8
> +/* DDR0_14 */
> +#define DDR_REDUC 0x1
> +#define DDR_REDUC_SHIFT 16
> +/* DDR0_42 */
> +#define DDR_APIN 0x7
> +#define DDR_APIN_SHIFT 24
> +/* DDR0_43 */
> +#define DDR_COL_SZ 0x7
> +#define DDR_COL_SZ_SHIFT 8
> +#define DDR_BANK8 0x1
> +#define DDR_BANK8_SHIFT 0
> +
> +#define DDR_GET_VAL(val, mask, shift) (((val) >> (shift)) & (mask))
> +
> +static inline u32 mfdcr_sdram0(u32 reg)
> +{
> + mtdcr(DCRN_SDRAM0_CFGADDR, reg);
> + return mfdcr(DCRN_SDRAM0_CFGDATA);
> +}
> +
> +void ibm4xx_denali_fixup_memsize(void)
> +{
> + u32 val, max_cs, max_col, max_row;
> + u32 cs, col, row, bank, dpath;
> + unsigned long memsize;
> +
> + val = mfdcr_sdram0(DDR0_02);
> + if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
> + fatal("DDR controller is not initialized\n");
> +
> + /* get maximum cs col and row values */
> + max_cs = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
> + max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
> + max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
> +
> + /* get CS value */
> + val = mfdcr_sdram0(DDR0_10);
> +
> + val = DDR_GET_VAL(val, DDR_CS_MAP, DDR_CS_MAP_SHIFT);
> + cs = 0;
> + while (val) {
> + if (val && 0x1)
> + cs++;
> + val = val >> 1;
> + }
> +
> + if (!cs)
> + fatal("No memory installed\n");
> + if (cs > max_cs)
> + fatal("DDR wrong CS configuration\n");
> +
> + /* get data path bytes */
> + val = mfdcr_sdram0(DDR0_14);
> +
> + if (DDR_GET_VAL(val, DDR_REDUC, DDR_REDUC_SHIFT))
> + dpath = 8; /* 64 bits */
> + else
> + dpath = 4; /* 32 bits */
> +
> + /* get adress pins (rows) */
> + val = mfdcr_sdram0(DDR0_42);
> +
> + row = DDR_GET_VAL(val, DDR_APIN, DDR_APIN_SHIFT);
> + if (row > max_row)
> + fatal("DDR wrong APIN configuration\n");
> + row = max_row - row;
> +
> + /* get collomn size and banks */
> + val = mfdcr_sdram0(DDR0_43);
> +
> + col = DDR_GET_VAL(val, DDR_COL_SZ, DDR_COL_SZ_SHIFT);
> + if (col > max_col)
> + fatal("DDR wrong COL configuration\n");
> + col = max_col - col;
> +
> + if (DDR_GET_VAL(val, DDR_BANK8, DDR_BANK8_SHIFT))
> + bank = 8; /* 8 banks */
> + else
> + bank = 4; /* 4 banks */
> +
> + memsize = cs * (1 << (col+row)) * bank * dpath;
> + dt_fixup_memory(0, memsize);
> +}
> +
> #define DBCR0_RST_SYSTEM 0x30000000
>
> void ibm44x_dbcr_reset(void)
> diff -ruN linux-2.6.orig/arch/powerpc/boot/4xx.h linux-2.6/arch/powerpc/boot/4xx.h
> --- linux-2.6.orig/arch/powerpc/boot/4xx.h 2007-08-14 17:11:16.000000000 +0400
> +++ linux-2.6/arch/powerpc/boot/4xx.h 2007-08-14 20:24:22.000000000 +0400
> @@ -12,6 +12,7 @@
> #define _POWERPC_BOOT_4XX_H_
>
> void ibm4xx_fixup_memsize(void);
> +void ibm4xx_denali_fixup_memsize(void);
> void ibm44x_dbcr_reset(void);
> void ibm40x_dbcr_reset(void);
> void ibm4xx_quiesce_eth(u32 *emac0, u32 *emac1);
> diff -ruN linux-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c linux-2.6/arch/powerpc/boot/cuboot-sequoia.c
> --- linux-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c 1970-01-01 03:00:00.000000000 +0300
> +++ linux-2.6/arch/powerpc/boot/cuboot-sequoia.c 2007-08-14 17:25:37.000000000 +0400
> @@ -0,0 +1,31 @@
> +/*
> + * Old U-boot compatibility for Sequoia
> + *
> + * Based on Ebony code by David Gibson <david@gibson.dropbear.id.au>
> + *
> + * Copyright 2007 David Gibson, IBM Corporatio.
> + * Based on cuboot-83xx.c, which is:
> + * Copyright (c) 2007 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> + * by the Free Software Foundation.
> + */
> +
> +#include "ops.h"
> +#include "stdio.h"
> +#include "44x.h"
> +#include "cuboot.h"
> +
> +#define TARGET_4xx
> +#define TARGET_44x
> +#include "ppcboot.h"
> +
> +static bd_t bd;
> +
> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> + unsigned long r6, unsigned long r7)
> +{
> + CUBOOT_INIT();
> + sequoia_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
> +}
> diff -ruN linux-2.6.orig/arch/powerpc/boot/Makefile linux-2.6/arch/powerpc/boot/Makefile
> --- linux-2.6.orig/arch/powerpc/boot/Makefile 2007-08-14 17:11:16.000000000 +0400
> +++ linux-2.6/arch/powerpc/boot/Makefile 2007-08-14 17:25:38.000000000 +0400
> @@ -44,10 +44,11 @@
> src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
> ns16550.c serial.c simple_alloc.c div64.S util.S \
> gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
> - 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c
> + 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
> + sequoia.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
> + ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-sequoia.c
> src-boot := $(src-wlib) $(src-plat) empty.c
>
> src-boot := $(addprefix $(obj)/, $(src-boot))
> @@ -143,6 +144,7 @@
> image-$(CONFIG_PPC_85xx) += cuImage.85xx
> image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
> image-$(CONFIG_BAMBOO) += treeImage.bamboo
> +image-$(CONFIG_SEQUOIA) += cuImage.sequoia
> endif
>
> # For 32-bit powermacs, build the COFF and miboot images
> diff -ruN linux-2.6.orig/arch/powerpc/boot/sequoia.c linux-2.6/arch/powerpc/boot/sequoia.c
> --- linux-2.6.orig/arch/powerpc/boot/sequoia.c 1970-01-01 03:00:00.000000000 +0300
> +++ linux-2.6/arch/powerpc/boot/sequoia.c 2007-08-14 20:52:10.000000000 +0400
> @@ -0,0 +1,48 @@
> +/*
> + * Valentine Barshak <vbarshak@ru.mvista.com>
> + * Copyright 2007 MontaVista Software, Inc
> + *
> + * Based on Bamboo code by Josh Boyer <jwboyer@linux.vnet.ibm.com>
> + * Copyright IBM Corporation, 2007
> + *
> + * This program 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; version 2 of the License
> + */
> +#include <stdarg.h>
> +#include <stddef.h>
> +#include "types.h"
> +#include "elf.h"
> +#include "string.h"
> +#include "stdio.h"
> +#include "page.h"
> +#include "ops.h"
> +#include "dcr.h"
> +#include "4xx.h"
> +#include "44x.h"
> +
> +extern char _dtb_start[];
> +extern char _dtb_end[];
> +
> +static u8 *sequoia_mac0, *sequoia_mac1;
> +
> +
> +static void sequoia_fixups(void)
> +{
> + unsigned long sysclk = 33333333;
> +
> + ibm440ep_fixup_clocks(sysclk, 11059200);
> + ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> + ibm4xx_denali_fixup_memsize();
> + dt_fixup_mac_addresses(sequoia_mac0, sequoia_mac1);
> +}
> +
> +void sequoia_init(void *mac0, void *mac1)
> +{
> + platform_ops.fixups = sequoia_fixups;
> + platform_ops.exit = ibm44x_dbcr_reset;
> + sequoia_mac0 = mac0;
> + sequoia_mac1 = mac1;
> + ft_init(_dtb_start, 0, 32);
> + serial_console_init();
> +}
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC 440EPx: Sequoia bootwrapper
From: Valentine Barshak @ 2007-08-15 18:23 UTC (permalink / raw)
To: jyoung5; +Cc: linuxppc-dev
In-Reply-To: <1187199465.7628.5.camel@laptop>
The patches are based mainly on the Bamboo board support by Josh Boyer
and should be applied on top of the "[patch 00/10] 4xx patch series for
2.6.24"
http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040512.html
The 2.6.24 4xx patch series is included in the following git tree:
git://git.infradead.org/users/jwboyer/powerpc.git
Please, take a look at the first message of the thread.
Thanks,
Valentine.
Jerone Young wrote:
> What source tree patch based on? The latest kernel.org git tree does not
> have arch/powerpc/boot/4xx.c or arch/powerpc/boot/4xx.h . This patch is
> attempting to patch these files.
>
> On Tue, 2007-08-14 at 22:53 +0400, Valentine Barshak wrote:
>> Bootwrapper code for AMCC 440EPx Sequoia board.
>> The DDR2 Denali controller support has been moved to
>> arch/powerpc/boot/4xx.c
>> The code also uses 440EP clocking fixups
>> initially provided for 440EP Bamboo.
>>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> ---
>> arch/powerpc/boot/44x.h | 1
>> arch/powerpc/boot/4xx.c | 108 +++++++++++++++++++++++++++++++++++++
>> arch/powerpc/boot/4xx.h | 1
>> arch/powerpc/boot/Makefile | 6 +-
>> arch/powerpc/boot/cuboot-sequoia.c | 31 ++++++++++
>> arch/powerpc/boot/sequoia.c | 48 ++++++++++++++++
>> 6 files changed, 193 insertions(+), 2 deletions(-)
>>
>> diff -ruN linux-2.6.orig/arch/powerpc/boot/44x.h linux-2.6/arch/powerpc/boot/44x.h
>> --- linux-2.6.orig/arch/powerpc/boot/44x.h 2007-08-14 17:11:16.000000000 +0400
>> +++ linux-2.6/arch/powerpc/boot/44x.h 2007-08-14 17:25:37.000000000 +0400
>> @@ -12,5 +12,6 @@
>>
>> void ebony_init(void *mac0, void *mac1);
>> void bamboo_init(void);
>> +void sequoia_init(void *mac0, void *mac1);
>>
>> #endif /* _PPC_BOOT_44X_H_ */
>> diff -ruN linux-2.6.orig/arch/powerpc/boot/4xx.c linux-2.6/arch/powerpc/boot/4xx.c
>> --- linux-2.6.orig/arch/powerpc/boot/4xx.c 2007-08-14 17:11:16.000000000 +0400
>> +++ linux-2.6/arch/powerpc/boot/4xx.c 2007-08-14 20:16:57.000000000 +0400
>> @@ -39,6 +39,114 @@
>> dt_fixup_memory(0, memsize);
>> }
>>
>> +/* 4xx DDR1/2 Denali memory controller support */
>> +/* DDR0 registers */
>> +#define DDR0_02 2
>> +#define DDR0_08 8
>> +#define DDR0_10 10
>> +#define DDR0_14 14
>> +#define DDR0_42 42
>> +#define DDR0_43 43
>> +
>> +/* DDR0_02 */
>> +#define DDR_START 0x1
>> +#define DDR_START_SHIFT 0
>> +#define DDR_MAX_CS_REG 0x3
>> +#define DDR_MAX_CS_REG_SHIFT 24
>> +#define DDR_MAX_COL_REG 0xf
>> +#define DDR_MAX_COL_REG_SHIFT 16
>> +#define DDR_MAX_ROW_REG 0xf
>> +#define DDR_MAX_ROW_REG_SHIFT 8
>> +/* DDR0_08 */
>> +#define DDR_DDR2_MODE 0x1
>> +#define DDR_DDR2_MODE_SHIFT 0
>> +/* DDR0_10 */
>> +#define DDR_CS_MAP 0x3
>> +#define DDR_CS_MAP_SHIFT 8
>> +/* DDR0_14 */
>> +#define DDR_REDUC 0x1
>> +#define DDR_REDUC_SHIFT 16
>> +/* DDR0_42 */
>> +#define DDR_APIN 0x7
>> +#define DDR_APIN_SHIFT 24
>> +/* DDR0_43 */
>> +#define DDR_COL_SZ 0x7
>> +#define DDR_COL_SZ_SHIFT 8
>> +#define DDR_BANK8 0x1
>> +#define DDR_BANK8_SHIFT 0
>> +
>> +#define DDR_GET_VAL(val, mask, shift) (((val) >> (shift)) & (mask))
>> +
>> +static inline u32 mfdcr_sdram0(u32 reg)
>> +{
>> + mtdcr(DCRN_SDRAM0_CFGADDR, reg);
>> + return mfdcr(DCRN_SDRAM0_CFGDATA);
>> +}
>> +
>> +void ibm4xx_denali_fixup_memsize(void)
>> +{
>> + u32 val, max_cs, max_col, max_row;
>> + u32 cs, col, row, bank, dpath;
>> + unsigned long memsize;
>> +
>> + val = mfdcr_sdram0(DDR0_02);
>> + if (!DDR_GET_VAL(val, DDR_START, DDR_START_SHIFT))
>> + fatal("DDR controller is not initialized\n");
>> +
>> + /* get maximum cs col and row values */
>> + max_cs = DDR_GET_VAL(val, DDR_MAX_CS_REG, DDR_MAX_CS_REG_SHIFT);
>> + max_col = DDR_GET_VAL(val, DDR_MAX_COL_REG, DDR_MAX_COL_REG_SHIFT);
>> + max_row = DDR_GET_VAL(val, DDR_MAX_ROW_REG, DDR_MAX_ROW_REG_SHIFT);
>> +
>> + /* get CS value */
>> + val = mfdcr_sdram0(DDR0_10);
>> +
>> + val = DDR_GET_VAL(val, DDR_CS_MAP, DDR_CS_MAP_SHIFT);
>> + cs = 0;
>> + while (val) {
>> + if (val && 0x1)
>> + cs++;
>> + val = val >> 1;
>> + }
>> +
>> + if (!cs)
>> + fatal("No memory installed\n");
>> + if (cs > max_cs)
>> + fatal("DDR wrong CS configuration\n");
>> +
>> + /* get data path bytes */
>> + val = mfdcr_sdram0(DDR0_14);
>> +
>> + if (DDR_GET_VAL(val, DDR_REDUC, DDR_REDUC_SHIFT))
>> + dpath = 8; /* 64 bits */
>> + else
>> + dpath = 4; /* 32 bits */
>> +
>> + /* get adress pins (rows) */
>> + val = mfdcr_sdram0(DDR0_42);
>> +
>> + row = DDR_GET_VAL(val, DDR_APIN, DDR_APIN_SHIFT);
>> + if (row > max_row)
>> + fatal("DDR wrong APIN configuration\n");
>> + row = max_row - row;
>> +
>> + /* get collomn size and banks */
>> + val = mfdcr_sdram0(DDR0_43);
>> +
>> + col = DDR_GET_VAL(val, DDR_COL_SZ, DDR_COL_SZ_SHIFT);
>> + if (col > max_col)
>> + fatal("DDR wrong COL configuration\n");
>> + col = max_col - col;
>> +
>> + if (DDR_GET_VAL(val, DDR_BANK8, DDR_BANK8_SHIFT))
>> + bank = 8; /* 8 banks */
>> + else
>> + bank = 4; /* 4 banks */
>> +
>> + memsize = cs * (1 << (col+row)) * bank * dpath;
>> + dt_fixup_memory(0, memsize);
>> +}
>> +
>> #define DBCR0_RST_SYSTEM 0x30000000
>>
>> void ibm44x_dbcr_reset(void)
>> diff -ruN linux-2.6.orig/arch/powerpc/boot/4xx.h linux-2.6/arch/powerpc/boot/4xx.h
>> --- linux-2.6.orig/arch/powerpc/boot/4xx.h 2007-08-14 17:11:16.000000000 +0400
>> +++ linux-2.6/arch/powerpc/boot/4xx.h 2007-08-14 20:24:22.000000000 +0400
>> @@ -12,6 +12,7 @@
>> #define _POWERPC_BOOT_4XX_H_
>>
>> void ibm4xx_fixup_memsize(void);
>> +void ibm4xx_denali_fixup_memsize(void);
>> void ibm44x_dbcr_reset(void);
>> void ibm40x_dbcr_reset(void);
>> void ibm4xx_quiesce_eth(u32 *emac0, u32 *emac1);
>> diff -ruN linux-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c linux-2.6/arch/powerpc/boot/cuboot-sequoia.c
>> --- linux-2.6.orig/arch/powerpc/boot/cuboot-sequoia.c 1970-01-01 03:00:00.000000000 +0300
>> +++ linux-2.6/arch/powerpc/boot/cuboot-sequoia.c 2007-08-14 17:25:37.000000000 +0400
>> @@ -0,0 +1,31 @@
>> +/*
>> + * Old U-boot compatibility for Sequoia
>> + *
>> + * Based on Ebony code by David Gibson <david@gibson.dropbear.id.au>
>> + *
>> + * Copyright 2007 David Gibson, IBM Corporatio.
>> + * Based on cuboot-83xx.c, which is:
>> + * Copyright (c) 2007 Freescale Semiconductor, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published
>> + * by the Free Software Foundation.
>> + */
>> +
>> +#include "ops.h"
>> +#include "stdio.h"
>> +#include "44x.h"
>> +#include "cuboot.h"
>> +
>> +#define TARGET_4xx
>> +#define TARGET_44x
>> +#include "ppcboot.h"
>> +
>> +static bd_t bd;
>> +
>> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
>> + unsigned long r6, unsigned long r7)
>> +{
>> + CUBOOT_INIT();
>> + sequoia_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
>> +}
>> diff -ruN linux-2.6.orig/arch/powerpc/boot/Makefile linux-2.6/arch/powerpc/boot/Makefile
>> --- linux-2.6.orig/arch/powerpc/boot/Makefile 2007-08-14 17:11:16.000000000 +0400
>> +++ linux-2.6/arch/powerpc/boot/Makefile 2007-08-14 17:25:38.000000000 +0400
>> @@ -44,10 +44,11 @@
>> src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
>> ns16550.c serial.c simple_alloc.c div64.S util.S \
>> gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
>> - 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c
>> + 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
>> + sequoia.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
>> + ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-sequoia.c
>> src-boot := $(src-wlib) $(src-plat) empty.c
>>
>> src-boot := $(addprefix $(obj)/, $(src-boot))
>> @@ -143,6 +144,7 @@
>> image-$(CONFIG_PPC_85xx) += cuImage.85xx
>> image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
>> image-$(CONFIG_BAMBOO) += treeImage.bamboo
>> +image-$(CONFIG_SEQUOIA) += cuImage.sequoia
>> endif
>>
>> # For 32-bit powermacs, build the COFF and miboot images
>> diff -ruN linux-2.6.orig/arch/powerpc/boot/sequoia.c linux-2.6/arch/powerpc/boot/sequoia.c
>> --- linux-2.6.orig/arch/powerpc/boot/sequoia.c 1970-01-01 03:00:00.000000000 +0300
>> +++ linux-2.6/arch/powerpc/boot/sequoia.c 2007-08-14 20:52:10.000000000 +0400
>> @@ -0,0 +1,48 @@
>> +/*
>> + * Valentine Barshak <vbarshak@ru.mvista.com>
>> + * Copyright 2007 MontaVista Software, Inc
>> + *
>> + * Based on Bamboo code by Josh Boyer <jwboyer@linux.vnet.ibm.com>
>> + * Copyright IBM Corporation, 2007
>> + *
>> + * This program 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; version 2 of the License
>> + */
>> +#include <stdarg.h>
>> +#include <stddef.h>
>> +#include "types.h"
>> +#include "elf.h"
>> +#include "string.h"
>> +#include "stdio.h"
>> +#include "page.h"
>> +#include "ops.h"
>> +#include "dcr.h"
>> +#include "4xx.h"
>> +#include "44x.h"
>> +
>> +extern char _dtb_start[];
>> +extern char _dtb_end[];
>> +
>> +static u8 *sequoia_mac0, *sequoia_mac1;
>> +
>> +
>> +static void sequoia_fixups(void)
>> +{
>> + unsigned long sysclk = 33333333;
>> +
>> + ibm440ep_fixup_clocks(sysclk, 11059200);
>> + ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
>> + ibm4xx_denali_fixup_memsize();
>> + dt_fixup_mac_addresses(sequoia_mac0, sequoia_mac1);
>> +}
>> +
>> +void sequoia_init(void *mac0, void *mac1)
>> +{
>> + platform_ops.fixups = sequoia_fixups;
>> + platform_ops.exit = ibm44x_dbcr_reset;
>> + sequoia_mac0 = mac0;
>> + sequoia_mac1 = mac1;
>> + ft_init(_dtb_start, 0, 32);
>> + serial_console_init();
>> +}
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH 4/4] PowerPC 440EPx: Sequoia board support
From: Josh Boyer @ 2007-08-15 18:43 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <46C3053C.10108@ru.mvista.com>
On Wed, 15 Aug 2007 17:53:00 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> David Gibson wrote:
> >> diff -ruN linux-2.6.orig/arch/powerpc/kernel/head_44x.S linux-2.6/arch/powerpc/kernel/head_44x.S
> >> --- linux-2.6.orig/arch/powerpc/kernel/head_44x.S 2007-08-14 17:11:19.000000000 +0400
> >> +++ linux-2.6/arch/powerpc/kernel/head_44x.S 2007-08-14 17:18:43.000000000 +0400
> >> @@ -217,7 +217,7 @@
> >> lis r4,interrupt_base@h /* IVPR only uses the high 16-bits */
> >> mtspr SPRN_IVPR,r4
> >>
> >> -#ifdef CONFIG_440EP
> >> +#if defined(CONFIG_440EP) || defined(CONFIG_440EPX)
> >
> > Since we should now be able to support both 440GP and 440EP boards in
> > the same kernel, this probably needs to become a feature section.
> >
>
> Thanks for pointing that out.
> Talking about this, there appears to be more stuff that would need to
> become feature sections. There're lots of other ifdefs in
> arch/powerpc/kernel/head_44x.S, like ifdef CONFIG_PPC_FPU or ifdef
> CONFIG_440A
> Looks like all these things have to be detected dynamically and
> configured properly at runtime since we tend to support more than one
> CPU in the same kernel.
Yes, definitely. It's on my TODO list. The "multiplatformness" of 44x
at the moment needs work.
> I think this should come as a separate patch, that replaces all these
> ifdefs with the FTR_SECTION stuff.
I agree. I'd like to do this as a separate patch later rather than hold
up Sequoia at the moment.
josh
^ permalink raw reply
* Re: [PATCH] [ML403-AC97CR] Fix (device/driver) name registered with platform bus
From: Joachim Foerster @ 2007-08-15 18:45 UTC (permalink / raw)
To: Takashi Iwai
Cc: alsa-devel, Lorenz Kolb, Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <1186849433.20835.33.camel@localhost>
Hi all,
below, you'll find a very small patch: In the current state, platform
bus _never_ activates (= calls probe() callback on) the driver, because
the driver's name has a dash and the device's name has an underscore. I
made this horrible change _after_ I tested the final patch, which I
posted on Saturday. Sorry.
From: Joachim Foerster <JOFT@gmx.de>
Names inside struct platform_device and struct platform_driver seem to
need underscores instead of dashes.
(Patch for Linus' master branch, date 2007/08/08 _including_ my patches
sent on Saturday)
Signed-off-by: Joachim Foerster <JOFT@gmx.de>
---
arch/ppc/syslib/virtex_devices.c | 2 +-
sound/drivers/ml403-ac97cr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
index d0b04d6..9fa10b1 100644
--- a/arch/ppc/syslib/virtex_devices.c
+++ b/arch/ppc/syslib/virtex_devices.c
@@ -122,7 +122,7 @@
}
#define XPAR_AC97_CONTROLLER_REFERENCE(num) { \
- .name = "ml403-ac97cr", \
+ .name = "ml403_ac97cr", \
.id = num, \
.num_resources = 3, \
.resource = (struct resource[]) { \
diff --git a/sound/drivers/ml403-ac97cr.c b/sound/drivers/ml403-ac97cr.c
index 2222315..2636249 100644
--- a/sound/drivers/ml403-ac97cr.c
+++ b/sound/drivers/ml403-ac97cr.c
@@ -66,7 +66,7 @@
#include "pcm-indirect2.h"
-#define SND_ML403_AC97CR_DRIVER "ml403-ac97cr"
+#define SND_ML403_AC97CR_DRIVER "ml403_ac97cr"
MODULE_AUTHOR("Joachim Foerster <JOFT@gmx.de>");
MODULE_DESCRIPTION("Xilinx ML403 AC97 Controller Reference");
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH 1/3] Fix setting of irq trigger type in UIC driver
From: Josh Boyer @ 2007-08-15 19:13 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070814035242.8EED6DDEF4@ozlabs.org>
On Tue, 14 Aug 2007 13:52:42 +1000 (EST)
David Gibson <david@gibson.dropbear.id.au> wrote:
> The UIC (interrupt controller in 4xx embedded CPUs) driver currently
> missets the IRQ_lEVEL flag in desc->status, due to a thinko. This
> patch fixes the bug.
>
> Currently this is only a cosmetic problem (affects the output in
> /proc/interrupts), however subsequent patches will use the IRQ_LEVEL
> flag to affect flow handling.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
josh
^ permalink raw reply
* Re: [PATCH 2/3] Fix irq flow handler for 4xx UIC
From: Josh Boyer @ 2007-08-15 19:13 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070814035242.9674EDDEF0@ozlabs.org>
On Tue, 14 Aug 2007 13:52:42 +1000 (EST)
David Gibson <david@gibson.dropbear.id.au> wrote:
> At present the driver for the UIC (the embedded interrupt controller
> in 4xx chips) uses the handle_level_irq() flow handler. It turns out
> this does not correctly handle level triggered interrupts on the UIC.
>
> Specifically, acknowledging an irq on the UIC (i.e. clearing the
> relevant bit in UIC_SR) will have no effect for a level interrupt
> which is still asserted by the external device, even if the irq is
> already masked. Therefore, unlike handle_level_irq() we must ack the
> interrupt after invoking the ISR (which should cause the device to
> stop asserting the irq) instead of acking it when we mask it, before
> the ISR.
>
> This patch implements this change, in a new handle_uic_irq(), a
> customised irq flow handler for the UIC. For edge triggered
> interrupts, handle_uic_irq() still uses the old flow - we must ack
> edge triggered interrupt before the ISR not after, or we could miss a
> second event which occurred between invoking the ISR and acking the
> irq.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
josh
^ permalink raw reply
* Re: [PATCH] powerpc: fix i2c device string format
From: Guennadi Liakhovetski @ 2007-08-15 19:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18114.39893.913684.592560@cargo.ozlabs.ibm.com>
Use strlcpy() to guarantee strings in i2c device type and driver_name
fields are 0-terminated.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
On Wed, 15 Aug 2007, Paul Mackerras wrote:
> That's not a commit message I can use. Please repost with an
> informative commit message that says what the motivation for the
> change is, plus anything other information that would be useful for
> someone looking at this in a couple of years' time.
Sure, sorry. This should be fine - below "---" I may write whatever I
want:-)
Thanks
Guennadi
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 727453d..c0d66df 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -320,21 +320,26 @@ static struct i2c_driver_device i2c_devices[] __initdata = {
{"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",},
};
-static int __init of_find_i2c_driver(struct device_node *node, struct i2c_board_info *info)
+static int __init of_find_i2c_driver(struct device_node *node,
+ struct i2c_board_info *info)
{
int i;
for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
if (!of_device_is_compatible(node, i2c_devices[i].of_device))
continue;
- strncpy(info->driver_name, i2c_devices[i].i2c_driver, KOBJ_NAME_LEN);
- strncpy(info->type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
+ if (strlcpy(info->driver_name, i2c_devices[i].i2c_driver,
+ KOBJ_NAME_LEN) >= KOBJ_NAME_LEN ||
+ strlcpy(info->type, i2c_devices[i].i2c_type,
+ I2C_NAME_SIZE) >= I2C_NAME_SIZE)
+ return -ENOMEM;
return 0;
}
return -ENODEV;
}
-static void __init of_register_i2c_devices(struct device_node *adap_node, int bus_num)
+static void __init of_register_i2c_devices(struct device_node *adap_node,
+ int bus_num)
{
struct device_node *node = NULL;
^ permalink raw reply related
* Re: [PATCH 3/3] Improve robustness of the UIC cascade handler
From: Josh Boyer @ 2007-08-15 19:25 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070814035242.CAE2BDDEFD@ozlabs.org>
On Tue, 14 Aug 2007 13:52:42 +1000 (EST)
David Gibson <david@gibson.dropbear.id.au> wrote:
> At present the cascade interrupt handler for the UIC (interrupt
> controller on 4xx embedded chips) will misbehave badly if it is called
> spuriously - that is if the handler is invoked when no interrupts are
> asserted in the child UIC.
>
> Although spurious interrupts shouldn't happen, it's good to behave
> robustly if they do. This patch does so by checking for and ignoring
> spurious interrupts.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> ---
> arch/powerpc/sysdev/uic.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> Index: working-2.6/arch/powerpc/sysdev/uic.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/sysdev/uic.c 2007-08-14 13:46:02.000000000 +1000
> +++ working-2.6/arch/powerpc/sysdev/uic.c 2007-08-14 13:46:02.000000000 +1000
> @@ -266,6 +266,9 @@ irqreturn_t uic_cascade(int virq, void *
> int subvirq;
>
> msr = mfdcr(uic->dcrbase + UIC_MSR);
> + if (!msr) /* spurious interrupt */
> + return IRQ_HANDLED;
Hm. Is there was a way we could have this case increment
ppc_spurious_interrupts so that the BAD entry in /proc/interrupts would
be updated with these? Not a huge deal, but it might be nice to have.
Otherwise the patch looks fine.
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
josh
^ permalink raw reply
* FW: Cypress C67X00 driver question
From: Robertson, Joseph M. @ 2007-08-15 19:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <939D37AEB47F1F49B88FAB6599B6023501A1726C@hsv1dafpew02.das.gov.sanm.corp>
[-- Attachment #1: Type: text/plain, Size: 4077 bytes --]
Sorry, replied to wrong address...
-----Original Message-----
From: Robertson, Joseph M.
Sent: Wed 8/15/2007 2:18 PM
To: Peter Korsgaard
Subject: RE: Cypress C67X00 driver question
Hi,
Ok call me dense, but I still get a problem.
I put some messages in the driver. I see the c67x00_drv init, and also udc_init.
But no hdc init and no probing. And my ports are not powered.
I built the system to use c67x00_hdc, and I want 2 hosts enabled.
RE: The CYPRESS C67300 and ROM. By the docs, this thing comes up dead. It comes up HPI, co-processor mode and waits.
All the defaut values are 0 = disabled, off, etc.
Actually I have to get my hardware guys to double-check that, and also my port wiring, but thats another story.
Where does 'platform_device c67x00' go? That is, should it be sent/used by some init function? All I could find was c67x00_sie?
Thanks again.
Joe Robertson
Joseph.Robertson@sanmina-sci.com
-----Original Message-----
From: linuxppc-embedded-bounces+joseph.robertson=sanmina-sci.com@ozlabs.org on behalf of Peter Korsgaard
Sent: Thu 8/9/2007 2:08 AM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Cypress C67X00 driver question
>>>>> "RJM" == Robertson, Joseph M <joseph.robertson@sanmina-sci.com> writes:
Hi,
RJM> Hi all, First off big thanks to the guys working on the Cypress
RJM> USB C67X00 driver! Without them I would not even be this far.
You're welcome.
RJM> But my question for them is: How are you guys initializing the
RJM> Cypress chip? It looks like the driver is expecting the cypress
RJM> to be programmed and ready.
No, you don't need to program anything. The driver only uses he
Cypress BIOS programmed in ROM in the chip.
You just need to register a struct platform_device in your board code
with the base address, IRQ and port configuration - Something like:
#include <linux/usb/c67x00.h
..
static struct resource c67x00_resources[] = {
[0] = {
.start = 0x84000000,
.end = 0x8400000f,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = 3,
.end = 3,
.flags = IORESOURCE_IRQ,
},
};
static struct c67x00_platform_data c67x00_data = {
.sie_config = C67X00_SIE1_HOST | C67X00_SIE2_HOST,
.hpi_regstep = 0x02,
};
static struct platform_device c67x00 = {
.name = "c67x00",
.id = 0,
.num_resources = ARRAY_SIZE(c67x00_resources),
.resource = c67x00_resources,
.dev.platform_data = &c67x00_data,
};
--
Bye, Peter Korsgaard
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
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: 6349 bytes --]
^ permalink raw reply
* 2.6.23-rc3 broken on G5
From: Andreas Schwab @ 2007-08-15 20:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
This change:
commit edd0622bd2e8f755c960827e15aa6908c3c5aa94
Author: Paul Mackerras <paulus@samba.org>
Date: Fri Aug 10 21:04:07 2007 +1000
[POWERPC] Fix potential duplicate entry in SLB shadow buffer
is broken on PowerMac G5. It crashes very early, before the bootx
console is set up.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: System crash on boot_e500.S
From: mike zheng @ 2007-08-15 20:53 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <16A6A248-880E-483A-AFDD-2A225F4B6864@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]
Unfortunately, all the applications are running on 2.4 kernel. I can not
just throw the 2.4 kernel. I took the some core specific code from
ppc.bkbits.net, such as head_e500.S and mpc85xx_cds_common.c. I assume the
image should work on the 8548 CDS board, or at least for the bootup. I shall
able to have the serial port working in platform_init(). However , the
code stops in the head_e500.S. This does not make any sense. Please correct
me if I am wrong.
BTW, I am using the tool-chain gcc-3_4-e5000glibc-2.3.4-dp, which is from
Freescale for the 8548 CDS BSP of 2.6 kernel.
Any suggest or comment is welcome, I am struggling with this issue for
almost one week...... :-(
On 8/15/07, Becky Bruce <becky.bruce@freescale.com> wrote:
>
>
> On Aug 15, 2007, at 11:28 AM, Kumar Gala wrote:
>
> >
> > On Aug 15, 2007, at 11:02 AM, Scott Wood wrote:
> >
> >> On Wed, Aug 15, 2007 at 09:57:59AM -0400, mike zheng wrote:
> >>> Did you done similar work before? Current 2.6 code need many other
> >>> files, I
> >>> have following errors when I try to use the head_e500.S from 2.6
> >>> code:
> >>>
> >>>
> >>> /kernel-> powerpc-linux-gnuspe-gcc -m32 -Wp,-MD,arch/ppc/
> >>> kernel/.entry.o.d
> >>> -nostdinc -isystem /opt/mtwk/usr/local/gcc-3_4-
> >>> e500-glibc-2.3.4-dp/powerpc-linux-gnuspe/lib/gcc/powerpc-linux-
> >>> gnuspe/3.4.3/include
> >>> -D__KERNEL__ -Iinclude -Iarch/ppc -D__ASSEMBLY__ -Iarch/ppc -Wa,-
> >>> me500 -c
> >>> -o arch/ppc/kernel/entry.o arch/ppc/kernel/entry.S
> >>> arch/ppc/kernel/entry.S: Assembler messages:
> >>>
> >>> entry.S:819: Error: unsupported relocation against CSRR0
> >>> entry.S:820: Error: unsupported relocation against CSRR1
> >>> entry.S:888: Error: unsupported relocation against MCSRR0
> >>> entry.S:889: Error: unsupported relocation against MCSRR1
> >>> entry.S:909: Error: unsupported relocation against CSRR0
> >>> entry.S:911: Error: unsupported relocation against CSRR1
> >>
> >> Try arch/powerpc; arch/ppc is deprecated.
> >
> > He's trying a 2.4 kernel.
>
> I think maybe he misunderstood Jon's advive to "use 2.6" as using
> just some files from 2.6. I think the above is probably some strange
> mix of 2.4 and 2.6, which, of course, won't work.
>
> Jon's real advice was "use 2.6", as in, the whole thing.
>
> -B
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 3310 bytes --]
^ permalink raw reply
* Re: System crash on boot_e500.S
From: Scott Wood @ 2007-08-15 20:57 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <5c9cd53b0708151353u67e10e03lf12c3971e4f3d63@mail.gmail.com>
mike zheng wrote:
> Unfortunately, all the applications are running on 2.4 kernel. I can not
> just throw the 2.4 kernel.
And in what way does 2.6 break these applications?
> I took the some core specific code from
> ppc.bkbits.net, such as head_e500.S and mpc85xx_cds_common.c. I assume the
> image should work on the 8548 CDS board, or at least for the bootup. I shall
> able to have the serial port working in platform_init(). However , the
> code stops in the head_e500.S. This does not make any sense. Please correct
> me if I am wrong.
Of course it makes sense -- you can't just go around ripping random
files from a codebase, sticking them in a version from several years
earlier, and expecting it to "just work".
> Any suggest or comment is welcome, I am struggling with this issue for
> almost one week...... :-(
How long would you have struggled with getting your applications running
on a more recent kernel instead?
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc: add setmaskedbits macros
From: Paul Mackerras @ 2007-08-15 21:06 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <11871796461560-git-send-email-timur@freescale.com>
Timur Tabi writes:
> This patch adds the setmaskedbits_xxx() macros, which are used to set a
> multiple-bit bit pattern in a register. The macros include a mask, which
> zeros the respective bits before applying the value via a bitwise-OR.
> There are big-endian and little-endian versions for 8, 16, 32, and 64 bits.
Why do we want these? (Don't tell me, put it in the commit log. :)
Paul.
^ permalink raw reply
* Re: System crash on boot_e500.S on 2.4Kernel
From: mike zheng @ 2007-08-15 21:12 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-embedded
In-Reply-To: <FC996AA4-4C5F-4B36-A9E9-5F931D054F1C@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 3482 bytes --]
Here is the PC value before the rfi:
cds8458>halt
Target CPU: : MPC85xx (e500v2 rev.1)
Target state : halted
Debug entry cause : instruction breakpoint
Current PC : 0x0000015c
Current CR : 0x24024022
Current MSR : 0x00012100
Current LR :0x00000148
Current CCSRBAR :0x0_e000000
After the rfi:
#step timeout defected
cds8458>halt
Target CPU: : MPC85xx (e500v2 rev.1)
Target state : halted
Debug entry cause : COP halt
Current PC : 0xfff81300
Current CR : 0x24024022
Current MSR : 0x00001000
Current LR :0x00000148
Current CCSRBAR :0x0_e000000
On 8/15/07, Becky Bruce <becky.bruce@freescale.com> wrote:
>
>
> On Aug 15, 2007, at 8:59 AM, mike zheng wrote:
>
> > I use BDI to debug these two instructions. And here are the output
> > of BDI just before the "rfi". The content of R6, R7 is different
> > from SRR0(SPR26) and SRR1(SPR27).
>
> I see you have not printed the pc/nia once you stop. Are you sure
> you're stopped where you think? Please check this.
>
> -B
>
> >
> > cds8548>res run
> >
> > - TARGET: processing user reset request
> >
> > - BDI asserts HRESET
> >
> > - Reset JTAG controller passed
> >
> > - JTAG exists check passed
> >
> > - IDCODE is 0x0003901D
> >
> > - SVR is 0x80390011
> >
> > - PVR is 0x80210010
> >
> > - CCSRBAR is 0x0_ff700000
> >
> > - BDI removes HRESET
> >
> > - TARGET: Target PVR is 0x80210010
> >
> > - TARGET: resetting target passed
> >
> > cds8548>halt
> >
> > Target CPU : MPC85xx (e500v2 rev.1)
> >
> > Target state : halted
> >
> > Debug entry cause : COP halt
> >
> > Current PC : 0xfff82560
> >
> > Current CR : 0x88000042
> >
> > Current MSR : 0x00021200
> >
> > Current LR : 0xfff8aa4c
> >
> > Current CCSRBAR : 0x0_e0000000
> >
> > cds8548>ci
> >
> > cds8548>bi 0x0000015c
> >
> > Breakpoint identification is 0
> >
> > cds8548>go
> >
> > - TARGET: stopped
> >
> > cds8548>rd
> >
> > GPR00: 00000000 0ffabd20 00000200 00000008
> >
> > GPR04: 00000000 00000001 00000020 00000160
> >
> > GPR08: 1f8b0808 00000148 0ffabace 0ffe08b0
> >
> > GPR12: 00000006 764deddb 10000300 007fff00
> >
> > GPR16: 00000001 ffffffff 007fff25 0ffff9d8
> >
> > GPR20: 007ffeb0 00000000 0fffaa3c 0ffae490
> >
> > GPR24: 00000000 00000003 02000040 007fff25
> >
> > GPR28: 007fff00 0ffab3b8 0fcd6000 007ffeb0
> >
> > CR : 24024022 MSR: 00021200
> >
> > cds8548>rdspr 26
> >
> > SPR 26 : 0xfff81300 - 519424
> >
> > cds8548>rdspr 27
> >
> > SPR 27 : 0x00001000 4096
> >
> > cds8548>
> >
> >
> >
> >
> >
> >
> > On 8/14/07, Andy Fleming <afleming@freescale.com> wrote:
> > On Aug 14, 2007, at 15:21, mike zheng wrote:
> >
> > >
> > > Hi All,
> > >
> > > I am trying to bring up MPC8548 CDS board on 2.4 kernel. I have
> > > problem in the head_e500.S. The "mtspr SRR0, r7; mtspr SRR1 r6"
> > > does not work for me. The content of R7 and R6 are not moved to
> > > SRR0 and SRR1. I am using the tool-chain from Freescale for 2.6
> > > kernel.
> > >
> > > Any idea on this issue?
> >
> > Just to check...how do you know it doesn't work?
> >
> > Andy
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
[-- Attachment #2: Type: text/html, Size: 6346 bytes --]
^ permalink raw reply
* Re: System crash on boot_e500.S
From: mike zheng @ 2007-08-15 21:23 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <46C368D1.7000403@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]
On 8/15/07, Scott Wood <scottwood@freescale.com> wrote:
>
> mike zheng wrote:
> > Unfortunately, all the applications are running on 2.4 kernel. I can not
> > just throw the 2.4 kernel.
>
> And in what way does 2.6 break these applications?
All the device drivers are based on 2.4 kernel. We plan to upgrade to 2.6 in
the middle of next year.
> I took the some core specific code from
> > ppc.bkbits.net, such as head_e500.S and mpc85xx_cds_common.c. I assume
> the
> > image should work on the 8548 CDS board, or at least for the bootup. I
> shall
> > able to have the serial port working in platform_init(). However , the
> > code stops in the head_e500.S. This does not make any sense. Please
> correct
> > me if I am wrong.
>
> Of course it makes sense -- you can't just go around ripping random
> files from a codebase, sticking them in a version from several years
> earlier, and expecting it to "just work".
All those files are e500 core specific. When we use bootm from Uboot to
start the kernel, head_e500.S is first file being called, and then the
mpc85xx_cds_common.c. I also merged some BOOKE related include files into
our source tree as well.
Our 2.4 kernel version is different from ppc.bkbits.net. I did not expect it
"just work". However the serial console should come out when platform_init()
called. Everything before that is the same for any processor with e500 core.
> Any suggest or comment is welcome, I am struggling with this issue for
> > almost one week...... :-(
>
> How long would you have struggled with getting your applications running
> on a more recent kernel instead?
Don't know, maybe 16 weeks. That is out of my control. I only deal with the
kernel.....:-)
-Scott
>
[-- Attachment #2: Type: text/html, Size: 2666 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: fix i2c device string format
From: Scott Wood @ 2007-08-15 21:29 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0708152106090.10160@poirot.grange>
Guennadi Liakhovetski wrote:
> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
> index 727453d..c0d66df 100644
> --- a/arch/powerpc/sysdev/fsl_soc.c
> +++ b/arch/powerpc/sysdev/fsl_soc.c
> @@ -320,21 +320,26 @@ static struct i2c_driver_device i2c_devices[] __initdata = {
> {"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",},
> };
>
> -static int __init of_find_i2c_driver(struct device_node *node, struct i2c_board_info *info)
> +static int __init of_find_i2c_driver(struct device_node *node,
> + struct i2c_board_info *info)
> {
> int i;
>
> for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
> if (!of_device_is_compatible(node, i2c_devices[i].of_device))
> continue;
> - strncpy(info->driver_name, i2c_devices[i].i2c_driver, KOBJ_NAME_LEN);
> - strncpy(info->type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
> + if (strlcpy(info->driver_name, i2c_devices[i].i2c_driver,
> + KOBJ_NAME_LEN) >= KOBJ_NAME_LEN ||
> + strlcpy(info->type, i2c_devices[i].i2c_type,
> + I2C_NAME_SIZE) >= I2C_NAME_SIZE)
> + return -ENOMEM;
> return 0;
> }
> return -ENODEV;
> }
BTW, is there any reason this stuff is fsl_soc specific? I'd think
prom_parse.c (or better yet, drivers/of/ or drivers/i2c/, now that some
OF calls have been factored out) would be a better place.
-Scott
^ permalink raw reply
* [PATCH v2] powerpc: add setmaskedbits macros
From: Timur Tabi @ 2007-08-15 21:30 UTC (permalink / raw)
To: linuxppc-dev, paulus; +Cc: Timur Tabi
This patch adds the setmaskedbits_xxx() macros, which are used to set a
multiple-bit bit pattern in a register. The macros include a mask, which
zeros the respective bits before applying the value via a bitwise-OR.
There are big-endian and little-endian versions for 8, 16, 32, and 64 bits.
These new macros are useful because the setbits macros can only be used
to set single-bit fields. For example, if you have a 32-bit register
where bits 17-20 need to be set to 0100, you would do
setmaskedbits_be32(p, 4 << 11, 0xF << 11).
Signed-off-by: Timur Tabi <timur@freescale.com>
---
Updated the changelog to include a reason why you'd want these macros.
I have a number of new SOC device drivers coming up that will use these
macros, if this patch is accepted.
include/asm-powerpc/io.h | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
index bb8d965..ac3defb 100644
--- a/include/asm-powerpc/io.h
+++ b/include/asm-powerpc/io.h
@@ -734,6 +734,19 @@ static inline void * bus_to_virt(unsigned long address)
#define setbits16(_addr, _v) out_be16((_addr), in_be16(_addr) | (_v))
#define clrbits16(_addr, _v) out_be16((_addr), in_be16(_addr) & ~(_v))
+#ifdef __powerpc64__
+#define setmaskedbits_be64(a, v, m) out_be64((a), (in_be64(a) & ~(m)) | (v))
+#define setmaskedbits_le64(a, v, m) out_le64((a), (in_le64(a) & ~(m)) | (v))
+#endif
+
+#define setmaskedbits_be32(a, v, m) out_be32((a), (in_be32(a) & ~(m)) | (v))
+#define setmaskedbits_be16(a, v, m) out_be16((a), (in_be16(a) & ~(m)) | (v))
+
+#define setmaskedbits_le32(a, v, m) out_le32((a), (in_le32(a) & ~(m)) | (v))
+#define setmaskedbits_le16(a, v, m) out_le16((a), (in_le16(a) & ~(m)) | (v))
+
+#define setmaskedbits_8(a, v, m) out_8((a), (in_8(a) & ~(m)) | (v))
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_IO_H */
--
1.5.2.4
^ permalink raw reply related
* Re: System crash on boot_e500.S on 2.4Kernel
From: Andy Fleming @ 2007-08-15 22:06 UTC (permalink / raw)
To: mike zheng; +Cc: linuxppc-embedded
In-Reply-To: <5c9cd53b0708151412v2f5feb74v9e0b49d114b83021@mail.gmail.com>
On Aug 15, 2007, at 16:12, mike zheng wrote:
> Here is the PC value before the rfi:
>
> cds8458>halt
> Target CPU: : MPC85xx (e500v2 rev.1)
> Target state : halted
> Debug entry cause : instruction breakpoint
> Current PC : 0x0000015c
> Current CR : 0x24024022
> Current MSR : 0x00012100
> Current LR :0x00000148
> Current CCSRBAR :0x0_e000000
>
> After the rfi:
>
> #step timeout defected
> cds8458>halt
> Target CPU: : MPC85xx (e500v2 rev.1)
> Target state : halted
> Debug entry cause : COP halt
> Current PC : 0xfff81300
> Current CR : 0x24024022
> Current MSR : 0x00001000
> Current LR :0x00000148
> Current CCSRBAR :0x0_e000000
Ok, I'm sure your problem isn't that SRR0 isn't getting updated
properly. I suspect something is going wrong during the rfi.
Possibly something in your TLBs. However, what is happening is most
likely that you have hit an exception, and SRR0 and SRR1 have been
updated. I'm a little confused by the addresses where you first
invoke "halt". It looks like you're in the middle of flash, which is
an odd place in u-boot to be.
And if you look at your PC, it doesn't seem like you step. It looks
like something goes wrong with the debugging. My suggestion is to
check your TLB setup and your IVOR setup. Find out if the IVORs are
pointing at an exception at fff81300.
Andy
^ 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