Re: [PATCH] Consolidate XILINX_VIRTEX board support
On 8/9/07, Grant Likely <[EMAIL PROTECTED]> wrote: > On 8/6/07, Wolfgang Reissnegger <[EMAIL PROTECTED]> wrote: > > Make support for Xilinx boards more generic, making it easier > > to add new boards. Add initial support for xupv2p and ml410 boards. > > > > Thanks, > >Wolfgang > > > > > > Signed-off-by: Wolfgang Reissnegger <[EMAIL PROTECTED]> > > Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]> > > Comments below... > > > diff --git a/arch/ppc/boot/simple/embed_config.c > > b/arch/ppc/boot/simple/embed_config.c > > index 840bff2..e0b8954 100644 > > --- a/arch/ppc/boot/simple/embed_config.c > > +++ b/arch/ppc/boot/simple/embed_config.c > > @@ -744,7 +744,7 @@ embed_config(bd_t **bdp) > > } > > #endif /* WILLOW */ > > > > -#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403) > > +#if defined(CONFIG_XILINX_VIRTEX) > > You need to rebase your patch to mainline. This change has already been > applied Oops, my mistake. This change is in my tree, but not in mainline. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Consolidate XILINX_VIRTEX board support
On 8/10/07, Kumar Gala <[EMAIL PROTECTED]> wrote: > > On Aug 9, 2007, at 1:54 PM, Grant Likely wrote: > > > On 8/6/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote: > > Naahh, this is pretty benign stuff. I say let it go in. :-) > > > > These changes are low risk and they don't hurt anything. If Virtex > > support worked in arch/powerpc then I'd agree, but for now it allows > > us to keep the virtex device driver support somewhat current. > > We've clearly stated for a while that only bug fixes should be going > into arch/ppc. This looks like new board support. > > Also, be aware that arch/ppc is going away in Jun 2008. :) So it only lives in the tree for 10 months time, big deal. :-) For those who are need it, it allows them to participate without having to do the heavy lifting of getting Virtex support into arch/powerpc. It also allow device driver development to progress on those boards in the mean time. Besides there is almost no new code in these changes. The largest part of the patch is a copy of older code (which I NAKed). The other changes are no big deal. That being said, those excuses are *no* *bloody* *good* for folks like me who *should* be getting virtex support into arch/powerpc. :-) Also, the moment it is viable to add new Virtex board ports to arch/powerpc I will change my tune and agree 100% with you. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: 2.6 system stuck with one line change in platform_init()
On 8/11/07, mike zheng <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> In order to debug the 8548 CDS BSP of kernel 2.6, I want setup serial port
> with UART on mpc85xx as early as possible. . I add the register access code
> at the beginning of platform_init(). However the system just hanging there
> with this line. If I comment out this
> line"WRITE8_ADDR(M85xx_EIIADDR,0)", then linux kernel runs
> well.
>
> Thanks in advance,
>
> Mike Z
>
> Here is the code of my mpc85xx_cds_common.c:
>
> #define WRITE8_ADDR(address, value) \
> ((*((volatile u8 *)(address))) = (u8)(value))
>
> #define M85xx_EII_ADDR 0xe0004500
>
> void __init
> platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
>unsigned long r6, unsigned long r7)
> {
>/* parse_bootinfo must always be called first */
>parse_bootinfo(find_bootinfo());
>
> /* Now we try to access register of UART */
> WRITE8_ADDR(M85xx_EII_ADDR, 0);
where is M85xx_EII_ADDR declearation? If the address need to
be io_remap first?
>
> }
> ___
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
www.skyeye.org
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
2.6 system stuck with one line change in platform_init()
Hi All,
In order to debug the 8548 CDS BSP of kernel 2.6, I want setup serial port
with UART on mpc85xx as early as possible. . I add the register access
code at the beginning of platform_init(). However the system just hanging
there with this line. If I comment out this
line"WRITE8_ADDR(M85xx_EIIADDR,0)", then linux kernel runs well.
Thanks in advance,
Mike Z
Here is the code of my mpc85xx_cds_common.c:
#define WRITE8_ADDR(address, value) \
((*((volatile u8 *)(address))) = (u8)(value))
#define M85xx_EII_ADDR 0xe0004500
void __init
platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
unsigned long r6, unsigned long r7)
{
/* parse_bootinfo must always be called first */
parse_bootinfo(find_bootinfo());
/* Now we try to access register of UART */
WRITE8_ADDR(M85xx_EII_ADDR, 0);
}
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: some questions about XUP and the generation of ace file
On 8/10/07, windstorm <[EMAIL PROTECTED]> wrote: > 1 it's strange. the ns16550.c do exist in the arch/ppc/boot/ > directory, not arch/ppc/boot/common. I just download the source > yesterday. > > 2 Can you show me some reference about the "small bootloader"? Or any > web material about it? Sorry, I don't have anything I can publish. I just grabbed some elf decoding code from CFE (Common firmware environment which uses a BSD style license) and bound it up with the Xilinx FAT driver. It wasn't very hard to do. g. > > 2007/8/10, Grant Likely <[EMAIL PROTECTED]>: > > On 8/10/07, windstorm <[EMAIL PROTECTED]> wrote: > > > Hello all: > > > > > > I am trying to transfer the Linux onto XUP board. The kernel source I > > > used is from the git trees from andrei konovalov or grant likely. But > > > I encounter two questions now. > > > > > > 1 Generally, I should correct the kernel source file > > > arch/ppc/boot/common/ns16550.c, In that file, changing SERIAL_BAUD > > > from 9600 to 38400 makes the bootloader talk at 38400. I always do it > > > when I use standard kernel source. But this time I found out that the > > > ns16550.c's path is arch/ppc/boot/, not arch/ppc/boot/common/, and > > > there was no "SERIAL_BAUD" string any more. So, how can I control the > > > baud rate? > > > > ??? > > > > I don't know what you're referring to. ns16550.c is in > > arch/ppc/boot/common on my tree, and it still contains the SERIAL_BAUD > > #define. > > > > > > > > 2 I have compiled the kernel and obtained a Image.elf whose size is > > > 1.7MB, and then it's time for creating a system.ace file which I can > > > put onto a compact flash card. I Changed the file xupGenace.opt like > > > the follow: > > > > You can do this, but I don't think it's a particularly good idea. > > Binding the kernel image into an ACE file results in a *very* large > > ace file, and it's slow. Consider the fact that doing it that way > > means that you're transferring the entire 1.7MB image via JTAG. > > > > I've also seem problems where DDR isn't fully initialized before the > > SystemACE tries to transfer the image which results in a non-booting > > system. > > > > What I do, is I've got a small bootloader that lives in BRAM and is > > just smart enough to load an elf file off of the CF card. If I can > > get permission to do so, I'll publish the source for my utility. > > > > > > > > -jprog > > > -board user > > > -target ppc_hw > > > -hw ./implementation/download.bit > > > -elf zImage.elf > > > -configdevice devicenr 1 idcode 0x1127e093 irlength 14 partname xc2vp30 > > > -debugdevice devicenr 1 cpunr 1 > > > -ace system.ace > > > > > > and executed the command: xmd -tcl genace.tcl -opt genace.opt > > > > > > and the result I saw is: Using GenACE option file : genace.opt > > > Error: Executable zImage.elf does not contain start address.. > > > > > > I examine the information by google, some said that it's the bug of > > > development tools without sp, but both my ISE and EDK was patched. > > > Others said that it's because of the "mb-objdump", we should chage it > > > into "powerpc-eaci-objdump", and actually I had done this correction. > > > BUT, the error still here. > > > > > > Could anyone please to help me about this question? I will be very > > > grateful. > > > > Very odd. I haven't seen this problem myself so I can't be much help. > > sorry. > > > > > > > > BTW, could any kind person send any basic config file, which had been > > > proved that the kernel compiled based on it could work good on XUP > > > board? > > > > I don't have that board, sorry > > > > g. > > > > -- > > Grant Likely, B.Sc., P.Eng. > > Secret Lab Technologies Ltd. > > [EMAIL PROTECTED] > > (403) 399-0195 > > > > > -- > web: http://www.forwind.cn > msn: likunarmstrong at hotmail.com > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: some questions about XUP and the generation of ace file
1 it's strange. the ns16550.c do exist in the arch/ppc/boot/ directory, not arch/ppc/boot/common. I just download the source yesterday. 2 Can you show me some reference about the "small bootloader"? Or any web material about it? 2007/8/10, Grant Likely <[EMAIL PROTECTED]>: > On 8/10/07, windstorm <[EMAIL PROTECTED]> wrote: > > Hello all: > > > > I am trying to transfer the Linux onto XUP board. The kernel source I > > used is from the git trees from andrei konovalov or grant likely. But > > I encounter two questions now. > > > > 1 Generally, I should correct the kernel source file > > arch/ppc/boot/common/ns16550.c, In that file, changing SERIAL_BAUD > > from 9600 to 38400 makes the bootloader talk at 38400. I always do it > > when I use standard kernel source. But this time I found out that the > > ns16550.c's path is arch/ppc/boot/, not arch/ppc/boot/common/, and > > there was no "SERIAL_BAUD" string any more. So, how can I control the > > baud rate? > > ??? > > I don't know what you're referring to. ns16550.c is in > arch/ppc/boot/common on my tree, and it still contains the SERIAL_BAUD > #define. > > > > > 2 I have compiled the kernel and obtained a Image.elf whose size is > > 1.7MB, and then it's time for creating a system.ace file which I can > > put onto a compact flash card. I Changed the file xupGenace.opt like > > the follow: > > You can do this, but I don't think it's a particularly good idea. > Binding the kernel image into an ACE file results in a *very* large > ace file, and it's slow. Consider the fact that doing it that way > means that you're transferring the entire 1.7MB image via JTAG. > > I've also seem problems where DDR isn't fully initialized before the > SystemACE tries to transfer the image which results in a non-booting > system. > > What I do, is I've got a small bootloader that lives in BRAM and is > just smart enough to load an elf file off of the CF card. If I can > get permission to do so, I'll publish the source for my utility. > > > > > -jprog > > -board user > > -target ppc_hw > > -hw ./implementation/download.bit > > -elf zImage.elf > > -configdevice devicenr 1 idcode 0x1127e093 irlength 14 partname xc2vp30 > > -debugdevice devicenr 1 cpunr 1 > > -ace system.ace > > > > and executed the command: xmd -tcl genace.tcl -opt genace.opt > > > > and the result I saw is: Using GenACE option file : genace.opt > > Error: Executable zImage.elf does not contain start address.. > > > > I examine the information by google, some said that it's the bug of > > development tools without sp, but both my ISE and EDK was patched. > > Others said that it's because of the "mb-objdump", we should chage it > > into "powerpc-eaci-objdump", and actually I had done this correction. > > BUT, the error still here. > > > > Could anyone please to help me about this question? I will be very grateful. > > Very odd. I haven't seen this problem myself so I can't be much help. sorry. > > > > > BTW, could any kind person send any basic config file, which had been > > proved that the kernel compiled based on it could work good on XUP > > board? > > I don't have that board, sorry > > g. > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > [EMAIL PROTECTED] > (403) 399-0195 > -- web: http://www.forwind.cn msn: likunarmstrong at hotmail.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEX boardsupport]
The main thing that Grant's script lacks is the ability to pull in default parameters that aren't listed in the MPD for a core, but not in the MHS file... I think the only way to easily solve that is to live within EDK's bsp generation, unfortunately... BTW: I'm currently hacking away to see if I can get a microblaze system booting using a flat device tree... I haven't decided if it's worth it to go that route in the end yet, but... Steve > -Original Message- > From: > [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] labs.org] On Behalf Of Grant Likely > Sent: Friday, August 10, 2007 6:48 AM > To: Koss, Mike (Mission Systems) > Cc: linuxppc-embedded@ozlabs.org > Subject: Re: Device Tree tool [was RE: [PATCH] Consolidate > XILINX_VIRTEX boardsupport] > > On 8/10/07, Koss, Mike (Mission Systems) <[EMAIL PROTECTED]> wrote: > > > > <> > > > > > diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > > > b/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > > > index 01aa043..34d9844 100644 > > > > > --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > > > +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > > > @@ -15,8 +15,12 @@ > > > > > > > > > > #if defined(CONFIG_XILINX_ML300) > > > > > #include "xparameters_ml300.h" > > > > > +#elif defined(CONFIG_XILINX_XUPV2P) #include > > > > > +"xparameters_xupv2p.h" > > > > > #elif defined(CONFIG_XILINX_ML403) > > > > > #include "xparameters_ml403.h" > > > > > +#elif defined(CONFIG_XILINX_ML41x) > > > > > + #include "xparameters_ml41x.h" > > > > > #else > > > > > /* Add other board xparameter includes here before > the #else */ > > > > > #error No xparameters_*.h file included > > > > > > > > see comment above. > > > > > This whole xparams stuff is a special case; but it is > going away for > > arch/powerpc. xparameters.h is generated by the xilinx EDK > tool and it > > is painful to work with in the Linux context. For > arch/powerpc, I've > > got a tool that generates a device tree from the FPGA > hardware design. > > > > What is the tool that you are using and are you willing to > share it at > > this point? I'm currently working on some code to generate platform > > files for our internal drivers and the ll_temac vs using the ugle > > xparam's file. I'd like to not duplicate, or actually > assist, any effort > > in this area. > > It's on my git tree; http://git.secretlab.ca > > I've also got some feedback from the Xilinx folks in the form of a > patch, but I haven't integrated it yet. Pretty experimental stuff, > I'll probably end up rewriting it from scratch before it's done. > > Cheers, > g. > > > > > -- Mike Koss > > > > > > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > [EMAIL PROTECTED] > (403) 399-0195 > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded > > ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Consolidate XILINX_VIRTEX board support
On Aug 9, 2007, at 1:54 PM, Grant Likely wrote: > On 8/6/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote: >> On Tuesday 07 August 2007, Wolfgang Reissnegger wrote: >>> >>> Make support for Xilinx boards more generic, making it easier >>> to add new boards. Add initial support for xupv2p and ml410 boards. >> >> I really think we shouldn't add stuff to arch/ppc at this point, >> it has been deprecated for over two years now. > > Naahh, this is pretty benign stuff. I say let it go in. :-) > > These changes are low risk and they don't hurt anything. If Virtex > support worked in arch/powerpc then I'd agree, but for now it allows > us to keep the virtex device driver support somewhat current. We've clearly stated for a while that only bug fixes should be going into arch/ppc. This looks like new board support. Also, be aware that arch/ppc is going away in Jun 2008. :) - k ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [PATCH] Consolidate XILINX_VIRTEX board support
On 8/10/07, Peter Korsgaard <[EMAIL PROTECTED]> wrote: > > "GL" == Grant Likely <[EMAIL PROTECTED]> writes: > > Hi, > > WR> -boot-$(CONFIG_XILINX_ML300)+= embed_config.o > WR> -boot-$(CONFIG_XILINX_ML403)+= embed_config.o > WR> +boot-$(CONFIG_XILINX_VIRTEX) += embed_config.o > >> > >> Don't do that. Other boards with Xilinx FPGAs don't necessarily need > >> embed_config.c > > GL> Then post patches for those boards so we can properly support the > GL> different configuration. > > Also if the boards are not generally available? No problem for me, but > I don't quite see the point. GregKH likes to tell the story of one architecture that is actively maintained, but only has about 2 users total. The point isn't how available the hardware is; the point is to see how others are using the code. Having a larger base of platform support to draw from makes it easier to recognize patterns in the code which Or, from a more selfish perspective; It's one thing to say "this will/won't work because of that platform over there that you can't see", and quite another to show the code and say "this is what I need to do". If you get your code merged, it is easier to influence the design direction. ie. you can say "Don't do that; you'll break this supported board!" :-) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: i couldn't get display in Console?
Hello. [EMAIL PROTECTED] wrote: > when i am booting montavista kernel using uboot i couldn't get any message > on Console... > i can view the booting messages by "Dumping the printk Log Buffer". i am > passing the "bootargs=console=ttyS0,115200 root=/dev/ram0 rw"...is that i I suspect you should use ttyCPM0 instead of ttyS0. Thi board very likely has CPM2, so its UARTs are the only ones that exist. > have to make any modification in kernel configuration to support > appropriate serial port for display boot messags.. find the attached printk You should enable CONFIG_SERIAL_CPM (if it's not already enabled). > buffer screen shot? can anybody help? You have actually replied only to me, not the maillist > Regards, > Saravanan.S WBR, Sergei ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: some questions about XUP and the generation of ace file
On 8/10/07, windstorm <[EMAIL PROTECTED]> wrote: > Hello all: > > I am trying to transfer the Linux onto XUP board. The kernel source I > used is from the git trees from andrei konovalov or grant likely. But > I encounter two questions now. > > 1 Generally, I should correct the kernel source file > arch/ppc/boot/common/ns16550.c, In that file, changing SERIAL_BAUD > from 9600 to 38400 makes the bootloader talk at 38400. I always do it > when I use standard kernel source. But this time I found out that the > ns16550.c's path is arch/ppc/boot/, not arch/ppc/boot/common/, and > there was no "SERIAL_BAUD" string any more. So, how can I control the > baud rate? ??? I don't know what you're referring to. ns16550.c is in arch/ppc/boot/common on my tree, and it still contains the SERIAL_BAUD #define. > > 2 I have compiled the kernel and obtained a Image.elf whose size is > 1.7MB, and then it's time for creating a system.ace file which I can > put onto a compact flash card. I Changed the file xupGenace.opt like > the follow: You can do this, but I don't think it's a particularly good idea. Binding the kernel image into an ACE file results in a *very* large ace file, and it's slow. Consider the fact that doing it that way means that you're transferring the entire 1.7MB image via JTAG. I've also seem problems where DDR isn't fully initialized before the SystemACE tries to transfer the image which results in a non-booting system. What I do, is I've got a small bootloader that lives in BRAM and is just smart enough to load an elf file off of the CF card. If I can get permission to do so, I'll publish the source for my utility. > > -jprog > -board user > -target ppc_hw > -hw ./implementation/download.bit > -elf zImage.elf > -configdevice devicenr 1 idcode 0x1127e093 irlength 14 partname xc2vp30 > -debugdevice devicenr 1 cpunr 1 > -ace system.ace > > and executed the command: xmd -tcl genace.tcl -opt genace.opt > > and the result I saw is: Using GenACE option file : genace.opt > Error: Executable zImage.elf does not contain start address.. > > I examine the information by google, some said that it's the bug of > development tools without sp, but both my ISE and EDK was patched. > Others said that it's because of the "mb-objdump", we should chage it > into "powerpc-eaci-objdump", and actually I had done this correction. > BUT, the error still here. > > Could anyone please to help me about this question? I will be very grateful. Very odd. I haven't seen this problem myself so I can't be much help. sorry. > > BTW, could any kind person send any basic config file, which had been > proved that the kernel compiled based on it could work good on XUP > board? I don't have that board, sorry g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEX board support]
On 8/10/07, Koss, Mike (Mission Systems) <[EMAIL PROTECTED]> wrote: > > <> > > > > diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > > b/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > > index 01aa043..34d9844 100644 > > > > --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > > +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > > @@ -15,8 +15,12 @@ > > > > > > > > #if defined(CONFIG_XILINX_ML300) > > > > #include "xparameters_ml300.h" > > > > +#elif defined(CONFIG_XILINX_XUPV2P) #include > > > > +"xparameters_xupv2p.h" > > > > #elif defined(CONFIG_XILINX_ML403) > > > > #include "xparameters_ml403.h" > > > > +#elif defined(CONFIG_XILINX_ML41x) > > > > + #include "xparameters_ml41x.h" > > > > #else > > > > /* Add other board xparameter includes here before the #else */ > > > > #error No xparameters_*.h file included > > > > > > see comment above. > > > This whole xparams stuff is a special case; but it is going away for > arch/powerpc. xparameters.h is generated by the xilinx EDK tool and it > is painful to work with in the Linux context. For arch/powerpc, I've > got a tool that generates a device tree from the FPGA hardware design. > > What is the tool that you are using and are you willing to share it at > this point? I'm currently working on some code to generate platform > files for our internal drivers and the ll_temac vs using the ugle > xparam's file. I'd like to not duplicate, or actually assist, any effort > in this area. It's on my git tree; http://git.secretlab.ca I've also got some feedback from the Xilinx folks in the form of a patch, but I haven't integrated it yet. Pretty experimental stuff, I'll probably end up rewriting it from scratch before it's done. Cheers, g. > > -- Mike Koss > > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [RFC PATCH v0.1] net driver: mpc52xx fec
Em Fri, Aug 10, 2007 at 11:51:53AM +0200, Domen Puncer escreveu:
> Hi!
>
> Not for merge (yet)! But please do review.
>
> fec_mpc52xx driver (not in-tree, but floating around) isn't in very
> good shape, so I tried to change that.
> Diff against original is quite big (fec_phy.c is completely rewritten)
> and confuzing, so I'm including whole drivers/net/fec_mpc52xx/ .
>
> I still have 'make CONFIG_FEC_MPC52xx_MDIO=n compile and work' on my
> TODO, maybe even ethtool support.
>
>
> Domen
>
>
> arch/powerpc/boot/dts/lite5200b.dts | 18
> arch/powerpc/sysdev/bestcomm/fec.h | 14
> drivers/net/fec_mpc52xx/Kconfig | 24
> drivers/net/fec_mpc52xx/Makefile|7
> drivers/net/fec_mpc52xx/fec.c | 1002
>
> drivers/net/fec_mpc52xx/fec.h | 299 ++
> drivers/net/fec_mpc52xx/fec_phy.c | 229
> drivers/net/fec_mpc52xx/fec_phy.h | 49 +
> 8 files changed, 1641 insertions(+), 1 deletion(-)
>
> diff -pruN dummy/fec.c ./drivers/net/fec_mpc52xx/fec.c
> --- dummy/fec.c 1970-01-01 01:00:00.0 +0100
> +++ ./drivers/net/fec_mpc52xx/fec.c 2007-08-10 10:59:00.0 +0200
> @@ -0,0 +1,1002 @@
> +/*
> + * drivers/net/fec_mpc52xx/fec.c
> + *
> + * Driver for the MPC5200 Fast Ethernet Controller
> + *
> + * Originally written by Dale Farnsworth <[EMAIL PROTECTED]> and
> + * now maintained by Sylvain Munaut <[EMAIL PROTECTED]>
> + *
> + * Copyright (C) 2007 Sylvain Munaut <[EMAIL PROTECTED]>
> + * Copyrigth (C) 2003-2004 MontaVista, Software, Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + *
> + */
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "fec_phy.h"
> +#include "fec.h"
> +
> +#define DRIVER_NAME "mpc52xx-fec"
> +
> +static irqreturn_t fec_interrupt(int, void *);
> +static irqreturn_t fec_rx_interrupt(int, void *);
> +static irqreturn_t fec_tx_interrupt(int, void *);
> +static struct net_device_stats *fec_get_stats(struct net_device *);
> +static void fec_set_multicast_list(struct net_device *dev);
> +static void fec_hw_init(struct net_device *dev);
> +static void fec_stop(struct net_device *dev);
> +static void fec_start(struct net_device *dev);
> +
> +static u8 mpc52xx_fec_mac_addr[6];
> +static u8 null_mac[6];
const
> +
> +static void fec_tx_timeout(struct net_device *dev)
> +{
> + struct fec_priv *priv = netdev_priv(dev);
> +
> + dev_warn(&dev->dev, "transmit timed out\n");
> +
> + fec_stop(dev);
> + fec_start(dev);
> +
> + priv->stats.tx_errors++;
> +
> + if (!priv->tx_full)
> + netif_wake_queue(dev);
> +}
> +
> +static void fec_set_paddr(struct net_device *dev, u8 *mac)
> +{
> + struct fec_priv *priv = netdev_priv(dev);
> + struct mpc52xx_fec __iomem *fec = priv->fec;
> +
> + out_be32(&fec->paddr1, *(u32*)(&mac[0]));
> + out_be32(&fec->paddr2, (*(u16*)(&mac[4]) << 16) | FEC_PADDR2_TYPE);
spaces after the types on casts to pointers
> +}
> +
> +static void fec_get_paddr(struct net_device *dev, u8 *mac)
> +{
> + struct fec_priv *priv = netdev_priv(dev);
> + struct mpc52xx_fec __iomem *fec = priv->fec;
> +
> + *(u32*)(&mac[0]) = in_be32(&fec->paddr1);
> + *(u16*)(&mac[4]) = in_be32(&fec->paddr2) >> 16;
ditto
> +}
> +
> +static int fec_set_mac_address(struct net_device *dev, void *addr)
> +{
> + struct sockaddr *sock = (struct sockaddr *)addr;
no need for a cast, addr is a void pointer
> +
> + memcpy(dev->dev_addr, sock->sa_data, dev->addr_len);
> +
> + fec_set_paddr(dev, sock->sa_data);
> + return 0;
Why always return 0? make it void
> +}
> +
> +static void fec_free_rx_buffers(struct bcom_task *s)
> +{
> + struct sk_buff *skb;
> +
> + while (!bcom_queue_empty(s)) {
> + skb = bcom_retrieve_buffer(s, NULL, NULL);
> + kfree_skb(skb);
> + }
> +}
> +
> +static int fec_alloc_rx_buffers(struct bcom_task *rxtsk)
> +{
> + while (!bcom_queue_full(rxtsk)) {
> + struct sk_buff *skb;
> + struct bcom_fec_bd *bd;
> +
> + skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
> + if (skb == 0)
Test against NULL
> + return -EAGAIN;
> +
> + /* zero out the initial receive buffers to aid debugging */
> + memset(skb->data, 0, FEC_RX_BUFFER_SIZE);
> +
> + bd = (struct bcom_fec_bd *)bcom_prepare_next_buffer(rxtsk);
> +
> + bd->status = FEC_RX_BUFFER_SIZE;
> + bd->skb_pa = virt_to_phys(skb->data);
> +
> + bcom_submit_next_buffer(rxtsk, skb);
> + }
> +
> + return
some questions about XUP and the generation of ace file
Hello all: I am trying to transfer the Linux onto XUP board. The kernel source I used is from the git trees from andrei konovalov or grant likely. But I encounter two questions now. 1 Generally, I should correct the kernel source file arch/ppc/boot/common/ns16550.c, In that file, changing SERIAL_BAUD from 9600 to 38400 makes the bootloader talk at 38400. I always do it when I use standard kernel source. But this time I found out that the ns16550.c's path is arch/ppc/boot/, not arch/ppc/boot/common/, and there was no "SERIAL_BAUD" string any more. So, how can I control the baud rate? 2 I have compiled the kernel and obtained a Image.elf whose size is 1.7MB, and then it's time for creating a system.ace file which I can put onto a compact flash card. I Changed the file xupGenace.opt like the follow: -jprog -board user -target ppc_hw -hw ./implementation/download.bit -elf zImage.elf -configdevice devicenr 1 idcode 0x1127e093 irlength 14 partname xc2vp30 -debugdevice devicenr 1 cpunr 1 -ace system.ace and executed the command: xmd -tcl genace.tcl -opt genace.opt and the result I saw is: Using GenACE option file : genace.opt Error: Executable zImage.elf does not contain start address.. I examine the information by google, some said that it's the bug of development tools without sp, but both my ISE and EDK was patched. Others said that it's because of the "mb-objdump", we should chage it into "powerpc-eaci-objdump", and actually I had done this correction. BUT, the error still here. Could anyone please to help me about this question? I will be very grateful. BTW, could any kind person send any basic config file, which had been proved that the kernel compiled based on it could work good on XUP board? Thanks again. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
How to increase the kernel stack size
Hi, I want to know how to increase the kernel stack size for 2.4.21 kernel. Thanks, Suresh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: Device Tree tool [was RE: [PATCH] Consolidate XILINX_VIRTEX board support]
<> > > > diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > b/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > index 01aa043..34d9844 100644 > > > --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h > > > @@ -15,8 +15,12 @@ > > > > > > #if defined(CONFIG_XILINX_ML300) > > > #include "xparameters_ml300.h" > > > +#elif defined(CONFIG_XILINX_XUPV2P) #include > > > +"xparameters_xupv2p.h" > > > #elif defined(CONFIG_XILINX_ML403) > > > #include "xparameters_ml403.h" > > > +#elif defined(CONFIG_XILINX_ML41x) > > > + #include "xparameters_ml41x.h" > > > #else > > > /* Add other board xparameter includes here before the #else */ > > > #error No xparameters_*.h file included > > > > see comment above. > This whole xparams stuff is a special case; but it is going away for arch/powerpc. xparameters.h is generated by the xilinx EDK tool and it is painful to work with in the Linux context. For arch/powerpc, I've got a tool that generates a device tree from the FPGA hardware design. What is the tool that you are using and are you willing to share it at this point? I'm currently working on some code to generate platform files for our internal drivers and the ll_temac vs using the ugle xparam's file. I'd like to not duplicate, or actually assist, any effort in this area. -- Mike Koss ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Unwinding stack frame
Hi, We are using MPC 8541 processor. Running Linux 2.6.11. I have a question regarding unwinding stack frame in userland. To understand the stack frame format, I am using gdb to walk through nested function calls frame. I am not able to understand where the PC (program counter) of callee functions is saved on the stack/register. Here are my questions: 1- Is there any available software like "pstack" ported to powerpc that I can use? I know the stack pointer of the last frame is save in "R1" register. 2- How about PC, and number of the input parameters to the function. Many thanks in advance, BZ ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [alsa-devel] [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
At Fri, 10 Aug 2007 13:50:40 +0200, Joachim Förster wrote: > > Hi Takashi, > > again some question came up (while correcting all the other issues): > > On Thu, 2007-08-09 at 19:13 +0200, Takashi Iwai wrote: > > > +static int __init > > > +snd_ml403_ac97cr_create(struct snd_card *card, struct platform_device > > > *pfdev, > > > + struct snd_ml403_ac97cr **rml403_ac97cr) > > > > It's no longer __init as long as you use platform_device. > > It should be __devinit instead. > > Ok, I changed that (for create(), pcm(), mixer(), etc.). Do I have to > change it for the module_init and module_exit functions, too? I guess, > they are not in the "scope" of platform device, right? So, they will > keep __init / __exit ? Yes, they can be __init & __exit. > > > --- /dev/null > > > +++ b/sound/ppc/pcm-indirect2.h > > (snip) > > > +#ifdef SND_PCM_INDIRECT2_STAT > > > +static inline void snd_pcm_indirect2_stat(struct snd_pcm_substream > > > *substream, > > > + struct snd_pcm_indirect2 *rec) > > > > Remove inline from the functions in this file. They are too lengthy. > > > > sound/pcm-indirect.h contain inline functions becuase they are > > relatively small, and I didn't want to add them in the core module > > unconditionally. > > I looked at my functions again. And I think we could still go with > inline for the *_interrupt() and *_pointer() functions since they have > just a few lines. > With both *_transfer() functions - I don't know. In fact they shouldn't > be much longer than yours in pcm-indirect.h . They seem long, because > there are lot of comments and the #ifdef SND_PCM_INDIRECT2_STAT stuff, > which is/was a debugging feature, which _won't_ be compiled in without > CONFIG_SND_DEBUG. IMO, the inline isn't usually necessary unless it hits really the performance. Let the compiler optimize the codes. The size reduction often wins in the end than inlining. > [I removed inline from the _stat() and _min_periods() function - that's > true, they are too long.] > > The other thing I thought about, is: Is it ok to have non-inline > functions in a header file? Don't we need a .c file + .h ? (Are there > any CodingStyle rules about that?) Yeah, *.c sounds more appropriate. Takashi ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [alsa-devel] [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
Hi Takashi, again some question came up (while correcting all the other issues): On Thu, 2007-08-09 at 19:13 +0200, Takashi Iwai wrote: > > +static int __init > > +snd_ml403_ac97cr_create(struct snd_card *card, struct platform_device > > *pfdev, > > + struct snd_ml403_ac97cr **rml403_ac97cr) > > It's no longer __init as long as you use platform_device. > It should be __devinit instead. Ok, I changed that (for create(), pcm(), mixer(), etc.). Do I have to change it for the module_init and module_exit functions, too? I guess, they are not in the "scope" of platform device, right? So, they will keep __init / __exit ? > > --- /dev/null > > +++ b/sound/ppc/pcm-indirect2.h > (snip) > > +#ifdef SND_PCM_INDIRECT2_STAT > > +static inline void snd_pcm_indirect2_stat(struct snd_pcm_substream > > *substream, > > + struct snd_pcm_indirect2 *rec) > > Remove inline from the functions in this file. They are too lengthy. > > sound/pcm-indirect.h contain inline functions becuase they are > relatively small, and I didn't want to add them in the core module > unconditionally. I looked at my functions again. And I think we could still go with inline for the *_interrupt() and *_pointer() functions since they have just a few lines. With both *_transfer() functions - I don't know. In fact they shouldn't be much longer than yours in pcm-indirect.h . They seem long, because there are lot of comments and the #ifdef SND_PCM_INDIRECT2_STAT stuff, which is/was a debugging feature, which _won't_ be compiled in without CONFIG_SND_DEBUG. [I removed inline from the _stat() and _min_periods() function - that's true, they are too long.] The other thing I thought about, is: Is it ok to have non-inline functions in a header file? Don't we need a .c file + .h ? (Are there any CodingStyle rules about that?) Joachim ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[RFC PATCH v0.1] net driver: mpc52xx fec
Hi!
Not for merge (yet)! But please do review.
fec_mpc52xx driver (not in-tree, but floating around) isn't in very
good shape, so I tried to change that.
Diff against original is quite big (fec_phy.c is completely rewritten)
and confuzing, so I'm including whole drivers/net/fec_mpc52xx/ .
I still have 'make CONFIG_FEC_MPC52xx_MDIO=n compile and work' on my
TODO, maybe even ethtool support.
Domen
arch/powerpc/boot/dts/lite5200b.dts | 18
arch/powerpc/sysdev/bestcomm/fec.h | 14
drivers/net/fec_mpc52xx/Kconfig | 24
drivers/net/fec_mpc52xx/Makefile|7
drivers/net/fec_mpc52xx/fec.c | 1002
drivers/net/fec_mpc52xx/fec.h | 299 ++
drivers/net/fec_mpc52xx/fec_phy.c | 229
drivers/net/fec_mpc52xx/fec_phy.h | 49 +
8 files changed, 1641 insertions(+), 1 deletion(-)
diff -pruN dummy/fec.c ./drivers/net/fec_mpc52xx/fec.c
--- dummy/fec.c 1970-01-01 01:00:00.0 +0100
+++ ./drivers/net/fec_mpc52xx/fec.c 2007-08-10 10:59:00.0 +0200
@@ -0,0 +1,1002 @@
+/*
+ * drivers/net/fec_mpc52xx/fec.c
+ *
+ * Driver for the MPC5200 Fast Ethernet Controller
+ *
+ * Originally written by Dale Farnsworth <[EMAIL PROTECTED]> and
+ * now maintained by Sylvain Munaut <[EMAIL PROTECTED]>
+ *
+ * Copyright (C) 2007 Sylvain Munaut <[EMAIL PROTECTED]>
+ * Copyrigth (C) 2003-2004 MontaVista, Software, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "fec_phy.h"
+#include "fec.h"
+
+#define DRIVER_NAME "mpc52xx-fec"
+
+static irqreturn_t fec_interrupt(int, void *);
+static irqreturn_t fec_rx_interrupt(int, void *);
+static irqreturn_t fec_tx_interrupt(int, void *);
+static struct net_device_stats *fec_get_stats(struct net_device *);
+static void fec_set_multicast_list(struct net_device *dev);
+static void fec_hw_init(struct net_device *dev);
+static void fec_stop(struct net_device *dev);
+static void fec_start(struct net_device *dev);
+
+static u8 mpc52xx_fec_mac_addr[6];
+static u8 null_mac[6];
+
+static void fec_tx_timeout(struct net_device *dev)
+{
+ struct fec_priv *priv = netdev_priv(dev);
+
+ dev_warn(&dev->dev, "transmit timed out\n");
+
+ fec_stop(dev);
+ fec_start(dev);
+
+ priv->stats.tx_errors++;
+
+ if (!priv->tx_full)
+ netif_wake_queue(dev);
+}
+
+static void fec_set_paddr(struct net_device *dev, u8 *mac)
+{
+ struct fec_priv *priv = netdev_priv(dev);
+ struct mpc52xx_fec __iomem *fec = priv->fec;
+
+ out_be32(&fec->paddr1, *(u32*)(&mac[0]));
+ out_be32(&fec->paddr2, (*(u16*)(&mac[4]) << 16) | FEC_PADDR2_TYPE);
+}
+
+static void fec_get_paddr(struct net_device *dev, u8 *mac)
+{
+ struct fec_priv *priv = netdev_priv(dev);
+ struct mpc52xx_fec __iomem *fec = priv->fec;
+
+ *(u32*)(&mac[0]) = in_be32(&fec->paddr1);
+ *(u16*)(&mac[4]) = in_be32(&fec->paddr2) >> 16;
+}
+
+static int fec_set_mac_address(struct net_device *dev, void *addr)
+{
+ struct sockaddr *sock = (struct sockaddr *)addr;
+
+ memcpy(dev->dev_addr, sock->sa_data, dev->addr_len);
+
+ fec_set_paddr(dev, sock->sa_data);
+ return 0;
+}
+
+static void fec_free_rx_buffers(struct bcom_task *s)
+{
+ struct sk_buff *skb;
+
+ while (!bcom_queue_empty(s)) {
+ skb = bcom_retrieve_buffer(s, NULL, NULL);
+ kfree_skb(skb);
+ }
+}
+
+static int fec_alloc_rx_buffers(struct bcom_task *rxtsk)
+{
+ while (!bcom_queue_full(rxtsk)) {
+ struct sk_buff *skb;
+ struct bcom_fec_bd *bd;
+
+ skb = dev_alloc_skb(FEC_RX_BUFFER_SIZE);
+ if (skb == 0)
+ return -EAGAIN;
+
+ /* zero out the initial receive buffers to aid debugging */
+ memset(skb->data, 0, FEC_RX_BUFFER_SIZE);
+
+ bd = (struct bcom_fec_bd *)bcom_prepare_next_buffer(rxtsk);
+
+ bd->status = FEC_RX_BUFFER_SIZE;
+ bd->skb_pa = virt_to_phys(skb->data);
+
+ bcom_submit_next_buffer(rxtsk, skb);
+ }
+
+ return 0;
+}
+
+/* based on generic_adjust_link - fs_enet-main.c */
+static void fec_adjust_link(struct net_device *dev)
+{
+ struct fec_priv *priv = netdev_priv(dev);
+ struct phy_device *phydev = priv->phydev;
+ int new_state = 0;
+
+ if (phydev->link != PHY_DOWN) {
+ if (phydev->duplex != priv->duplex) {
+ new_state = 1;
+ priv->duplex = phydev->duplex;
+ }
+
+ if (phydev->spe
Re: [PATCH] Consolidate XILINX_VIRTEX board support
> "GL" == Grant Likely <[EMAIL PROTECTED]> writes: Hi, WR> -boot-$(CONFIG_XILINX_ML300)+= embed_config.o WR> -boot-$(CONFIG_XILINX_ML403)+= embed_config.o WR> +boot-$(CONFIG_XILINX_VIRTEX) += embed_config.o >> >> Don't do that. Other boards with Xilinx FPGAs don't necessarily need >> embed_config.c GL> Then post patches for those boards so we can properly support the GL> different configuration. Also if the boards are not generally available? No problem for me, but I don't quite see the point. -- Bye, Peter Korsgaard ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
