* 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
* Re: [patch 6/6] Walnut zImage wrapper
From: Wolfgang Grandegger @ 2007-09-24 7:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20070905113604.746ee01c@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> Updated patch below
>
> Add zImage wrapper for walnut board
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> ---
> arch/powerpc/boot/Makefile | 3
> arch/powerpc/boot/dcr.h | 5 +
> arch/powerpc/boot/treeboot-walnut.c | 131 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 138 insertions(+), 1 deletion(-)
>
> --- linux-2.6.orig/arch/powerpc/boot/Makefile
> +++ linux-2.6/arch/powerpc/boot/Makefile
> @@ -49,7 +49,7 @@ src-wlib := string.S crt0.S stdio.c main
> 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-bamboo.c
> + cuboot-pq2.c cuboot-bamboo.c treeboot-walnut.c
[deletions]
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?
And the WARNING above on "Section mismatch" looks strange as well (still
present in 2.6.23-rc7).
Thanks for help.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 1/2] qemu platform, v2
From: Christoph Hellwig @ 2007-09-24 7:46 UTC (permalink / raw)
To: Christoph Hellwig, Milton Miller, linuxppc-dev, Paul Mackerras,
Rob Landley
In-Reply-To: <20070924040047.GK8058@localhost.localdomain>
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?
^ permalink raw reply
* Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16
From: Milton Miller @ 2007-09-24 6:54 UTC (permalink / raw)
To: David Gibson; +Cc: ppcdev, Paul Mackerras
In-Reply-To: <20070924033612.GI8058@localhost.localdomain>
On Sep 23, 2007, at 10:36 PM, David Gibson wrote:
> On Fri, Sep 21, 2007 at 06:05:06PM -0500, Milton Miller wrote:
>> kexec-tools still produces a version 2 device tree, while the
>> libraries in the wrapper only support version 16 and later.
>>
>> Add a routine to convert a v2 flat device tree to a v16 one inplace
>> by inserting OF_DT_NOP and chomping full path. Make space for new
>> headers by moving and then chomping the OF_DT_NOPs.
>>
>> Signed-off-by: Milton Miller <miltonm@bga.com>
>> ---
>> vs 12175
>> Rediffed Makefile, ops, kexec.c
>>
>> Index: kernel/arch/powerpc/boot/flatdevtree_conv.c
>> ===================================================================
>> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
>> +++ kernel/arch/powerpc/boot/flatdevtree_conv.c 2007-09-20
>> 17:49:04.000000000 -0500
>> @@ -0,0 +1,280 @@
>> +/*
>> + * 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; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301, USA.
>> + *
>> + * Copyright IBM Corporation 2007
>> + *
>> + * Authors: Milton Miller <miltonm@bga.com>
>> + */
>> +#include "flatdevtree.h"
>> +#include "stdio.h"
>> +#include "ops.h"
>> +
>> +#define MIN_VERSION 2
>> +#define OUT_VERSION 16
>
> Should output version 17. In any case, don't try to be so general -
> just convert v123 (all basically the same) to latest (i.e. v17)
> without all the #if nonsense.
Outputing v17 instead of 16 requires more words to be added to the
header, and the library does fine with v16. Actually the v1 trees has
some other differences such as initrd addresses were kernel linear not
real, cpus were assigned logical numbers ... so while the structure
didn't change except for the header field, the contents did. Actually,
when converting v3 to v16 some of the code issn't needed, the ifs allow
the code size to be reduced.
>
>> +#define OUT_COMPAT 16
>> +
>> +#ifdef NO_CHECK
>> +static int check_v123_tree(u32 *start, u32 *limit)
>> +{
>> + return 0;
>> +}
>> +#else
>> +/**
>> + * check_v123_tree - check integrety of a version 1, 2, or 3 tree
>> + * @start: the start of the device tree struct
>> + * @limit: the end of the region for the struct
>> + * structural checks on device_tree
>> + */
>> +static int check_v123_tree(u32 *start, u32 *limit)
>
> What is the point of this check? If the device tree is corrupt, we're
> stuffed anyway, so why bother?
Hence the ifdef NO_CHECK. When developing, sometimes its nice to know
if its your input or your program. These functions are destructive to
an improperlly formed tree, and in non-obvious ways. When debugging,
it's not hard to hardcode console write or read the printf string
buffer with a hardware debugger to see error messages. That said, it
could be removed.
>
>> +{
>> + u32 len;
>> + int depth = 0;
>> + u32 *dtp = start;
>> +
>> + while (dtp < limit)
>> + switch (*dtp) {
>> + case OF_DT_END:
>> + if (depth)
>> + return -1;
>> + return ++dtp - start;
>> + case OF_DT_NOP:
>> + dtp++;
>> + break;
>> + case OF_DT_END_NODE:
>> + dtp++;
>> + depth--;
>> + break;
>> + case OF_DT_BEGIN_NODE:
>> + len = strlen((char *)(++dtp));
>> + /* check path is suffix to previous? */
>> + dtp += 1 + (len / 4);
>> + depth++;
>> + break;
>> + case OF_DT_PROP:
>> + len = dtp[1];
>> + dtp += 3;
>> + if ((len >= 8) && ((long)dtp & 4))
>> + dtp++;
>> + dtp += (len + 3) / 4;
>> + break;
>> + default:
>> + return -1;
>> + }
>> + return -1; /* no OF_DT_END */
>> +}
>> +#endif
>> +
>> +/**
>> + * nop_to_v16 - add %OF_DT_NOP to hide alignment differences
>> + * @dtp: pointer to the beginning of the struct area to modify
>> + * insert %OF_DT_NOP into the dt_struct @dtp to make it v16 from v1,
>> 2, or 3.
>> + */
>> +static int nop_to_v16(u32 *dtp)
>> +{
>> + int nops = 0;
>> + char *p, *s;
>> + int len;
>> + u32 *next;
>> +
>> + while (*dtp != OF_DT_END)
>> + switch (*dtp) {
>> + case OF_DT_BEGIN_NODE:
>> + /* v2 & v3 names are full path, v16+ is relative */
>> + p = (char *)(++dtp);
>> + len = strlen(p);
>> + next = dtp + 1 + len / 4;
>> +
>> + for (s = p + len; *s != '/'; s--)
>> + if (s == p)
>> + fatal("name %s has no '/'", p);
>> +
>> + len -= s++ - p; /* not the slash but the nul */
>> + memmove(p, s, len);
>> + while (len % 4)
>> + p[len++] = '\0';
>> + dtp += len / 4;
>> + while (dtp != next) {
>> + *dtp++ = OF_DT_NOP;
>> + nops++;
>> + }
>> + break;
>> + case OF_DT_PROP:
>> + /* convert from align_8 to align_4 via prefixing nop */
>> + len = dtp[1];
>> + if ((len >= 8) && !((long)dtp & 4)) {
>> + memmove(dtp+1, dtp, 12);
>> + *dtp++ = OF_DT_NOP;
>> + nops++;
>> + }
>> + dtp += 3 + (len + 3)/4;
>> + break;
>> + default:
>> + fatal("%s: unrecognised tag %d at %p\n", __FUNCTION__,
>> + *dtp, dtp);
>> + case OF_DT_NOP:
>> + nops ++;
>> + /* fall through */
>> + case OF_DT_END_NODE:
>> + dtp ++;
>> + break;
>> + }
>> + return nops;
>> +}
>> +
>> +#if MIN_VERSION < 3 || OUT_VERSION > 16
>> +/**
>> + * move_nops_fwd - move nops in a v16 dt_struct to the beginning
>> + * @start - device tree starting address
>> + * @count - number of %OF_DT_NOP cells to move
>> + */
>> +static void move_nops_fwd(u32 *start, int count)
>
> What on earth is the point of this. The NOPs are perfectly valid
> scattered within the tree, why go to all this trouble to shuffle them
> about.
And if you notice, there is a "how many to move" argument. The point
of moving them to the front of the tree is the v17 device tree header
takes more space than the v3 one, and the v2 header is smaller than
both v17 and v16 header. Since I am converting the tree in place, the
space has to come from somewhere. Since we are pretty much guaranteed
to get several nops, this function moves them forward so they can be
overwritten. In practice we move 1-3 NOPS from the early properties >
8 bytes and early grandchild nodes (eg /cpus/PowerPC,xxx).
>
>> +{
>> + u32 *dtp = start;
>> + int len;
>> + while (count)
>> + switch (*dtp) {
>> + case OF_DT_NOP:
>> + memmove(start+1,start,(dtp-start) * 4);
>> + *start++ = OF_DT_NOP;
>> + dtp++;
>> + count--;
>> + break;
>> + case OF_DT_END_NODE:
>> + dtp++;
>> + break;
>> + case OF_DT_BEGIN_NODE:
>> + len = strlen((char *)(++dtp));
>> + dtp += 1 + len / 4;
>> + break;
>> + case OF_DT_PROP:
>> + len = dtp[1];
>> + dtp += 3 + (len + 3) / 4;
>> + break;
>> + case OF_DT_END:
>> + fatal("Not enough nops -- need %d more\n", count);
>> + return;
>> + default:
>> + fatal("%s: unknown tag %d at %p", __FUNCTION__, *dtp, dtp)
>> + }
>> +}
>> +#endif
>> +
>> +/**
>> + * conv_flattree_inplace upgrade the version of a boot_param_header
>> + * @tree: pointer to the device tree header to convert
>> + *
>> + * Converts a v1, 2, 3 device tree (of at least MIN_VERSION)
>> + * in place to OUT_VERSION (16) format, usable by flatdevtree.c
>> + */
>> +void conv_flattree_inplace(struct boot_param_header *tree)
>> +{
>> + u32 *dtp;
>> + u32 need = 0, nops;
>> + int slen;
>> +
>> + if (tree->magic != OF_DT_HEADER)
>> + fatal("%s: no magic", __FUNCTION__);
>
> More pointless tests...
It says you didn't pass a tree ... yea, its dumb, but I prefer an
explicit error to figuring out where a machine check came from.
>
>> + if (tree->last_comp_version > 3)
>> + return; /* don't know what to do */
>
> Rather, don't need to do anything.
If the tree is >= 16 then we don't presently need to do anything. If
there is a theoritical v4 tree we don't know what to do. And if output
version is 17 but input is 16 we don't know what to do either, because
there likely aren't nops in the tree to consume. I suppose we could
preceed it with a check for version == OUTPUT_VERSION, but then I'm
sure I'd get pointless differentation :-).
>
>> +
>> + if (tree->version < MIN_VERSION) {
>> + printf("%s: Warning: can't handle version %d tree\n",
>> + __FUNCTION__, tree->version);
>> + return;
>> + }
>> +
>> + if (tree->version < 2)
>> + need++; /* boot_cpu_id */
>> +
>> + if (tree->version < 3)
>> + need++; /* dt_string_size */
>> +
>> + if (OUT_VERSION > 16)
>> + need++; /* dt_struct_size */
>> +
>> + dtp = (void *)tree + tree->off_dt_struct;
>> +
>> + slen = check_v123_tree(dtp, (void *)tree + tree->totalsize);
>> + if (slen < 0)
>> + fatal("device tree check failed\n");
>> +
>> + nops = nop_to_v16(dtp);
>> +
>> + if (need & 1) /* keep 8 byte alignment of mem reserve */
>> + need++;
>> +
>> + if (need > nops)
>> + fatal("Didn't find enough space to add new header fields\n\r"
>> + "(needed %d found %d tree %p)", need, nops, tree);
>> +
>> + /* ok now compress the dtb struct */
>> + move_nops_fwd(dtp, need);
>> + dtp += need;
>> +
>> + /*
>> + * move mem_rsvmap and dt_strings if they are before dt_struct
>> + * onto our nops . Adjust start addresses for the 3 sections.
>> + */
>
> Hrm. Do we really need to worry about this case. You may be
> producing v2 trees in kexec-tools, but do they actually have the
> blocks out of order? dtc certainly never produced them that way.
Out of order? There has never been a spec as to the order of the
blocks, only the implicit assumption that they follow the device tree
header in a reasonably packed sequence. booting-without-of says it
must be in ram,; the offsets are unsigned 32 bit quantities.
As to the order, used, the first implemntation was the kernel which
writes memreserve, strings, then struct (both the openfirmware client
in prom_init and the iSeries procedural library in dt.c). The second
implentation written is a procedural based library (similar to iseries,
never published, but still used internally) that starts with a
pre-built header and string table, builds the dt_struct as the
functions are called, and when finished copies the memreserve table and
fills in the dt_size, total size, and memreserve offset.
fs2dt writes memreserve, struct, then strings. Aparently the same as
dtc. But yes, the strings can be before the struct, and the mem
reserve may or may not be when the strings are before the struct.
>
>> + if ((tree->off_mem_rsvmap < tree->off_dt_struct) ||
>> + (tree->off_dt_strings < tree->off_dt_struct)) {
>> + int start, end;
>> + void *ptr;
>> +
>> + if (tree->off_mem_rsvmap < tree->off_dt_strings)
>> + start = tree->off_mem_rsvmap;
>> + else
>> + start = tree->off_dt_strings;
>> +
>> + end = tree->off_dt_struct;
>> + ptr = (void *)tree + start;
>> +
>> + memmove(ptr + 4 * need, ptr, end - start);
>> +
>> + if (tree->off_mem_rsvmap < tree->off_dt_struct)
>> + tree->off_mem_rsvmap += 4 * need;
>> + if (tree->off_dt_strings < tree->off_dt_struct)
>> + tree->off_dt_strings += 4 * need;
>> + }
>> + tree->off_dt_struct += 4 * need;
>> +
>> + /* ok now we have space to extend the header. */
>> + if (tree->version < 2 && MIN_VERSION < 2) {
>> + tree->boot_cpuid_phys = 0; /* default, caller can fix */
>> + }
>> +
>> + /* calculate size of dt_strings_size */
>> + if (tree->version < 3 && MIN_VERSION < 3) {
>> + int end = tree->totalsize;
>> +
>> + if (tree->off_dt_strings < tree->off_mem_rsvmap)
>> + end = tree->off_mem_rsvmap;
>> +
>> + if ((tree->off_dt_strings < tree->off_dt_struct) &&
>> + (end > tree->off_dt_struct))
>> + end = tree->off_dt_struct;
>> +
>> + tree->dt_strings_size = end - tree->off_dt_strings;
>> + }
>> +
>> +#if OUT_VERSION > 16
>> + tree->dt_struct_size = 4 * slen;
>> +#endif
>> +
>> + tree->version = OUT_VERSION;
>> + tree->last_comp_version = OUT_COMPAT;
>> +
>> + return;
>> +}
>> Index: kernel/arch/powerpc/boot/Makefile
>> ===================================================================
>> --- kernel.orig/arch/powerpc/boot/Makefile 2007-09-20
>> 17:42:24.000000000 -0500
>> +++ kernel/arch/powerpc/boot/Makefile 2007-09-20 17:49:04.000000000
>> -0500
>> @@ -42,7 +42,7 @@ $(addprefix $(obj)/,$(zlib) gunzip_util.
>> $(addprefix $(obj)/,$(zliblinuxheader)) $(addprefix
>> $(obj)/,$(zlibheader))
>>
>> src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c
>> flatdevtree_misc.c \
>> - marshal.c memranges.c kexec.c \
>> + flatdevtree_conv.c marshal.c memranges.c kexec.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 \
>> Index: kernel/arch/powerpc/boot/ops.h
>> ===================================================================
>> --- kernel.orig/arch/powerpc/boot/ops.h 2007-09-20 17:42:24.000000000
>> -0500
>> +++ kernel/arch/powerpc/boot/ops.h 2007-09-20 17:49:04.000000000 -0500
>> @@ -81,7 +81,10 @@ struct loader_info {
>> };
>> extern struct loader_info loader_info;
>>
>> +struct boot_param_header;
>> +
>> void start(void);
>> +void conv_flattree_inplace(struct boot_param_header *tree);
>> int ft_init(void *dt_blob, unsigned int max_size, unsigned int
>> max_find_device);
>> int serial_console_init(void);
>> int ns16550_console_init(void *devp, struct serial_console_data
>> *scdp);
>> Index: kernel/arch/powerpc/boot/kexec.c
>> ===================================================================
>> --- kernel.orig/arch/powerpc/boot/kexec.c 2007-09-20
>> 17:42:24.000000000 -0500
>> +++ kernel/arch/powerpc/boot/kexec.c 2007-09-20 17:49:04.000000000
>> -0500
>> @@ -99,6 +99,7 @@ void kexec_platform_init(struct boot_par
>> move_slaves_up();
>>
>> setup_initial_heap();
>> + conv_flattree_inplace(dt_blob);
>> init_flat_tree(dt_blob);
>> /*
>> * drivers can malloc and read the tree, but not realloc later
>> _______________________________________________
>> 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
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
From: Kumar Gala @ 2007-09-24 6:13 UTC (permalink / raw)
To: David Gibson; +Cc: Timur Tabi, linuxppc-dev
In-Reply-To: <20070924050709.GM8058@localhost.localdomain>
On Sep 24, 2007, at 12:07 AM, David Gibson wrote:
> On Fri, Sep 21, 2007 at 09:35:03AM +0200, Peter Korsgaard wrote:
>>>>>>> "Scott" == Scott Wood <scottwood@freescale.com> writes:
>>
>> Hi,
>>
>> Scott> #size-cells is zero on i2c, so it should just be reg = <68>.
>>
>> Scott> You'll probably need to add #address-cells and #size-cells
>> to the
>> Scott> controller node, as well.
>
> Uh.. yes.. i2c interfaces should really always have #a and #s.
>
>> Ahh - Thanks. This should be better.
>> ---
>>
>> [PATCH] mpc8349emitx.dts: Add ds1339 RTC
>>
>> Add ds1339 I2C RTC chip as child of 2nd I2C controller.
>>
>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>> ---
>> arch/powerpc/boot/dts/mpc8349emitx.dts | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> Index: linux/arch/powerpc/boot/dts/mpc8349emitx.dts
>> ===================================================================
>> --- linux.orig/arch/powerpc/boot/dts/mpc8349emitx.dts
>> +++ linux/arch/powerpc/boot/dts/mpc8349emitx.dts
>> @@ -62,12 +62,21 @@
>> };
>>
>> 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 prob
suggestions on how to handle this? We've described that fsl-i2c
nodes in booting-without-of.txt should have it. (which may have been
wrong at the time).
- k
>
>> compatible = "fsl-i2c";
>> reg = <3100 100>;
>> interrupts = <f 8>;
>> interrupt-parent = < &ipic >;
>> dfsrr;
^ permalink raw reply
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
From: Peter Korsgaard @ 2007-09-24 5:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070924050709.GM8058@localhost.localdomain>
>>>>> "David" == David Gibson <david@gibson.dropbear.id.au> writes:
Hi
>> compatible = "fsl-i2c";
>> reg = <3100 100>;
>> interrupts = <f 8>;
>> interrupt-parent = < &ipic >;
>> dfsrr;
>> +
>> + rtc@68 {
>> + device_type = "rtc";
>> + compatible = "dallas,ds1339";
>> + reg = <68>;
>> + };
David> I think we want to think a bit more carefully about how to do bindings
David> for RTC devices. No "rtc" device_type is defined, but again we might
David> want to.
Could be. I've simply done it like kuroboxHD.dts already does and
fsl_soc.c expects.
David> I did find one real OF binding for a different Dallas RTC (and NVRAM),
David> see:
David> http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346-it.txt
David> It's a little different from the example above.
David> The fact that NVRAM+RTC chips are so common is a bit of an issue from
David> the point of view of defining a device class binding - a device can't
David> have type "rtc" and "nvram".
True. I think we should primarily focus on the RTC part rather than
NVRAM as that's the "main" functionality and leave a NVRAM class for
I2C EEPROMs.
The Linux driver for the chip (rtc-1307.c) doesn't expose the NVRAM
bytes either.
But I'm open for suggestions.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 1/15] boot: find initrd location from device-tree
From: Rob Landley @ 2007-09-24 5:50 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras, Milton Miller
In-Reply-To: <20070924025824.GD8058@localhost.localdomain>
On Sunday 23 September 2007 9:58:24 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.
Except int and uint are 32 bits on all targets, due to unix standardizing on
LP64:
http://www.unix.org/whitepapers/64bit.html
http://www.unix.org/version2/whatsnew/lp64_wp.html
> > +/**
> > + * 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.
I think this means it finds the initrd location from the device tree (supplied
by your firmware or bootloader) rather than from the kernel command line the
way all the other platforms do.
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
From: David Gibson @ 2007-09-24 5:07 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <874pholbdk.fsf@macbook.be.48ers.dk>
On Fri, Sep 21, 2007 at 09:35:03AM +0200, Peter Korsgaard wrote:
> >>>>> "Scott" == Scott Wood <scottwood@freescale.com> writes:
>
> Hi,
>
> Scott> #size-cells is zero on i2c, so it should just be reg = <68>.
>
> Scott> You'll probably need to add #address-cells and #size-cells to the
> Scott> controller node, as well.
Uh.. yes.. i2c interfaces should really always have #a and #s.
> Ahh - Thanks. This should be better.
> ---
>
> [PATCH] mpc8349emitx.dts: Add ds1339 RTC
>
> Add ds1339 I2C RTC chip as child of 2nd I2C controller.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
> ---
> arch/powerpc/boot/dts/mpc8349emitx.dts | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> Index: linux/arch/powerpc/boot/dts/mpc8349emitx.dts
> ===================================================================
> --- linux.orig/arch/powerpc/boot/dts/mpc8349emitx.dts
> +++ linux/arch/powerpc/boot/dts/mpc8349emitx.dts
> @@ -62,12 +62,21 @@
> };
>
> 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
> compatible = "fsl-i2c";
> reg = <3100 100>;
> interrupts = <f 8>;
> interrupt-parent = < &ipic >;
> dfsrr;
> +
> + rtc@68 {
> + device_type = "rtc";
> + compatible = "dallas,ds1339";
> + reg = <68>;
> + };
I think we want to think a bit more carefully about how to do bindings
for RTC devices. No "rtc" device_type is defined, but again we might
want to.
I did find one real OF binding for a different Dallas RTC (and NVRAM),
see:
http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346-it.txt
It's a little different from the example above.
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".
> +
> };
>
> spi@7000 {
>
--
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