* Re: [PATCH 2/3] Introduce new CPM device bindings.
From: David Gibson @ 2007-08-30 5:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070830054854.GA21533@ld0162-tx32.am.freescale.net>
On Thu, Aug 30, 2007 at 12:48:54AM -0500, Scott Wood wrote:
> On Thu, Aug 30, 2007 at 10:55:59AM +1000, David Gibson wrote:
> > Am I correct in thinking that it's basically an arch/ppc versus
> > arch/powerpc thing. In which case couldn't you use CONFIG_PPC_MERGE
> > instead?
>
> The idea was to allow boards to be converted incrementally, as I don't
> have access to test 100% of the boards that use the CPM code.
Hrm. Right. This is still problematical, because what happens if you
have both old-binding and new-binding boards configured simultaneously?
> > > It has a phandle to the phy node... if you mean the mdio bus node, why?
> >
> > Well, I'm just working of the example of 4xx EMAC. The way it does
> > mdio, it wants a handle on the mdio bus to perform various operations
> > there as well on the phy to tell it how to address them. fsl-enet may
> > do things differently and have no particular need for such a handle.
>
> Even if it did need such a handle, couldn't it just look at the phy
> node's parent?
Well, yes, but it's just a bit more fiddling. For the purposes of
emac, it seemed simpler to supply pass the mdio phandle as well.
--
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: Network is blocked till ping is issued
From: DI BACCO ANTONIO - technolabs @ 2007-08-30 6:24 UTC (permalink / raw)
To: Florian A. Voegel, linuxppc-embedded
In-Reply-To: <20070830010752.0ca3d309.fvoegel@carangul.com>
> sounds to me like it could be a classical ARP problem. Have you
checked the ARP cache on the non-Linux
> machine?
But if Linux received the SYN packet of TCP connection, shouldn't the
Linux machine reply to the source mac address of SYN packet with a
SYN,ACK packet?
^ permalink raw reply
* Re: spin_lock doesn't work?!?
From: melinda develey @ 2007-08-30 6:30 UTC (permalink / raw)
To: Wolfgang Reissnegger; +Cc: linuxppc-embedded
In-Reply-To: <20070829214050.8C47A1A2804D@mail19-sin.bigfish.com>
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
>You should still put the spin_lock calls into your code because >you
>never know if someone else will compile it and for another >target. If
>someone would, for example, compile the same code for a SMP >machine then
>the spin_lock will actually lock.
I used the spinlock both in an interrupt handler to protect a group of variables (because in an interrupt I can't use a semaphore) and the same spinlock in a ioctl handler where the same group of variables is accessed. Is this wrong? I have a 2.6.19.2 linux kernel.
Thank you,
Melinda.
---------------------------------
Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV.
[-- Attachment #2: Type: text/html, Size: 985 bytes --]
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Miroslaw Dach @ 2007-08-30 7:50 UTC (permalink / raw)
To: Grant Likely; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <fa686aa40708290817k897f8c2y5fdf12e5a48cc0ac@mail.gmail.com>
Hi All,
I have modified the linux kernel to have it smaller than I have
tried once again with bootm and uImage. The result is as shown below:
1. First I have downloaded u-boot via jtag:
XMD% dow u-boot.elf
section, .text: 0x01300000-0x0131513c
section, .resetvec: 0x0131513c-0x01315140
section, .rodata: 0x01315140-0x01317d10
section, .reloc: 0x01317e00-0x0131877c
section, .data: 0x0131877c-0x01318c40
section, .data.rel: 0x01318c40-0x01318c6c
section, .data.rel.local: 0x01318c6c-0x013190a4
section, .u_boot_cmd: 0x013190a4-0x01319314
section, .bss: 0x01319400-0x0131df04
Downloaded Program u-boot13Debug.elf
Setting PC with program start addr = 0x01300100
PC reset to 0x01300100, Clearing MSR Register
XMD% run
2. The u-boot has started properly
3. Than I have loaded via tftp the uImage
=> tftp 0xf00000 uImage
TFTP from server 129.117.144.113; our IP address is 129.117.144.157
Filename 'uImage'.
Load address: 0xf00000
Loading: #################################################################
#################################################################
##############################################################
done
Bytes transferred = 981900 (efb8c hex)
=> bootm 0xf00000
## Booting image at 00f00000 ...
Image Name: Linux-2.6.21-rc6
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 981836 Bytes = 958.8 kB
Load Address: 00400000
Entry Point: 00400000
Uncompressing Kernel Image ... OK
Bad trap at PC: c0002218, SR: 21030, vector=1100
NIP: C0002218 XER: 00000000 LR: 00400018 REGS: 01fc0578 TRAP: 1100 DAR: 01FF71AC
MSR: 00021030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
GPR00: C0002218 01FC0668 B022C01B C00003C0 C0000000 00000000 007FFF00 007FFF7C
GPR08: C1FD9AC0 01FC0C0C 0000AE58 01FFEEC4 01FBFCA0 FFFFFFFF 02000E00 00000001
GPR16: 007FFF7C 00400000 00800000 FFFFFFFF 007FFF00 01FFA104 00000000 01FC0760
GPR24: 00000002 007FFE80 00000001 007FFF7C 007FFF00 00000000 00000000 007FFE80
Call backtrace:
Exception in kernel pc c0002218 signal 0
4. I have stopped the system and I have reloaded u-boot to see what is in
the RAM memory:
My __log_buf (of uImage) is under the address :
c02070c4 b __log_buf
So I have dumped the data from this memory location:
=> md 0x2070c4 100
002070c4: 20257320 69732043 6f727235 70746564 %s is Corr5pted
002070d4: 20615400 25720000 7265646d 72654154 aT.%r..redmreAT
002070e4: 00000000 6b65322a 656c0004 67617465 ....ke2*el..gate
002070f4: 64000000 72614000 6d727400 6a652232 d...ra@.mrt.je"2
00207104: 61000000 62697264 00000000 2f655463 a...bird..../eTc
00207114: 2f497060 6b652465 322f7256 5f7052c5 /Ip`ke$e2/rV_pR.
00207124: 746f7100 676c2a62 616c0000 6e6f7748 toq.gl*bal..nowH
00207134: 65726500 73693465 00000200 27657462 ere.si4e....'etb
00207144: 2f697070 6f752065 322eaa50 5f73436f /ippou e2..P_sCo
00207154: 70655100 2f657022 2f697062 6f757441 peQ./ep"/ipboutA
00207164: 32277274 5b722121 6c6d7380 2f657413 2'rt[r!!lms./et.
00207174: 2f697872 6f357060 322f3264 5f647364 /ixro5p`2/2d_dsd
00207184: 69656c64 00000000 30782520 32780000 ield....0x% 2x..
00207194: 64656640 756c2400 2f653422 2f697070 def@ul$./e4"/ipp
002071a4: 6f757445 322f7274 5f746162 6c654300 outE2/rt_tableC.
002071b4: 10099124 100ae0d4 100aa0e8 100b1838 ...$...........8
002071c4: 100aa3e4 00000000 00000000 00000000 ................
002071d4: 100a6070 100ae0f8 100aa0ec 100ae100 ..`p............
I do not understand what is going on with my kernel image.
When I try to start zImage.elf with bootelf command the system hangs during
uncompressing.
When I try to start uImage with bootm command the image is uncompressed
but it does not start properly.
Any idea
Best Regards
Mirek
On Wed, 29 Aug 2007, Grant Likely wrote:
> On 8/29/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
> > Hi Grant,
> >
> > My zImage.elf has 1.1 MB and uImage 968 KB.
> > Could you tell me please how to hook up GDB to debug u-boot?
>
> Ah-HA! You're using the wrong type of kernel image. When booting
> from u-boot, you should be using a 'uImage', not a 'zImage.elf'.
> (generated with 'make uImage' in the kernel tree). An you should use
> the 'bootm' command to boot the kernel.
>
> With bootm, u-boot can pass parameters to the kernel and it is u-boot
> that does the uncompression (instead of the zImage wrapper).
>
> Cheers,
> g.
>
>
--
=============================================================================
Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group
PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================
^ permalink raw reply
* [POWERPC] PCI Bug fix for MRM failure in PPC 440EPx
From: Stefan Roese @ 2007-08-30 8:33 UTC (permalink / raw)
To: linuxppc-dev
Problem Description and Fix : Memory Read Multiples(MRM) do not work
correctly on PPC 440EPX based systems. A PCI driver determines whether
MRMs are supported by reading the PCI cache line size register. If this
value is zero then MRMs are not supported. However some PCI drivers
write to the PCI cache line size register on initialization. This
results in MRMs being sent to system memory on 440EPX based systems.
Since MRMs do not work correctly in 440EPX based systems this may cause
system hang. This patch solves this problem by modifying the PPC
platform specific PCI configuration register write function, by forcing
any value written to PCI_CACHE_LINE_SIZE register to be 0. This fix was
tested on different PCI cards : i.e. Silicon Image ATA card and Intel
E1000 GIGE card. On Silicon Image ATA card without this fix in place
creating a filesystem on IDE drive "mke2fs /dev/hda" was hanging the
system. MRMs issued by the PCI card were seen on the PCI analyzer since
the Silicon Image driver was setting the PCI_CACHE_LINE_SIZE register to
255. With this patch the PCI_CACHE_LINE_SIZE register was 0 and only
Memory Reads were seen on PCI analyzer.
Signed-off-by: Pravin M. Bathija <pbathija@amcc.com>
Signed-off-by: Stefan Roese <sr@denx.de>
---
I know this patch is a little "dirty", but perhaps somebody has a better
idea to fix this problem. Thanks.
commit bae603c964831f26d9816e85ffc923afc3275e44
tree 6fb93d22bcb56670a8e6f344afbe8a4a8438692c
parent b07d68b5ca4d55a16fab223d63d5fb36f89ff42f
author Stefan Roese <sr@denx.de> Thu, 30 Aug 2007 10:30:09 +0200
committer Stefan Roese <sr@denx.de> Thu, 30 Aug 2007 10:30:09 +0200
arch/powerpc/sysdev/indirect_pci.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/indirect_pci.c b/arch/powerpc/sysdev/indirect_pci.c
index 5294560..d694acc 100644
--- a/arch/powerpc/sysdev/indirect_pci.c
+++ b/arch/powerpc/sysdev/indirect_pci.c
@@ -128,6 +128,13 @@ indirect_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
* suitably aligned and that len is 1, 2 or 4.
*/
cfg_data = hose->cfg_data + (offset & 3);
+
+#if defined(CONFIG_440EPX) || defined(CONFIG_440GRX)
+ /* Workaround for MRM failure in 440EPx/GRx */
+ if (offset == PCI_CACHE_LINE_SIZE)
+ val = 0;
+#endif
+
switch (len) {
case 1:
out_8(cfg_data, val);
^ permalink raw reply related
* Re: [PATCH] ppc32/8xx: Fix r3 trashing due to 8MB TLB page instantiation
From: Jochen Friedrich @ 2007-08-30 8:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <611B8BA7-89B3-4DA0-A248-0FB57E4654ED@kernel.crashing.org>
Hi Kumar,
> do we need this in arch/powerpc as well?
No. At least not until these patches are applied to powerpc, as well:
8f069b1a90bd97bf6d59a02ecabf0173d9175609 [PATCH] powerpc/8xx: Use 8MB D-TLB's for kernel static mapping faults
3ea4807de7b2c5c903380ba2c2e7150bee942f42 [PATCH] powerpc/8xx: last two 8MB D-TLB entries are incorrectly set
c51e078f82096a7d35ac8ec2416272e843a0e1c4 [PATCH] ppc32/8xx: Fix r3 trashing due to 8MB TLB page instantiation
Thanks,
Jochen
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Oliver Rutsch @ 2007-08-30 9:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20070829233106.9766C24044@gemini.denx.de>
Hi again,
>
> As mentioned above, with arch/powerpc you always need a device tree
> blob.
>
> Best regards,
>
> Wolfgang Denk
>
Thanks, Wolfang, now it's booting fine!
I've updated u-boot to the newest git version, builded the device tree
file and now everything's working.
Bye,
--
Dipl. Ing. Oliver Rutsch
^ permalink raw reply
* Re: how to debug the linux kernel with a BDI2000
From: Detlev Zundel @ 2007-08-30 9:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <479723497.472031188208291804.JavaMail.coremail@bj163app103.163.com>
Hi Denny,
> My kernel hanged in when passed the parameters to it, and I dump nothing from
> the log_buf, so I guss it is crashed at the very beginning.
>
> however I didn't know how to setup the KDB to load the kernel with the BDI2000
> ethernet? is there anyone has even loaded and debugged the kernel with the
> BDI2000 ethernet? if so pls show me how it goes?
You don't need KDB to use the BDI2000 to debug a linux kernel, in fact
you need nothing on the target side. Simply attach the BDI to your
hardware, and use a (cross-)gdb with the "target remote
<ipaddr>:<port>" command. Our DULG shows how to do that with
U-Boot[1]. Debugging (static) Linux is exactly the same...
Cheers
Detlev
[1] http://www.denx.de/wiki/view/DULG/DebuggingUBoot
--
debian is a prototype for a future version of emacs.
-- Thien-Thi Nguyen in <7eekubiffq.fsf@ada2.unipv.it>
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-08-30 11:49 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
There are a couple more bug fixes for Cell plus one from Kumar, and
defconfig updates.
Paul.
arch/powerpc/configs/celleb_defconfig | 196 +----
arch/powerpc/configs/chrp32_defconfig | 220 ++----
arch/powerpc/configs/ebony_defconfig | 190 +----
arch/powerpc/configs/g5_defconfig | 208 ++---
arch/powerpc/configs/holly_defconfig | 203 ++---
arch/powerpc/configs/iseries_defconfig | 210 +----
arch/powerpc/configs/linkstation_defconfig | 219 ++----
arch/powerpc/configs/lite5200_defconfig | 191 +----
arch/powerpc/configs/maple_defconfig | 189 +----
arch/powerpc/configs/mpc7448_hpc2_defconfig | 202 +----
arch/powerpc/configs/mpc8272_ads_defconfig | 193 ++---
arch/powerpc/configs/mpc8313_rdb_defconfig | 224 ++----
arch/powerpc/configs/mpc832x_mds_defconfig | 209 ++---
arch/powerpc/configs/mpc832x_rdb_defconfig | 211 ++----
arch/powerpc/configs/mpc834x_itx_defconfig | 206 ++---
arch/powerpc/configs/mpc834x_itxgp_defconfig | 203 ++---
arch/powerpc/configs/mpc834x_mds_defconfig | 205 ++---
arch/powerpc/configs/mpc836x_mds_defconfig | 209 ++---
arch/powerpc/configs/mpc8540_ads_defconfig | 183 +----
arch/powerpc/configs/mpc8544_ds_defconfig | 459 +++++++++++-
arch/powerpc/configs/mpc8560_ads_defconfig | 196 +----
arch/powerpc/configs/mpc8568mds_defconfig | 43 -
arch/powerpc/configs/mpc85xx_cds_defconfig | 198 ++---
arch/powerpc/configs/mpc8641_hpcn_defconfig | 880 ++++++++++++++++++-----
arch/powerpc/configs/mpc866_ads_defconfig | 174 +----
arch/powerpc/configs/mpc885_ads_defconfig | 174 +----
arch/powerpc/configs/pasemi_defconfig | 225 ++----
arch/powerpc/configs/pmac32_defconfig | 237 ++----
arch/powerpc/configs/ppc64_defconfig | 220 ++----
arch/powerpc/configs/prpmc2800_defconfig | 213 ++----
arch/powerpc/configs/pseries_defconfig | 205 ++---
arch/powerpc/kernel/process.c | 6
arch/powerpc/platforms/cell/spu_manage.c | 8
arch/powerpc/platforms/cell/spufs/backing_ops.c | 3
arch/powerpc/platforms/cell/spufs/run.c | 6
arch/powerpc/platforms/ps3/setup.c | 3
36 files changed, 2846 insertions(+), 4275 deletions(-)
commit fc43dca9e75b87d24a16d5be7b497e83837d9d31
Author: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Date: Wed Aug 29 20:30:25 2007 +0900
[POWERPC] PS3: Fix bug where the major version part is not compared
Fix the bug that the major version part of the firmware version number
is ignored in the comparison done by ps3_compare_firmware_version
because the difference of two 64-bit quantities is returned as an int.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 13a6976afdb10d54ac5ad344aa0c588bc0bd8b0a
Author: Paul Mackerras <paulus@samba.org>
Date: Thu Aug 30 16:51:51 2007 +1000
[POWERPC] Update defconfigs
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit ada83daab31c3ec35845785482124373a62f430c
Author: Andre Detsch <adetsch@br.ibm.com>
Date: Tue Aug 21 10:06:22 2007 +0800
[POWERPC] spufs: Don't call spu_run_init from spu_reacquire_runnable
This fixes a major bug which was happening when a SPU thread advances
its execution right after being restored to a SPU. A potentially
outdated NPC value was being (re)written to the SPU.
So, spu_run_init, in this case, was either not doing anything relevant,
or breaking the execution of the SPU thread.
This fixes a common problem of losing a mailbox write when it was done
to a saved context.
Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 62ee68e3bcb0d056aae5b36dea0388ca25572cdf
Author: Arnd Bergmann <arnd@arndb.de>
Date: Tue Aug 21 10:06:22 2007 +0800
[POWERPC] spufs: Fix update of mailbox status register during backed wbox write
When a process writes into the inbound spu mailbox (wbox) while the
context is saved, we accidentally break the contents of the mb_stat_R
register by clearing other entries of the mailbox status register. This
can cause the user side to hang.
This change fixes the problem by only altering the appropriate bits
of the mailbox status register during a backing-store write.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit aac2e68481681a362ab6f44fc515034e2a4c7f2c
Author: Christian Krafft <krafft@de.ibm.com>
Date: Thu Aug 30 01:33:53 2007 +0200
[POWERPC] spu_manage: fix spu_unit_number for celleb device tree
This fixes a regression introduced with 2.6.23-rc4 after on some
confusion about the device tree interfaces.
IBM QS21 device trees provide "physical-id", so we changed the code to
run on that and remain compatible with all IBM machines.
However, the Toshiba Celleb device tree provides the "unit-id" property,
which was in the Linux code, but never used in this way on IBM hardware.
Legacy device tree used the reg property for the physical id of an spe.
This patch fixes find_spu_unit_number to look for the spu id in that order.
The length is checked to avoid misinterpretation in case the attributes
unit-id or reg do not contain the id.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Cc: Jeremy Kerr <jk@ozlabs.org>
commit 5cc44e086d7a4e20035997ec612678ca91f426e7
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Tue Aug 28 21:46:53 2007 -0500
[POWERPC] Update defconfigs
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 0ee6c15e7ba7b36a217cdadb292eeaf32a057a59
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Tue Aug 28 21:15:53 2007 -0500
[POWERPC] Flush registers to proper task context
When we flush register state for FP, Altivec, or SPE in flush_*_to_thread
we need to respect the task_struct that the caller has passed to us.
Most cases we are called with current, however sometimes (ptrace) we may
be passed a different task_struct.
This showed up when using gdbserver debugging a simple program that used
floating point. When gdb tried to show the FP regs they all showed up as
0, because the child's FP registers were never properly flushed to memory.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
^ permalink raw reply
* Re: spin_lock doesn't work?!?
From: Josh Boyer @ 2007-08-30 11:50 UTC (permalink / raw)
To: melinda develey; +Cc: linuxppc-embedded
In-Reply-To: <762949.1267.qm@web63906.mail.re1.yahoo.com>
On Wed, 29 Aug 2007 23:30:22 -0700 (PDT)
melinda develey <melinda.develey70@yahoo.com> wrote:
> >You should still put the spin_lock calls into your code because >you
> >never know if someone else will compile it and for another >target. If
> >someone would, for example, compile the same code for a SMP >machine then
> >the spin_lock will actually lock.
>
> I used the spinlock both in an interrupt handler to protect a group of variables (because in an interrupt I can't use a semaphore) and the same spinlock in a ioctl handler where the same group of variables is accessed. Is this wrong? I have a 2.6.19.2 linux kernel.
You might want to use spin_lock_irq instead. That will disable
interrupts in the critical section in the ioctl. Seems more like what
you are trying to do.
josh
^ permalink raw reply
* Re: Network is blocked till ping is issued
From: Andy Gospodarek @ 2007-08-30 12:52 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: Florian A. Voegel, linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8EA1869B@aquib01a>
On 8/30/07, DI BACCO ANTONIO - technolabs <Antonio.DiBacco@technolabs.it> wrote:
> > sounds to me like it could be a classical ARP problem. Have you
> checked the ARP cache on the non-Linux
> > machine?
>
> But if Linux received the SYN packet of TCP connection, shouldn't the
> Linux machine reply to the source mac address of SYN packet with a
> SYN,ACK packet?
>
No. You are confusing Ethernet frames and IP packets a little bit.
If a Linux machine receives a SYN from a remote host (not on the same
network) then the Linux machine needs to ARP for the router that is
listed as the default route in the routing table.
If no such default route exists, you will not be able to reach the
remote host. If the router doesn't reply to your ARP request, you
will not be able to reach the remote host.
Check to make sure you are not having either one of these problems.
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Grant Likely @ 2007-08-30 13:21 UTC (permalink / raw)
To: Miroslaw Dach; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0708300923140.12294-100000@slslc02.psi.ch>
On 8/30/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
>
> When I try to start zImage.elf with bootelf command the system hangs during
> uncompressing.
> When I try to start uImage with bootm command the image is uncompressed
> but it does not start properly.
Ugh, I'm stumped. Sorry. I'd spend some more quality time with your
debugger to trace the exact boot path.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC 440EPx: Initial Sequoia support
From: Valentine Barshak @ 2007-08-30 13:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <1188433699.3515.15.camel@localhost.localdomain>
Josh Boyer wrote:
> On Wed, 2007-08-29 at 17:35 +0400, Valentine Barshak wrote:
>> The following patches add initial PowerPC 440EPx Sequoia board support.
>> The code is based mainly on the Bamboo board support by Josh Boyer.
>> These patches have been modified according the comments for the previous
>> 440EPx Sequoia patch series.
>
> I see David has beaten me to reviewing the individual patches, which of
> course is always welcome. I just wanted add that I also think these
> look good. Thanks!
>
> josh
>
Thanks guys :)
Valentine
^ permalink raw reply
* Re: dtc: Fix summary calculation in testsuite
From: Jon Loeliger @ 2007-08-30 13:51 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070829021851.GA25233@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> The bookkeeping for producing the testsuite summary (total number of
> tests passed, failed and so forth) is broken. It uses $? across
> several tests, but for checks after the first, the value of $? will no
> longer contain the original return code, but just that from the
> previous test. This patch fixes the problem.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: libfdt: Fix handling of trailing / in fdt_path_offset()
From: Jon Loeliger @ 2007-08-30 13:52 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070829022250.GA25468@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Currently, fdt_path_offset() returns FDL_ERR_BADOFFSET if given a path
> with a trailing '/'. In particular this means that
> fdt_path_offset("/") returns FDT_ERR_BADOFFSET rather than 0 as one
> would expect.
>
> This patch fixes the function to accept and ignore trailing '/'
> characters. As well as allowing fdt_path_offset("/") this means that
> fdt_path_offset("/foo/") will return the same as
> fdt_path_offset("/foo") which seems in keeping with the principle of
> least surprise.
>
> This also adds a testcase to ensure that fdt_path_offset("/") returns
> 0 as it should.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: libfdt: Several new functions
From: Jon Loeliger @ 2007-08-30 13:52 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070830045253.GA32543@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This series of patches adds several new functions to libfdt. These
> are all read-only functions related to determining a given nodes node
> and ancestry.
All three pplied.
Thanks,
jdl
^ permalink raw reply
* RE: Network is blocked till ping is issued
From: DI BACCO ANTONIO - technolabs @ 2007-08-30 13:59 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Florian A. Voegel, linuxppc-embedded
In-Reply-To: <bdfc5d6e0708300552g71a995c9x10f17322613ca9c1@mail.gmail.com>
>No. You are confusing Ethernet frames and IP packets a little bit.
>If a Linux machine receives a SYN from a remote host (not on the same
>network) then the Linux machine needs to ARP for the router that is
>listed as the default route in the routing table.
>If no such default route exists, you will not be able to reach the
>remote host. If the router doesn't reply to your ARP request, you
>will not be able to reach the remote host.
>Check to make sure you are not having either one of these problems.
I'm on the same network: NotLinux is 100.1.0.1 and Linux is 100.1.0.2
with netmask 255.255.255.0
Thank you,
Antonio.
^ permalink raw reply
* Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions
From: Joachim Fenkes @ 2007-08-30 14:00 UTC (permalink / raw)
To: jschopp, Nathan Lynch
Cc: Thomas Q Klein, Paul Mackerras, Jan-Bernd Themann, LKML,
LinuxPPC-Dev, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <46D5BBFA.5060200@austin.ibm.com>
Nathan Lynch <ntl@pobox.com> wrote on 29.08.2007 20:12:32:
> > Previously, ibmebus derived a device's bus_id from its location code.
The
> > location code is not guaranteed to be unique, so we might get bus_id
> > collisions if two devices share the same location code. The OFDT
full_name,
> > however, is unique, so we use that instead.
>
> This is a userspace-visible change, but I guess it's unavoidable.
> Will anything break?
Nope. Userspace programs should not depend on ibmebus' way of naming the
devices; especially since some overly long loc_codes tended to be
truncated and thus rendered useless. I have tested IBM's DLPAR tools
against the changed kernel, and they didn't break.
> Also, I dislike this approach of duplicating the firmware device tree
> path in sysfs.
Why? Any specific reasons for your dislike?
> Are GX/ibmebus devices guaranteed to be children of
> the same node in the OF device tree? If so, their unit addresses will
> be unique, and therefore suitable values for bus_id. I believe this
> is what the powerpc vio bus code does.
While there's no such guarantee (as in "officially signed document"), yes,
I expect future GX devices to also appear beneath the OFDT root node. For
the existing devices, the unit addresses are already part of the device
name, so I save the need to use sprintf() again. Plus, I rather like using
the full_name since it also contains a descriptive name as opposed to
being just nondescript numbers, helping the layman (ie user) to make sense
out of a dev_id.
jschopp <jschopp@austin.ibm.com> wrote on 29.08.2007 20:33:30:
> > + len = strlen(dn->full_name + 1);
> > + bus_len = min(len, BUS_ID_SIZE - 1);
> > + memcpy(dev->ofdev.dev.bus_id, dn->full_name + 1
> > + + (len - bus_len), bus_len);
> > + for (i = 0; i < bus_len; i++)
> > + if (dev->ofdev.dev.bus_id[i] == '/')
> > + dev->ofdev.dev.bus_id[i] = '_';
> >
> > /* Register with generic device framework. */
> > if (ibmebus_register_device_common(dev, dn->name) != 0) {
>
> What happens when the full name is > 31 characters? It looks to me that
it
> will be truncated, which takes away the uniqueness guarantee.
There are currently two GX devices, eHCA and eHEA, which both reside
beneath the root node - this is required by architecture for those
devices. Unless they invent a device called
"supercalifragilisticexpialidocious", devices in the root note will have a
full_name of less than 31 chars. Even in that case, the truncation occurs
at the beginning, so the @xxx part that makes the nodes unique will stay
in place.
If any more GX devices appear on the scene, I expect them to appear in the
root node as well. The substitution of "/" by "_" is a safeguard so
possible weird OFDT setups don't break the kernel.
> There must be an individual property that is guaranteed to be unique and
> less than 32 characters. How about "ibm,my-drc-index"? That looks like
a
> good candidate.
On first glance, it does, however the attribute might not be present in
all cases. Architecture states it only needs to be present on systems with
dynamic reconfiguration enabled.
All things considered, I still like the idea of using the full_name most.
No offense.
Regards,
Joachim
^ permalink raw reply
* Re: [PATCH 2/3] Introduce new CPM device bindings.
From: Scott Wood @ 2007-08-30 14:10 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20070830055812.GB32543@localhost.localdomain>
On Thu, Aug 30, 2007 at 03:58:12PM +1000, David Gibson wrote:
> On Thu, Aug 30, 2007 at 12:48:54AM -0500, Scott Wood wrote:
> > On Thu, Aug 30, 2007 at 10:55:59AM +1000, David Gibson wrote:
> > > Am I correct in thinking that it's basically an arch/ppc versus
> > > arch/powerpc thing. In which case couldn't you use CONFIG_PPC_MERGE
> > > instead?
> >
> > The idea was to allow boards to be converted incrementally, as I don't
> > have access to test 100% of the boards that use the CPM code.
>
> Hrm. Right. This is still problematical, because what happens if you
> have both old-binding and new-binding boards configured simultaneously?
Multiplatform will not be supported for old-binding boards.
-Scott
^ permalink raw reply
* Re: [PATCH 6/9] bootwrapper: Add a zImage.bin.<platform> target.
From: Scott Wood @ 2007-08-30 14:21 UTC (permalink / raw)
To: paulus, linuxppc-dev
In-Reply-To: <20070830003409.GE21072@localhost.localdomain>
On Thu, Aug 30, 2007 at 10:34:09AM +1000, David Gibson wrote:
> Hrm.. I think the --binary option at least should be removed, and
> subsumed into the platform id - all other binary formats are selected
> by the platform name at present.
>
> And I think it's probably best to do that for --fixed-entry as well,
> although it's a bit less clear there.
I'm not particularly fond of having huge platform switch blocks in the
wrapper script -- if it can be reasonably parameterized, why not do so?
-Scott
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Kumar Gala @ 2007-08-30 14:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, torvalds
In-Reply-To: <18134.44726.426680.221570@cargo.ozlabs.ibm.com>
On Aug 30, 2007, at 6:49 AM, Paul Mackerras wrote:
> Linus,
>
> Please do
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> There are a couple more bug fixes for Cell plus one from Kumar, and
> defconfig updates.
>
> Paul.
any reason you didn't pull this into your master branch as well, or
will just wait to do that after linus pulls?
- k
^ permalink raw reply
* Re: Xilinx Virtex boot
From: Robert Woodworth @ 2007-08-30 14:44 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708291729j3f63a57dl32e5d4df647326b5@mail.gmail.com>
On Wed, 2007-08-29 at 18:29 -0600, Grant Likely wrote:
> On 8/29/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> > I'm trying to port Linux to a new Virtex Platform. The kernel will not
> > uncompress, I get the following on the console:
> >
> > loaded at: 00400000 004FB19C
> > board data at: 004F9120 004F919C
> > relocated to: 00404054 004040D0
> > zimage at: 00404E50 004F8409
> > avail ram: 004FC000 04000000
> >
> > Linux/PPC load: console=ttyUL root=/dev/xsa2
> > Uncompressing Linux...
> > zlib_inflateInit2 returned 00506530
> > exit
> >
> > Any ideas what causes this error??
> > Is something mis-configured on my EDK project?
> >
>
> Possibly, do you know that EDK has your ram is configured correctly
> (ie. have you run a memory test application)?
Yes, I ran the sample memory test application that EDK builds
automatically. It ran fine.
The fact that the above prints on the console, tells me that the
zImage.elf is getting loaded at the correct start location and that its
partly executing.
What is the return code that I'm seeing?? I have been unable to figure
that out from the source yet.
> >
> > I have 64MB DDR on the OPB *not* the PLB.
> > Is that a problem??
>
> It shouldn't be the problem, but why are you doing that?
We are building an image-processing application inside the FPGA. The
application is very memory intensive. I have been told that the PPC
always has priority on the PLB and that if I want to have my FPGA module
have priority on memory, that I should place the memory and my FPGA
module on the OPB. Yes, this can significantly slow down the PPC, but
in my case the PPC is only used for UI and networking.
I will actually build in *two* OPBs one for the memory + my module and
the second for the other peripherals.
Woody.
^ permalink raw reply
* Re: Xilinx Virtex boot
From: Robert Woodworth @ 2007-08-30 14:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708291729j3f63a57dl32e5d4df647326b5@mail.gmail.com>
On Wed, 2007-08-29 at 18:29 -0600, Grant Likely wrote:
> On 8/29/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> > I'm trying to port Linux to a new Virtex Platform. The kernel will not
> > uncompress, I get the following on the console:
> >
> > loaded at: 00400000 004FB19C
> > board data at: 004F9120 004F919C
> > relocated to: 00404054 004040D0
> > zimage at: 00404E50 004F8409
> > avail ram: 004FC000 04000000
> >
> > Linux/PPC load: console=ttyUL root=/dev/xsa2
> > Uncompressing Linux...
> > zlib_inflateInit2 returned 00506530
> > exit
> >
> > Any ideas what causes this error??
> > Is something mis-configured on my EDK project?
> >
>
> Possibly, do you know that EDK has your ram is configured correctly
> (ie. have you run a memory test application)?
>
>
> >
> > I have 64MB DDR on the OPB *not* the PLB.
> > Is that a problem??
>
> It shouldn't be the problem, but why are you doing that?
I did notice in my configuration, that when the memory is on the PLB it
has an interrupt flag and when it's on the OPB it doesn't. What is the
interrupt for? DMA's?
Could Linux be doing a DMA in the uncompression where the lack of an
interrupt causes and error?
^ permalink raw reply
* Re: [PATCH 8/9] mpc82xx: Update mpc8272ads, and factor out PCI and reset.
From: Kumar Gala @ 2007-08-30 14:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070830055644.GA21604@ld0162-tx32.am.freescale.net>
On Aug 30, 2007, at 12:56 AM, Scott Wood wrote:
> On Wed, Aug 29, 2007 at 05:41:17PM -0500, Kumar Gala wrote:
>> NACK.
>>
>> I don't want pq2 to be the only platform that has the PCI bus
>> separate from the PCI controller.
>
> Could you articulate the reasons why you'd rather have a mishmash
> of crap
> in the soc node's ranges property?
It don't feel its a mishmash of crap its just how things are
defined. Maybe the SOC node was a mistake, but I think we are past
the point of return on that.
Having one platform's device tree be different just creates confusion
to our customers. While there isn't anything technically wrong with
what your proposing it will cause support issues down the line which
I want to avoid.
- k
^ permalink raw reply
* Re: Xilinx Virtex boot
From: Grant Likely @ 2007-08-30 15:02 UTC (permalink / raw)
To: Robert Woodworth; +Cc: linuxppc-embedded
In-Reply-To: <1188485072.8717.42.camel@PisteOff>
On 8/30/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> On Wed, 2007-08-29 at 18:29 -0600, Grant Likely wrote:
> > On 8/29/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> > > I'm trying to port Linux to a new Virtex Platform. The kernel will not
> > > uncompress, I get the following on the console:
> > >
> > > loaded at: 00400000 004FB19C
> > > board data at: 004F9120 004F919C
> > > relocated to: 00404054 004040D0
> > > zimage at: 00404E50 004F8409
> > > avail ram: 004FC000 04000000
> > >
> > > Linux/PPC load: console=ttyUL root=/dev/xsa2
> > > Uncompressing Linux...
> > > zlib_inflateInit2 returned 00506530
> > > exit
> > >
> > > Any ideas what causes this error??
> > > Is something mis-configured on my EDK project?
> > >
> >
> > Possibly, do you know that EDK has your ram is configured correctly
> > (ie. have you run a memory test application)?
>
> Yes, I ran the sample memory test application that EDK builds
> automatically. It ran fine.
>
> The fact that the above prints on the console, tells me that the
> zImage.elf is getting loaded at the correct start location and that its
> partly executing.
>
> What is the return code that I'm seeing?? I have been unable to figure
> that out from the source yet.
IIRC, the return code is the result of the CRC calculation. If it is
non-zero, then the CRC was incorrect. That says to me that you've got
either memory or download issues.
I have seen corruption in the past when downloading zImages larger
than about 1.2MB over JTAG.
> > > I have 64MB DDR on the OPB *not* the PLB.
> > > Is that a problem??
> >
> > It shouldn't be the problem, but why are you doing that?
>
> We are building an image-processing application inside the FPGA. The
> application is very memory intensive. I have been told that the PPC
> always has priority on the PLB and that if I want to have my FPGA module
> have priority on memory, that I should place the memory and my FPGA
> module on the OPB. Yes, this can significantly slow down the PPC, but
> in my case the PPC is only used for UI and networking.
<offtopic> You might want to take a look at the MPMC ipcore. It
allows multiple PLBs to address a single memory region.</offtopic>
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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