* Re: simple ELF bootloader for embedded xilinx linux ?
From: Michael Galassi @ 2006-09-11 21:20 UTC (permalink / raw)
To: rimas; +Cc: linuxppc-embedded
In-Reply-To: <1354DD02-657B-4777-8378-BC408DA3D800@cnmat.berkeley.edu>
>whats the best/easiest way for me to boot from an ELF file in the
>flash ? i'm aware of u-boot but it seems like overkill for this
>application. however if it would work and the footprint is
>relatively small i could give it a try. i imagine i could write my
>own bootloader, i just thought i'd ask first to avoid reinventing the
>wheel.
If you're using the zImage file the only bootloader you need is an
unconditional, unlinked branch to the first instruction you want to
execute in the zImage located at -4 (0xfffffffc). To save a few extra
bytes you can strip the ELF header from the zImage, then you flash it
at the same address you jump to. I do that with objcopy:
make zImage && \
ppc_405-objcopy -O binary arch/ppc/boot/images/zImage.elf zImage.bin
Remember that the first instruction of the kernel must reside within
your relative jump limit if you take this approach. If you place your 3
meg kernel right below the branch instruction you'll have no problems
with this at all. If you prefer mapping your flash lower down and use a
blockram (or whatever) for your boot-code you can branch a dozen bytes
backward in the instruction at -4 and have an absolute branch there
which could reach anyplace in your address space.
>another somewhat related question is whether i can use a portion of
>the flash (the part thats left over after the kernel/root fs image is
>programmed) as nonvolatile storage using the JFFS2 filesystem ?
>anyone have any pointers to information on how to set this up ?
Most flash must be erased in 128K blocks, once two are paired to yield
a 32bit wide data bus you'll find yourself segmenting your space into
256K blocks. I use an integral number of these blocks for a cramfs
image, I see no reason you shouldn't do the same for a jffs2. Just be
careful not to accidentally write past the space you allocate to your
filesystem and onto your boot-code, kernel, and what ever else you place
in flash. Since bricking(*) a system is viewed as a bad thing we don't
allow writes to the filesystem in flash, we instead write entire images
at once in carefully controlled conditions.
An over-simplified flash map ends up looking something like:
"size-4bytes" branch instruction to "top-4meg"
"size-4meg" kernel stripped of elf header
"size-20meg" filesystem image
"0" bitstream loaded into FPGA at power-up
Adjust the sizes to fit your kernel size, filesystem size, bistream
size, and to accommodate the flash size you're using and other data
you might with to store in flash.
(*) brick (verb) to render functionally brick-like
-michael
^ permalink raw reply
* Re: simple ELF bootloader for embedded xilinx linux ?
From: rimas @ 2006-09-11 22:53 UTC (permalink / raw)
To: Michael Galassi; +Cc: linuxppc-embedded
In-Reply-To: <200609112120.k8BLKnFF097143@penguin.ncube.com>
On Mon, 11 Sep 2006 14:20:49 -0700
Michael Galassi <mgalassi@c-cor.com> wrote:
>>whats the best/easiest way for me to boot from an ELF file in the
>>flash ? i'm aware of u-boot but it seems like overkill for this
>>application. however if it would work and the footprint is
>>relatively small i could give it a try. i imagine i could write my
>>own bootloader, i just thought i'd ask first to avoid reinventing the
>>wheel.
>
> If you're using the zImage file the only bootloader you need is an
> unconditional, unlinked branch to the first instruction you want to
> execute in the zImage located at -4 (0xfffffffc). To save a few extra
> bytes you can strip the ELF header from the zImage, then you flash it
> at the same address you jump to. I do that with objcopy:
> make zImage && \
> ppc_405-objcopy -O binary arch/ppc/boot/images/zImage.elf zImage.bin
>
> Remember that the first instruction of the kernel must reside within
> your relative jump limit if you take this approach. If you place your 3
> meg kernel right below the branch instruction you'll have no problems
> with this at all. If you prefer mapping your flash lower down and use a
> blockram (or whatever) for your boot-code you can branch a dozen bytes
> backward in the instruction at -4 and have an absolute branch there
> which could reach anyplace in your address space.
Thanks for clarifying that for me ! Using objcopy to create a binary file,
flashing the binary file and then jumping to the start of the flash works
perfectly.
>
>>another somewhat related question is whether i can use a portion of
>>the flash (the part thats left over after the kernel/root fs image is
>>programmed) as nonvolatile storage using the JFFS2 filesystem ?
>>anyone have any pointers to information on how to set this up ?
>
> Most flash must be erased in 128K blocks, once two are paired to yield
> a 32bit wide data bus you'll find yourself segmenting your space into
> 256K blocks. I use an integral number of these blocks for a cramfs
> image, I see no reason you shouldn't do the same for a jffs2. Just be
> careful not to accidentally write past the space you allocate to your
> filesystem and onto your boot-code, kernel, and what ever else you place
> in flash. Since bricking(*) a system is viewed as a bad thing we don't
> allow writes to the filesystem in flash, we instead write entire images
> at once in carefully controlled conditions.
>
Thanks for pointing out the potential risks in using the same flash as a
read/write filesystem and storage for the kernel/root filesystem/etc. I hadn't
considered that. I only need minimal low speed non volatile storage so maybe
I'll use an eeprom or something instead for the sake of reliability.
-rimas
> An over-simplified flash map ends up looking something like:
> "size-4bytes" branch instruction to "top-4meg"
> "size-4meg" kernel stripped of elf header
> "size-20meg" filesystem image
> "0" bitstream loaded into FPGA at power-up
>
> Adjust the sizes to fit your kernel size, filesystem size, bistream
> size, and to accommodate the flash size you're using and other data
> you might with to store in flash.
>
> (*) brick (verb) to render functionally brick-like
>
> -michael
^ permalink raw reply
* Re: [PATCH] Prevent legacy io access on pmac
From: Benjamin Herrenschmidt @ 2006-09-11 23:11 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060911151730.GA25244@aepfle.de>
On Mon, 2006-09-11 at 17:17 +0200, Olaf Hering wrote:
> On Mon, Sep 11, Olaf Hering wrote:
>
> > * add check for parport_pc, exit on pmac.
>
> How do I allow parport on PCI cards?
Doesn't the driver have explicit PCI probing like 8250 ?
Ben.
^ permalink raw reply
* Re: [PATCH] Prevent legacy io access on pmac
From: Benjamin Herrenschmidt @ 2006-09-11 23:14 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060911115354.GA23884@aepfle.de>
On Mon, 2006-09-11 at 13:53 +0200, Olaf Hering wrote:
> The ppc32 common config runs also on PReP/CHRP, which uses PC style IO
> devices. The probing is bogus, it crashes or floods dmesg.
>
> ppc can boot one single binary on prep, chrp and pmac boards.
> ppc64 can boot one single binary on pseries and G5 boards.
> pmac has no legacy io, probing for PC style legacy hardware leads to a
> hard crash:
>
> * add check for parport_pc, exit on pmac.
> 32bit chrp has no ->check_legacy_ioport, the probe is always called.
> 64bit chrp has check_legacy_ioport, check for a "parallel" node
>
> * add check for isapnp, only PReP boards may have real ISA slots.
> 32bit PReP will have no ->check_legacy_ioport, the probe is always called.
>
> * update code in i8042_platform_init. Run ->check_legacy_ioport first, always
> call request_region. No functional change. Remove whitespace before i8042_reset init.
>
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
Looks good to me.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* SM501 Kernel display driver for v2.6.17
From: Suzuki Takashi @ 2006-09-12 4:24 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I want to make Voyager GX PCI Demo Board Ver.A work on Yosemite board.
I know Silicon Motion have Linux Kernel_v2.6 Display driver:
http://www.siliconmotion.com.tw/en/en2/download2c.htm
But it's for v2.6.4 and it cannot be compiled with v2.6.17 working on
Yosemite board.
Does anybody have succeeded in making the board work with v2.6.17?
If there is a patch or source code available, let me know the location.
Thanks in advance,
-- T.Suzuki
^ permalink raw reply
* Fix interrupt clearing in kdump shutdown sequence
From: Mohan Kumar M @ 2006-09-12 12:18 UTC (permalink / raw)
To: linuxppc-dev, fastboot, mingo, torvalds, paulus
Hi,
Some times HVC console on a PPC machine may have pending interrupts and
in this case kdump shutdown sequence created problem by calling
chip->end. This should be chip->eoi(). The attached patch fixes this
issue. Tested on POWER5 box.
Patch generated on 2.6.18-rc6-git4.
It will be helpful if this patch is included in 2.6.18.
Regards,
Mohan.
Call chip->eoi(irq) to clear any pending interrupt in case of kdump shutdown
sequence. chip->end(irq) does not solve this purpose.
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
---
linux-2.6.18-rc6-git4/arch/powerpc/kernel/crash.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN linux-2.6.18-rc6-git4/arch/powerpc/kernel/crash.c~kdump-irq-fix linux-2.6.18-rc6-git4/arch/powerpc/kernel/crash.c
--- kernel/linux-2.6.18-rc6-git4/arch/powerpc/kernel/crash.c~kdump-irq-fix 2006-09-12 17:20:39.000000000 +0530
+++ kernel-mohan/linux-2.6.18-rc6-git4/arch/powerpc/kernel/crash.c 2006-09-12 17:20:51.000000000 +0530
@@ -295,7 +295,7 @@ void default_machine_crash_shutdown(stru
struct irq_desc *desc = irq_desc + irq;
if (desc->status & IRQ_INPROGRESS)
- desc->chip->end(irq);
+ desc->chip->eoi(irq);
if (!(desc->status & IRQ_DISABLED))
desc->chip->disable(irq);
_
^ permalink raw reply
* Re: Reminder: [PATCH] Add new, missing argument to of_irq_map_raw().
From: Paul Mackerras @ 2006-09-12 12:27 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1GMlqi-0001PS-33@jdl.com>
Jon Loeliger writes:
> I just wanted to check with you that this patch isn't
> slipping through the cracks as we close out 2.6.18.
> Without this, the 86xx build is broken, of course.
Thanks for the reminder. I'll send it on.
Paul.
^ permalink raw reply
* Re: SM501 Kernel display driver for v2.6.17
From: Sergei Shtylyov @ 2006-09-12 13:00 UTC (permalink / raw)
To: Suzuki Takashi; +Cc: Linux-MIPS, linuxppc-embedded
In-Reply-To: <BDCC9646-9F98-4FFC-B0D8-A73E05B799A4@emi.yamaha.co.jp>
Hello.
Suzuki Takashi wrote:
> I want to make Voyager GX PCI Demo Board Ver.A work on Yosemite board.
> I know Silicon Motion have Linux Kernel_v2.6 Display driver:
> http://www.siliconmotion.com.tw/en/en2/download2c.htm
> But it's for v2.6.4 and it cannot be compiled with v2.6.17 working on
> Yosemite board.
> Does anybody have succeeded in making the board work with v2.6.17?
> If there is a patch or source code available, let me know the location.
I know that Linux/MIPS project maintains the framebuffer driver in
drivers/video/smivgxfb.c. We used to backport it to 2.6.10 and it worked for
us... Here's the link to the latest source:
http://www.linux-mips.org/git?p=linux.git;a=blob;h=c521069c905b4252109b8144478b4381c0ccdb7f;hb=db092db967ec0824db433c4adf3b58202fe610e2;f=drivers/video/smivgxfb.c
> Thanks in advance,
> -- T.Suzuki
WBR, Sergei
^ permalink raw reply
* Linux on custom Xilinx board with PPC405 hangs on boot
From: Peter N. Andreasen @ 2006-09-12 14:06 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]
I have an FPGA board which is based on the Xilinx ML300 board but without
disk and display. It has 4MB flash, and 32MB SDRAM, and uses the uartlite
serial port.
The RAM is located at 0x0000'0000 - 0x01FF'FFFF
I downloaded the kernel from Montavista, built a board support package in
Xilinx Platform Studio, and managed to configure and build the kernel.
However when I transfer the resulting zImage.elf file to the board, the
attached terminal only shows:
loaded at: 00040000 00D4140E
board data at: 00D41183 00D41105
relocated to: 0004258F 00043501
zimage at: 00048550 0074E751
initrd at: 00740800 00D420FF
avail ram: 00D40500 20000000
Linux/PPC load: root=/dev/ram rw console=/dev/ttyS0
Uncompressing Linux...done.
Now booting the kernel
and then it dies.
In the debug window I have this:
XMD% dow c:/Hardi/zImage.initrd.elf
section, .text: 0x00400000-0x004047b8
section, .data: 0x00405000-0x004d1000
section, .bss: 0x004d1000-0x004d41e0
Downloading ELF File c:/Hardi/zImage.initrd.elf
Program header record #0, Size = 0xD1000.
Downloading program section : Start = 0x00400000, length = 0x000d1000
Downloaded Program c:/Hardi/zImage.initrd.elf
Setting PC with program start addr = 0x00400000
PC reset to 0x00400000, Clearing MSR Register
XMD% con
Processor started. Type "stop" to stop processor
RUNNING> stop
XMD%
Processor stopped at PC: 0x6fbf0700
XMD% dis 0x6fbf0700
6FBF0700: 00000000
XMD%
so it looks like the processor somewhere is sent out in space -
Does anyone have an idea how to find the problem?
Peter
[-- Attachment #2: Type: text/html, Size: 1934 bytes --]
^ permalink raw reply
* How to find I2C address?
From: Sachin Rane @ 2006-09-12 14:13 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Murali Sampath
[-- Attachment #1: Type: text/plain, Size: 261 bytes --]
Hi,
I am using AMCC PPC440GX evaluation board.
I want to access serial EEPROM (AP31_U29) present on the board.
I couldn't find the I2C address for this chip in the board manuals.
Could you tell me where I can find it?
Regards,
SAchin Rane
[-- Attachment #2: Type: text/html, Size: 977 bytes --]
^ permalink raw reply
* Re: How to find I2C address?
From: Ben Warren @ 2006-09-12 14:44 UTC (permalink / raw)
To: Sachin Rane; +Cc: Murali Sampath, linuxppc-embedded
In-Reply-To: <8584FDC94AFF7640B17B8A89B23B19B34F655C@sbsserver.AlphionCorp.local>
On Tue, 2006-09-12 at 10:13 -0400, Sachin Rane wrote:
> Hi,
>
> I am using AMCC PPC440GX evaluation board.
> I want to access serial EEPROM (AP31_U29) present on the board.
> I couldn't find the I2C address for this chip in the board manuals.
>
> Could you tell me where I can find it?
>
These things typically have 1 to 3 address pins that are pulled up or
down on the board, with a base address of 0x50. In other words, it's
probably between 0x50 and 0x57. To be sure, download the datasheet from
the chip vendor, and look on your board's schematics to see how the
address pins are tied.
There are various ways of probing the bus to get the info indirectly,
but you should really be familiar with your hardware first.
regards,
Ben
^ permalink raw reply
* [PATCH] Export copy_4K_page()
From: David Howells @ 2006-09-12 15:04 UTC (permalink / raw)
To: linuxppc-dev
Export copy_4K_page() for use by modules via copy_page() (such as CacheFiles).
Signed-Off-By: David Howells <dhowells@redhat.com>
---
arch/powerpc/kernel/ppc_ksyms.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index 39d3bfc..b2edac8 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -91,6 +91,9 @@ EXPORT_SYMBOL(__copy_tofrom_user);
EXPORT_SYMBOL(__clear_user);
EXPORT_SYMBOL(__strncpy_from_user);
EXPORT_SYMBOL(__strnlen_user);
+#ifdef CONFIG_PPC64
+EXPORT_SYMBOL(copy_4K_page);
+#endif
#ifndef __powerpc64__
EXPORT_SYMBOL(__ide_mm_insl);
^ permalink raw reply related
* How to move from /ppc/ to /powerpc/
From: Fredrik Roubert @ 2006-09-12 15:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
Hi!
I have a custom board on which I currently run Linux 2.6.18-rc6
configured for MPC834x_SYS in the /ppc/ tree, which just a few minor
changes. Now I'm interested to move to using the /powerpc/ source tree
instead, but I can't figure out exactly what steps are necessary to do
this.
Does anyone run a MPC834x_SYS built with ARCH=powerpc?
I boot the board with U-Boot (version 1.1.4, customized), and I assume
that I need to add some stuff for this new device tree thing, but I
can't figure out exactly what the kernel will expect.
Does anyone have some pointers on how to do this?
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
[-- Attachment #2: Type: application/pgp-signature, Size: 303 bytes --]
^ permalink raw reply
* Re: Linux on custom Xilinx board with PPC405 hangs on boot
From: Andrei Konovalov @ 2006-09-12 15:53 UTC (permalink / raw)
To: Peter N. Andreasen; +Cc: linuxppc-dev
In-Reply-To: <36468a5c0609120706i6c7e32efke7d8901d9ce4ae9b@mail.gmail.com>
Peter N. Andreasen wrote:
> I have an FPGA board which is based on the Xilinx ML300 board but
> without disk and display. It has 4MB flash, and 32MB SDRAM, and uses the
> uartlite serial port.
> The RAM is located at 0x0000'0000 - 0x01FF'FFFF
> I downloaded the kernel from Montavista, built a board support package
> in Xilinx Platform Studio, and managed to configure and build the kernel.
> However when I transfer the resulting zImage.elf file to the board, the
> attached terminal only shows:
>
> loaded at: 00040000 00D4140E
> board data at: 00D41183 00D41105
> relocated to: 0004258F 00043501
> zimage at: 00048550 0074E751
> initrd at: 00740800 00D420FF
> avail ram: 00D40500 20000000
>
> Linux/PPC load: root=/dev/ram rw console=/dev/ttyS0
...
"console=ttyS0" (not "/dev/ttyS0" BTW) is for 16x50 compatible UART.
UartLite needs something like "console=ttl0".
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Kim Phillips @ 2006-09-12 15:58 UTC (permalink / raw)
To: Fredrik Roubert; +Cc: linuxppc-embedded
In-Reply-To: <20060912153316.GC16340@igloo.df.lth.se>
On Tue, 12 Sep 2006 17:33:16 +0200
Fredrik Roubert <roubert@df.lth.se> wrote:
> Hi!
>
> I have a custom board on which I currently run Linux 2.6.18-rc6
> configured for MPC834x_SYS in the /ppc/ tree, which just a few minor
> changes. Now I'm interested to move to using the /powerpc/ source tree
> instead, but I can't figure out exactly what steps are necessary to do
> this.
>
> Does anyone run a MPC834x_SYS built with ARCH=powerpc?
>
yes
> I boot the board with U-Boot (version 1.1.4, customized), and I assume
> that I need to add some stuff for this new device tree thing, but I
> can't figure out exactly what the kernel will expect.
the kernel expects a pointer to a device tree instead of a bd_t. The 8349EMDS device tree source is now in linux/arch/powerpc/boot/dts. You'll need the device tree compiler (dtc) from jdl.com to build your flat device tree binary (dtb; what the kernel expects).
>
> Does anyone have some pointers on how to do this?
>
Matt's u-boot patches address the issue well for 85xx, they are straightforward to adapt to 83xx:
http://sourceforge.net/mailarchive/forum.php?thread_id=15518792&forum_id=12898
they allow you to tftp the dtb into mem, and "bootm ${loadaddr} - ${oftaddr}" to start an ARCH=powerpc kernel.
> Cheers // Fredrik Roubert
Kim
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Jon Loeliger @ 2006-09-12 16:03 UTC (permalink / raw)
To: Fredrik Roubert, linuxppc-embedded@ozlabs.org
In-Reply-To: <20060912105830.3923d537.kim.phillips@freescale.com>
On Tue, 2006-09-12 at 10:58, Kim Phillips wrote:
> > I boot the board with U-Boot (version 1.1.4, customized), and I assume
> > that I need to add some stuff for this new device tree thing, but I
> > can't figure out exactly what the kernel will expect.
>
> the kernel expects a pointer to a device tree instead of a bd_t.
> The 8349EMDS device tree source is now in linux/arch/powerpc/boot/dts.
> You'll need the device tree compiler (dtc) from jdl.com to build
> your flat device tree binary (dtb; what the kernel expects).
And you should read:
linux-2.6/Documentation/powerpc/booting-without-of.txt
jdl
^ permalink raw reply
* Re: How to move from /ppc/ to /powerpc/
From: Vitaly Bordug @ 2006-09-12 16:20 UTC (permalink / raw)
To: Fredrik Roubert; +Cc: linuxppc-embedded
In-Reply-To: <20060912153316.GC16340@igloo.df.lth.se>
On Tue, 12 Sep 2006 17:33:16 +0200
Fredrik Roubert <roubert@df.lth.se> wrote:
> Hi!
>
> I have a custom board on which I currently run Linux 2.6.18-rc6
> configured for MPC834x_SYS in the /ppc/ tree, which just a few minor
> changes. Now I'm interested to move to using the /powerpc/ source tree
> instead, but I can't figure out exactly what steps are necessary to do
> this.
>
> Does anyone run a MPC834x_SYS built with ARCH=powerpc?
>
Actually it was the first ppc board actually moved over to powerpc.
> I boot the board with U-Boot (version 1.1.4, customized), and I assume
> that I need to add some stuff for this new device tree thing, but I
> can't figure out exactly what the kernel will expect.
You'll need to replace u-boot with custom one that is able to deal with dts. There are 2 ways ATM - use bootm dts approach, which could load device tree from external source, and built-in that makes in compiled into u-boot.
Both patches against u-boot should be searched in u-boot mailing list archives. For 83xx both way work just fine.
--
Sincerely,
Vitaly
^ permalink raw reply
* MPC5200 fec frame corruption
From: Asier Llano Palacios @ 2006-09-12 16:33 UTC (permalink / raw)
To: Sylvain Munaut, linuxppc-embedded; +Cc: a.arzuaga, m.alvarez, t.arzuaga
In-Reply-To: <20060607120252.qjekdh5yzyrs4s0g@webmail.bluenox.com>
Hello,
We have been working with the MPC5200 fec and a linux-2.6.10 with some
patches extracted from Sylvain's bitkeeper repository. We have 3
different boards that worked properly with that kernel.
We upgraded to the new MPC5200B and it still worked properly with the
2.6.10 kernel.
We upgraded to the new code of the Sylvain's git repository and the FEC
transmitted frames are corrupted. This corruption only happens with the
current git repository and the MPC5200B.
MPC5200 MPC5200B
linux-2.6.10: OK OK
Sylvain's git: OK CORRUPT
The problem is that the lite5200 and the lite5200b work flawlessly, but
our architecture is essentialy the same but with different PHYs (Marvell
88E6095F and 88E6060). Our architecture works properly with the
linux-2.6.10, so we don't think that it is a hardware related problem.
We have been watching the MII bus by osciloscope and the errors are
clearly transmitted by the MPC5200B (no noise or distortion).
We have inserted traces in the functions of the FEC driver with the
buffer information that is sent to the DMA and the frames are correct.
The corruption pattern is as follows:
Transmition frame:
0000 ff ff ff ff ff ff 00 11 22 33 44 55 e0 00 e0 73
0010 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
0020 12 23 34 45 56 67 78 89 9a ab bc cd de ef f0 01
0030 24 35 46 57 68 79 8a 9b ac bd ce df e0 f1 02 13
0040 36 47 58 69 7a 8b 9c ad be cf d0 e1 f2 03 14 25
0050 48 59 6a 7b 8c 9d ae bf c0 d1 e2 f3 04 15 26 37
0060 5a 6b 7c 8d 9e af b0 c1 d2 e3 f4 05 16 27 38 49
0070 6c 7d 8e 9f a0 b1 c2 d3 e4 f5 06 17 28 39 4a 5b
0080 7e 8f 90 a1 b2 c3 d4 e5 f6 07 18 29 3a 4b 5c 6d
Reception frame (corrupted bytes marked):
0000 (7e)ff ff ff ff ff 00 11 22 33 44 55 e0 00 e0 73
0010 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
0020 12 23 34 45 56 67 78 89 9a ab bc cd de ef f0 01
0030 24 35 46 57 68 79 8a 9b ac bd ce df e0 f1(ee)13
0040 36 47 58 69 7a 8b 9c ad be cf d0 e1 f2 03 14 25
0050 48 59 6a 7b 8c 9d ae bf c0 d1 e2 f3 04 15 26 37
0060 5a 6b 7c 8d 9e af b0 c1 d2 e3 f4 05 16 27 38 49
0070 6c 7d 8e 9f a0 b1 c2 d3 e4 f5 06 17 28 39(26)5b
0080 7e 8f 90 a1 b2 c3 d4 e5 f6 07 18 29 3a 4b 5c 6d
The corrupted bytes are sometimes correct, sometimes overwriten
by the byte that is 0x20 bytes before, and sometimes changed
by the bytes that is 0x40 bytes before. About 50% of the time
the marked bytes are worong.
I'd like to know if anything here makes any sense to you, so
that I can understand the origin of the problem, or any
additional test to perform.
Thank you in advance,
Asier Llano=20
=20
----------------------------------------- PLEASE NOTE =
-------------------------------------------
This message, along with any attachments, may be confidential or legally =
privileged.=20
It is intended only for the named person(s), who is/are the only =
authorized recipients.
If this message has reached you in error, kindly destroy it without =
review and notify the sender immediately.
Thank you for your help.
=B5SysCom uses virus scanning software but excludes any liability for =
viruses contained in any attachment.
=20
------------------------------------ ROGAMOS LEA ESTE TEXTO =
-------------------------------
Este mensaje y sus anexos pueden contener informaci=F3n confidencial y/o =
con derecho legal.=20
Est=E1 dirigido =FAnicamente a la/s persona/s o entidad/es rese=F1adas =
como =FAnico destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elim=EDnelo sin =
revisarlo ni reenviarlo y notif=EDquelo inmediatamente al remitente. =
Gracias por su colaboraci=F3n. =20
=B5SysCom utiliza software antivirus, pero no se hace responsable de los =
virus contenidos en los ficheros anexos.
^ permalink raw reply
* Re: MPC5200 fec frame corruption
From: Sylvain Munaut @ 2006-09-12 17:26 UTC (permalink / raw)
To: a.llano; +Cc: a.arzuaga, m.alvarez, t.arzuaga, linuxppc-embedded
In-Reply-To: <1158078812.5297.92.camel@usys-sw-server>
Hi Asier,
> We have been working with the MPC5200 fec and a linux-2.6.10 with some
> patches extracted from Sylvain's bitkeeper repository. We have 3
> different boards that worked properly with that kernel.
>
> We upgraded to the new MPC5200B and it still worked properly with the
> 2.6.10 kernel.
>
> We upgraded to the new code of the Sylvain's git repository and the FEC
> transmitted frames are corrupted. This corruption only happens with the
> current git repository and the MPC5200B.
>
> MPC5200 MPC5200B
> linux-2.6.10: OK OK
> Sylvain's git: OK CORRUPT
>
I must admit I don't have bitkeeper anymore installed on my machine so I
don't
remeber exactly what in there.
Could you put somewhere on line the diff between 2.6.10 and you tree,
eventually minus all the irrelevant/confidential stuff ?
What would be needed woud be the arch/ppc/syslib/bestcomm ,
drivers/net/fec_mpc52xx
and the board setup code.
> The problem is that the lite5200 and the lite5200b work flawlessly, but
> our architecture is essentialy the same but with different PHYs (Marvell
> 88E6095F and 88E6060). Our architecture works properly with the
> linux-2.6.10, so we don't think that it is a hardware related problem.
> We have been watching the MII bus by osciloscope and the errors are
> clearly transmitted by the MPC5200B (no noise or distortion).
>
> We have inserted traces in the functions of the FEC driver with the
> buffer information that is sent to the DMA and the frames are correct.
>
>
> [... logs stripped ...]
> The corrupted bytes are sometimes correct, sometimes overwriten
> by the byte that is 0x20 bytes before, and sometimes changed
> by the bytes that is 0x40 bytes before. About 50% of the time
> the marked bytes are worong.
>
> I'd like to know if anything here makes any sense to you, so
> that I can understand the origin of the problem, or any
> additional test to perform.
>
Any sense not really. But I would check first the options in the board
setup.
Things like cache snooping, comm bus prefetching, xlb priority settings and
pipelining, ...
Then the microcode of the task themselves and the options wich are used when
loading them.
Finally compare the driver code itself.
Sylvain
^ permalink raw reply
* Re: 'make ARCH=ppc defconfig' failing for cross-compile
From: Judith Lebzelter @ 2006-09-12 17:48 UTC (permalink / raw)
To: Christian; +Cc: linuxppc-dev, Judith Lebzelter
In-Reply-To: <Pine.LNX.4.64.0609100652160.16347@sheep.housecafe.de>
On Tue, Sep 12, 2006 at 10:21:46AM -0700, Christian wrote:
> On Fri, 8 Sep 2006, Judith Lebzelter wrote:
> > I have been doing cross-compiles for ppc and powerpc on my i686 system.
> > In order to do this I generate the .config file like this:
> >
> > make ARCH=ppc defconfig
> > (or make ARCH=powerpc defconfig)
>
> Seems like defconfig has been removed, because there are so many
> sub-platforms for ppc:
I build these in OSDL's cross compile build farm (PLM) as a code check.
Our scripts are generalized to work for various architectures, so it is
disappointing that 'defconfig' no longer works for ppc the way it does
in other achitectures. Are there plans to make plain 'defconfig' work
again, at least in the new 'powerpc' directory? (The 'ppc64_defconfig'
target looks good to me.:)
>
> $ ls arch/ppc/configs/*defconfig | wc -l
> 56
>
> Just pick the defonfig for your platform, for my PReP that'd be:
I will do this as a work-around.
TFYR,
Judith
>
> $ make ARCH=ppc CROSS_COMPILE=powerpc-604-linux-gnu- prep_defconfig
>
>
> HTH,
> Christian.
> --
> BOFH excuse #383:
>
> Your processor has taken a ride to Heaven's Gate on the UFO behind Hale-Bopp's comet.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: How to find I2C address?
From: Howard, Marc @ 2006-09-12 17:48 UTC (permalink / raw)
To: Sachin Rane; +Cc: linuxppc-embedded
> On Tue, 2006-09-12 at 10:13 -0400, Sachin Rane wrote:
> Hi,
> =20
> I am using AMCC PPC440GX evaluation board.
> I want to access serial EEPROM (AP31_U29) present on the board.
> I couldn't find the I2C address for this chip in the board manuals.
> =20
> Could you tell me where I can find it?
> =20
You didn't look very hard. All of the I2C addresses are in Table 2-5 on
page 42 of the AMCC evaluation board users manual.
Marc Howard
^ permalink raw reply
* [PATCH] powerpc: allow PHBs anywhere in the device tree
From: Arnd Bergmann @ 2006-09-12 17:52 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cbe-oss-dev
The rtas_pci code currently restricts pci host bridges to
locations directly under the device tree root. In order to
correctly model a north bridge that has multiple PCI buses,
that restriction needs to be relaxed.
The new definition is a device node of type "pci" whose
parent is of a different type, so we don't treat pci-to-pci
bridges as host bridges.
It also accepts any device type of "pci", "pcie", "ht" and
"pciex" in order to match anything that is currently in use.
I have added a new helper "of_find_phb_node" to prom.c so
that pci implementations of non-rtas platforms can use this
as well.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/kernel/prom.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/prom.c
+++ linux-2.6/arch/powerpc/kernel/prom.c
@@ -1325,6 +1325,72 @@ struct device_node *of_get_next_child(co
EXPORT_SYMBOL(of_get_next_child);
/**
+ * of_node_is_pci - Test if a node a pci host
+ * @node: node to compare
+ *
+ * returns 1 for PCI hosts and 0 for anything else
+ *
+ * This function is meant to be called from
+ * of_find_phb_node as a helper. We compare both
+ * the compatible and the device_type properties
+ * to known strings used to indicate PCI hosts.
+ */
+static int of_node_is_pci(struct device_node *node)
+{
+ if (!node->type)
+ return 0;
+
+ if (strcasecmp(node->type, "pci") == 0 ||
+ strcasecmp(node->type, "ht") == 0 ||
+ strcasecmp(node->type, "pciex") == 0 ||
+ strcasecmp(node->type, "pcie") == 0)
+ return 1;
+
+ if (device_is_compatible(node, "pci") ||
+ device_is_compatible(node, "ht") ||
+ device_is_compatible(node, "pciex") ||
+ device_is_compatible(node, "pcie"))
+ return 1;
+
+ return 0;
+}
+
+/**
+ *
+ * of_find_phb_node - Iterate all PCI host bridge device nodes
+ *
+ * @from: The node to start searching from or NULL, the node
+ * you pass will not be searched, only the next one
+ * will; typically, you pass what the previous call
+ * returned. of_node_put() will be called on it
+ *
+ * Returns a node pointer with refcount incremented, use
+ * of_node_put() on it when done.
+ *
+ * since we only want to return host bridges, not pci-pci
+ * bridges, check if the parent is not also a pci host.
+ */
+struct device_node *of_find_phb_node(struct device_node *from)
+{
+ struct device_node *np;
+
+ read_lock(&devtree_lock);
+ np = from ? from->allnext : allnodes;
+ for (; np; np = np->allnext) {
+ if (of_node_is_pci(np) &&
+ np->parent &&
+ !of_node_is_pci(np->parent))
+ break;
+ }
+ if (np)
+ of_node_get(np);
+ if (from)
+ of_node_put(from);
+ read_unlock(&devtree_lock);
+ return np;
+}
+
+/**
* of_node_get - Increment refcount of a node
* @node: Node to inc refcount, NULL is supported to
* simplify writing of callers
Index: linux-2.6/arch/powerpc/kernel/rtas_pci.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/rtas_pci.c
+++ linux-2.6/arch/powerpc/kernel/rtas_pci.c
@@ -240,13 +240,6 @@ unsigned long __devinit get_phb_buid (st
if (ibm_read_pci_config == -1) return 0;
- /* PHB's will always be children of the root node,
- * or so it is promised by the current firmware. */
- if (phb->parent == NULL)
- return 0;
- if (phb->parent->parent)
- return 0;
-
buid_vals = (unsigned int *) get_property(phb, "reg", &len);
if (buid_vals == NULL)
return 0;
@@ -297,17 +290,10 @@ unsigned long __init find_and_init_phbs(
struct device_node *node;
struct pci_controller *phb;
unsigned int index;
- struct device_node *root = of_find_node_by_path("/");
+ node = NULL;
index = 0;
- for (node = of_get_next_child(root, NULL);
- node != NULL;
- node = of_get_next_child(root, node)) {
-
- if (node->type == NULL || (strcmp(node->type, "pci") != 0 &&
- strcmp(node->type, "pciex") != 0))
- continue;
-
+ while ((node = of_find_phb_node(node))) {
phb = pcibios_alloc_controller(node);
if (!phb)
continue;
@@ -316,8 +302,6 @@ unsigned long __init find_and_init_phbs(
pci_setup_phb_io(phb, index == 0);
index++;
}
-
- of_node_put(root);
pci_devs_phb_init();
/*
Index: linux-2.6/include/asm-powerpc/prom.h
===================================================================
--- linux-2.6.orig/include/asm-powerpc/prom.h
+++ linux-2.6/include/asm-powerpc/prom.h
@@ -131,6 +131,7 @@ extern struct device_node *of_find_compa
extern struct device_node *of_find_node_by_path(const char *path);
extern struct device_node *of_find_node_by_phandle(phandle handle);
extern struct device_node *of_find_all_nodes(struct device_node *prev);
+extern struct device_node *of_find_phb_node(struct device_node *from);
extern struct device_node *of_get_parent(const struct device_node *node);
extern struct device_node *of_get_next_child(const struct device_node *node,
struct device_node *prev);
^ permalink raw reply
* Re: [PATCH] Prevent legacy io access on pmac
From: Olaf Hering @ 2006-09-12 19:29 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
In-Reply-To: <20060911115354.GA23884@aepfle.de>
Follow up to the previous patch:
Update the return values in i8402 and parport to -ENODEV.
---
drivers/input/serio/i8042-io.h | 2 +-
drivers/parport/parport_pc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.18-rc6/drivers/input/serio/i8042-io.h
===================================================================
--- linux-2.6.18-rc6.orig/drivers/input/serio/i8042-io.h
+++ linux-2.6.18-rc6/drivers/input/serio/i8042-io.h
@@ -69,7 +69,7 @@ static inline int i8042_platform_init(vo
*/
#if defined(CONFIG_PPC_MERGE)
if (check_legacy_ioport(I8042_DATA_REG))
- return -EBUSY;
+ return -ENODEV;
#endif
#if !defined(__sh__) && !defined(__alpha__) && !defined(__mips__)
if (!request_region(I8042_DATA_REG, 16, "i8042"))
Index: linux-2.6.18-rc6/drivers/parport/parport_pc.c
===================================================================
--- linux-2.6.18-rc6.orig/drivers/parport/parport_pc.c
+++ linux-2.6.18-rc6/drivers/parport/parport_pc.c
@@ -3376,7 +3376,7 @@ static int __init parport_pc_init(void)
{
#if defined(CONFIG_PPC_MERGE)
if (check_legacy_ioport(PARALLEL_BASE))
- return -EBUSY;
+ return -ENODEV;
#endif
if (parse_parport_params())
return -EINVAL;
^ permalink raw reply
* Re: pci error recovery procedure
From: Linas Vepstas @ 2006-09-12 19:38 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: linuxppc-dev, linux-pci maillist, Yanmin Zhang, LKML, Rajesh Shah
In-Reply-To: <1157599136.20092.529.camel@ymzhang-perf.sh.intel.com>
On Thu, Sep 07, 2006 at 11:18:56AM +0800, Zhang, Yanmin wrote:
> The error recovery procedures
> are to process pci hardware errors instead of device driver bug.
Over the last three years, we've uncovered (and fixed) dozens of
device driver bugs that were only detected because of the pci error
detection hardware. The ability to get device dumps is important,
because many of these bugs are hard to reproduce, require getting
PCI bus analyzers attached to the system, etc.
> Current error handler infrastructure could support pci-e, but I want a better
> solution to faciliate driver developers to add error handlers more easily. My
> startpoint is driver developer. If they are not willing to add error handlers,
> it's impossible to do so for all drivers by you and me.
Right. As a result, we only care about the products that we actually
sell to customers. PCI error recovery is not some "gee its nice" piece
of eye-candy or chrome: either one is serious about high-availability,
or one is not.
--linas
^ permalink raw reply
* Re: [PATCH] powerpc: allow PHBs anywhere in the device tree
From: Olof Johansson @ 2006-09-12 19:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <200609121952.04779.arnd.bergmann@de.ibm.com>
Hi,
Looks good. Two very minor nitpicks below.
-Olof
On Tue, 12 Sep 2006 19:52:04 +0200 Arnd Bergmann <arnd.bergmann@de.ibm.com> wrote:
> The rtas_pci code currently restricts pci host bridges to
> locations directly under the device tree root. In order to
> correctly model a north bridge that has multiple PCI buses,
> that restriction needs to be relaxed.
>
> The new definition is a device node of type "pci" whose
> parent is of a different type, so we don't treat pci-to-pci
> bridges as host bridges.
> It also accepts any device type of "pci", "pcie", "ht" and
> "pciex" in order to match anything that is currently in use.
>
> I have added a new helper "of_find_phb_node" to prom.c so
> that pci implementations of non-rtas platforms can use this
> as well.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Index: linux-2.6/arch/powerpc/kernel/prom.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/prom.c
> +++ linux-2.6/arch/powerpc/kernel/prom.c
> @@ -1325,6 +1325,72 @@ struct device_node *of_get_next_child(co
> EXPORT_SYMBOL(of_get_next_child);
>
> /**
> + * of_node_is_pci - Test if a node a pci host
> + * @node: node to compare
> + *
> + * returns 1 for PCI hosts and 0 for anything else
> + *
> + * This function is meant to be called from
> + * of_find_phb_node as a helper. We compare both
> + * the compatible and the device_type properties
> + * to known strings used to indicate PCI hosts.
> + */
> +static int of_node_is_pci(struct device_node *node)
> +{
> + if (!node->type)
> + return 0;
> +
> + if (strcasecmp(node->type, "pci") == 0 ||
> + strcasecmp(node->type, "ht") == 0 ||
> + strcasecmp(node->type, "pciex") == 0 ||
> + strcasecmp(node->type, "pcie") == 0)
!strcasecmp(...) instead?
Do they ever exist in non-lowercase versions? Old code just did
strcmp().
> + return 1;
> +
> + if (device_is_compatible(node, "pci") ||
> + device_is_compatible(node, "ht") ||
> + device_is_compatible(node, "pciex") ||
> + device_is_compatible(node, "pcie"))
> + return 1;
> +
> + return 0;
> +}
> +
> +/**
> + *
> + * of_find_phb_node - Iterate all PCI host bridge device nodes
> + *
> + * @from: The node to start searching from or NULL, the node
> + * you pass will not be searched, only the next one
> + * will; typically, you pass what the previous call
> + * returned. of_node_put() will be called on it
Convention seems to be to call this "prev", not "from"?
> + *
> + * Returns a node pointer with refcount incremented, use
> + * of_node_put() on it when done.
> + *
> + * since we only want to return host bridges, not pci-pci
> + * bridges, check if the parent is not also a pci host.
> + */
> +struct device_node *of_find_phb_node(struct device_node *from)
> +{
> + struct device_node *np;
> +
> + read_lock(&devtree_lock);
> + np = from ? from->allnext : allnodes;
> + for (; np; np = np->allnext) {
> + if (of_node_is_pci(np) &&
> + np->parent &&
> + !of_node_is_pci(np->parent))
> + break;
> + }
> + if (np)
> + of_node_get(np);
> + if (from)
> + of_node_put(from);
> + read_unlock(&devtree_lock);
> + return np;
> +}
> +
> +/**
> * of_node_get - Increment refcount of a node
> * @node: Node to inc refcount, NULL is supported to
> * simplify writing of callers
> Index: linux-2.6/arch/powerpc/kernel/rtas_pci.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/rtas_pci.c
> +++ linux-2.6/arch/powerpc/kernel/rtas_pci.c
> @@ -240,13 +240,6 @@ unsigned long __devinit get_phb_buid (st
>
> if (ibm_read_pci_config == -1) return 0;
>
> - /* PHB's will always be children of the root node,
> - * or so it is promised by the current firmware. */
> - if (phb->parent == NULL)
> - return 0;
> - if (phb->parent->parent)
> - return 0;
> -
> buid_vals = (unsigned int *) get_property(phb, "reg", &len);
> if (buid_vals == NULL)
> return 0;
> @@ -297,17 +290,10 @@ unsigned long __init find_and_init_phbs(
> struct device_node *node;
> struct pci_controller *phb;
> unsigned int index;
> - struct device_node *root = of_find_node_by_path("/");
>
> + node = NULL;
> index = 0;
> - for (node = of_get_next_child(root, NULL);
> - node != NULL;
> - node = of_get_next_child(root, node)) {
> -
> - if (node->type == NULL || (strcmp(node->type, "pci") != 0 &&
> - strcmp(node->type, "pciex") != 0))
> - continue;
> -
> + while ((node = of_find_phb_node(node))) {
> phb = pcibios_alloc_controller(node);
> if (!phb)
> continue;
> @@ -316,8 +302,6 @@ unsigned long __init find_and_init_phbs(
> pci_setup_phb_io(phb, index == 0);
> index++;
> }
> -
> - of_node_put(root);
> pci_devs_phb_init();
>
> /*
> Index: linux-2.6/include/asm-powerpc/prom.h
> ===================================================================
> --- linux-2.6.orig/include/asm-powerpc/prom.h
> +++ linux-2.6/include/asm-powerpc/prom.h
> @@ -131,6 +131,7 @@ extern struct device_node *of_find_compa
> extern struct device_node *of_find_node_by_path(const char *path);
> extern struct device_node *of_find_node_by_phandle(phandle handle);
> extern struct device_node *of_find_all_nodes(struct device_node *prev);
> +extern struct device_node *of_find_phb_node(struct device_node *from);
> extern struct device_node *of_get_parent(const struct device_node *node);
> extern struct device_node *of_get_next_child(const struct device_node *node,
> struct device_node *prev);
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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