* Re: [PATCH 1/1] bootwrapper: add flat device tree support code
From: Hollis Blanchard @ 2006-09-11 18:44 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <1157995667.27129.148.camel@cashmere.sps.mot.com>
On Mon, 2006-09-11 at 12:27 -0500, Jon Loeliger wrote:
>
> Wasn't there a notion of even combining this with
> the DTC code base directly? I haven't seen any
> patches or motion down this line, though...?
That's certainly a good place the new code could be applied. Of course,
I haven't sent patches to uboot, iseries boot code, kexec, or any other
number of places either, and don't really plan to. If those areas have
problems, they can switch to the consolidated codebase then (rather than
bugfixing the non-consolidated code).
Why, are you going to convert DTC?
-Hollis
^ permalink raw reply
* Re: [PATCH 1/1] bootwrapper: add flat device tree support code
From: Hollis Blanchard @ 2006-09-11 19:01 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <1157999955.27129.168.camel@cashmere.sps.mot.com>
On Mon, 2006-09-11 at 13:39 -0500, Jon Loeliger wrote:
> On Mon, 2006-09-11 at 13:44, Hollis Blanchard wrote:
>
> > That's certainly a good place the new code could be applied. Of course,
> > I haven't sent patches to uboot, iseries boot code, kexec, or any other
> > number of places either, and don't really plan to. If those areas have
> > problems, they can switch to the consolidated codebase then (rather than
> > bugfixing the non-consolidated code).
>
> I'm worried about the code-duplication factor here...
The functionality has already been duplicated, and more was on the way.
The consolidated code prevents that from spreading, but by itself
doesn't replace any of the existing duplication.
> > Why, are you going to convert DTC?
>
> I'm not opposed to accepting patches. :-)
Have fun.
-Hollis
^ permalink raw reply
* Re: [PATCH] powerpc: Quiet hvc_console console output on failed opens
From: Ryan Arnold @ 2006-09-11 19:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <17664.43318.370252.157724@cargo.ozlabs.ibm.com>
On Fri, 2006-09-08 at 09:20 +1000, Paul Mackerras wrote:
> Ryan Arnold writes:
>
> > This seems like a good fix to me. I think it is a debug artifact
> > anyway.
>
> So, does that amount to an Acked-by?
>
> Paul.
Yes, take that as an:
Acked-by: Ryan S. Arnold <rsa@us.ibm.com>
--
Ryan S. Arnold <rsa@us.ibm.com>
IBM Linux Technology Center
Linux on Power Toolchain
^ permalink raw reply
* Re: Perhaps git-update-server-info needs to be run on .../paulus/powerpc.git?
From: Kim Phillips @ 2006-09-11 20:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17669.7544.599959.442534@cargo.ozlabs.ibm.com>
On Mon, 11 Sep 2006 18:25:28 +1000
Paul Mackerras <paulus@samba.org> wrote:
> Paul Mackerras writes:
>
> > Kim Phillips writes:
> >
> > > Linus' tree clones fine, paulus' doesn't:
> >
> > Try now...
> >
> > Paul.
>
> Oops, mail system error, ignore me...
>
> Paul.
funnily enough, I can't seem to clone your tree again today; I'm using the http: protocol.
hopefully, the fix should only be a matter of:
chmod +x hooks/post-update
Thanks,
Kim
^ permalink raw reply
* Re: Any PPC system with working USB 2.0 host
From: Guennadi Liakhovetski @ 2006-09-11 20:13 UTC (permalink / raw)
To: Jamie Guinan; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0609111140260.6892@gemini.home.net>
On Mon, 11 Sep 2006, Jamie Guinan wrote:
> Does USB 2.0 host on the KuroBox in fact work, with hi-speed devices?
Yes, it does. Never had problems with it, using it with a high-speed
wireless dongle, didn't test too intensively with storage though.
Regards
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* simple ELF bootloader for embedded xilinx linux ?
From: rimas @ 2006-09-11 19:44 UTC (permalink / raw)
To: linuxppc-embedded
Greetings,
i have been prototyping a design using the avnet V4FX12 mini module
board running linux
i have been NFS mounting my root partition for the time being but now
i want to use initrd and have a ramdisk with my root partition
i have built a zImage.initrd.elf which i can download with xmd and
run and it works fine
up until now i've been using the simple bootloader application that
comes with the Xilinx EDK to boot linux off the flash memory that is
included on the board
however the EDK bootloader needs the file its booting to be in SREC
format which takes up close to 3x the space of the ELF file. when i
create an SREC file of the image containing the linux kernel and the
root filesystem, its too big to fit in the flash (4M). however the
zImage.initrd.elf file is less than 3 megs in size.
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.
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 ?
thanks for any and all advice,
-rimas
^ permalink raw reply
* 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
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