> I think you should modify the bootargs on your dts.
> --
> chosen {
> bootargs = "console=ttyS0 root=/dev/ram";
> linux,stdout-path = "/p...@0/ser...@83e0";
> } ;
Thanks, that worked great, I now have a fully bootable not only kernel, but
Guillaume Dargaud wrote:
>> I think you should modify the bootargs on your dts.
>> --
>> chosen {
>> bootargs = "console=ttyS0 root=/dev/ram";
>> linux,stdout-path = "/p...@0/ser...@83e0";
>> } ;
>
> Thanks, that worked great, I now have a fu
On Fri, Sep 17, 2010 at 03:01:08PM +0800, Roy Zang wrote:
[...]
> +static struct mutex fsl_elbc_nand_mutex;
> +
> +static int __devinit fsl_elbc_nand_probe(struct platform_device *dev)
> {
> - struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
> + struct fsl_lbc_regs __iomem *lbc;
> stru
Hi Milton,
sorry for the delayed answer, was on vacation.
linux-kernel-ow...@vger.kernel.org wrote on 21.05.2010 11:18:01:
> linux-kernel-ow...@vger.kernel.org
>
> On Thu, 20 May 2010 at 10:21:36 +0200 (CEST) Thomas Gleixner wrote:
> > On Thu, 20 May 2010, Michael Ellerman wrote:
> > > On Wed, 2
Andrew Morton wrote:
>
> > @@ -219,6 +219,7 @@ struct rio_net {
> > /**
> > * struct rio_switch - RIO switch info
> > * @node: Node in global list of switches
> > + * @rdev: Associated RIO device structure
> > * @switchid: Switch ID that is unique across a network
> > * @hopcount: Hopcou
On Thu, 19 Aug 2010 23:08:09 -0500
Sonny Rao wrote:
> Some modules (like eHCA) want to map all of kernel memory, for this to
> work with a relocated kernel, we need to export kernstart_addr so
> modules can use PHYSICAL_START and memstart_addr so they could use
> MEMORY_START. Note that the 32bi
On Fri, Sep 17, 2010 at 03:01:07PM +0800, Roy Zang wrote:
[...]
> +struct fsl_lbc_ctrl {
> + /* device info */
> + struct device *dev;
Forward declaration for struct device is needed (and enough).
> + struct fsl_lbc_regs __iomem *regs;
> + int
On Sun, 19 Sep 2010 09:40:15 +0800
"tiejun.chen" wrote:
> Scott Wood wrote:
> > On Fri, 17 Sep 2010 09:58:41 +0800
> > "tiejun.chen" wrote:
> >
> >> Scott Wood wrote:
> >>> The guest OS *is* the same as native Linux, as far as TLB handling is
> >>> concerned.
> >> Looks you means the TLB except
On Fri, Sep 17, 2010 at 7:37 PM, Josh Boyer wrote:
>> config BOOKE_WDT
>> - bool "PowerPC Book-E Watchdog Timer"
>> + tristate "PowerPC Book-E Watchdog Timer"
>> depends on BOOKE || 4xx
>> ---help---
>> + Watchdog driver for PowerPC e500 chips, such as the Freesc
Export the global variable 'ppc_tb_freq', so that modules (like the Book-E
watchdog driver) can use it. To maintain consistency, ppc_proc_freq is changed
to a GPL-only export. This is okay, because any module that needs this symbol
should be an actual Linux driver, which must be GPL-licensed.
Si
Register the __init and __exit functions in the PowerPC e500 watchdog driver
as module entry/exit functions, and modify the Kconfig entry.
Add a .release method for the PowerPC e500 watchdog driver, so that the
watchdog is disabled when the driver is closed.
Loosely based on original code from Ji
>> I have a cuImage kernel in order to support legacy u-boot and a
>> ramdisk image. Kernel boots fine if these two images are separate and
>> "bootm $kernel $ramdisk" is used. But I can not make it to work using
>> a single multi image that contains the kernel and ramdisk images. Is
>> it even tec
Mr. Wolfgang
>
> Will this driver ever include any 40x processors? If not, you probably
> should use "44x" instead (here and everywhere in the rest of the
> code).
[Marri] Yes there is 40x based DMA engine we planned to include in the
future.
> > +/* Pointer to DMA0, DMA1 CP/CS FIFO */
> > +static
On Sat, 18 Sep 2010 14:22:12 -0400
Josh Boyer wrote:
> Capitalizing? The patch you posted that uses this symbol is for a GPL
> driver so you gain or lose nothing by having this symbol be
> EXPORT_SYMBOL_GPL. Are you somehow advocating and getting some sort
> of gain by allowing non-GPL modules?
On Mon, 20 Sep 2010 07:31:22 -0700
"Bounine, Alexandre" wrote:
> Andrew Morton wrote:
> >
> > > @@ -219,6 +219,7 @@ struct rio_net {
> > > /**
> > > * struct rio_switch - RIO switch info
> > > * @node: Node in global list of switches
> > > + * @rdev: Associated RIO device structure
> > >
On Mon, Sep 20, 2010 at 10:51:37AM -0500, Timur Tabi wrote:
>On Fri, Sep 17, 2010 at 7:37 PM, Josh Boyer wrote:
>>> config BOOKE_WDT
>>> - bool "PowerPC Book-E Watchdog Timer"
>>> + tristate "PowerPC Book-E Watchdog Timer"
>>> depends on BOOKE || 4xx
>>> ---help---
>>> +
On Mon, Sep 20, 2010 at 11:23:41AM -0500, Timur Tabi wrote:
>Export the global variable 'ppc_tb_freq', so that modules (like the Book-E
>watchdog driver) can use it. To maintain consistency, ppc_proc_freq is changed
>to a GPL-only export. This is okay, because any module that needs this symbol
>s
Andrew Morton wrote:
>
> The "variable length array at the end of the struct" thing is pretty
> commonly used and works well. As long as we never want to change the
> number of switches on the fly (hotplug?).
This is expected to be a "strange" array - its size can be 0 or 1 only.
No number of s
Josh Boyer wrote:
> I guess I don't see what you mean. It talks about e500 but it doesn't
> say "Book-E" anywhere in that comment. (Though I'm pretty sure that
> comment does apply to 4xx.)
That was my point. The comment says e500, but the code is also intended for
4xx.
--
Timur Tabi
Linux ke
Hi Alex,
Bounine, Alexandre wrote:
struct rio_dev {
struct list_head global_list;
struct list_head net_list;
.
. rest of rio_dev
.
struct rio_switch switch[0];
}
It makes sense to let rio_dev structures point to the switch they are
attached to. That can be
Dear Tirumala Marri,
In message <7707889dee57e97ad50b4ce5c7697...@mail.gmail.com> you wrote:
>
> > > +/**
> > > + * ppc440spe_can_rxor - check if the operands may be processed with RXOR
> > > + */
> > > +static int ppc440spe_can_rxor(struct page **srcs, int src_cnt,
> > size_t len)
> >
> > Again,
> -Original Message-
> From: Scott Wood [mailto:scottw...@freescale.com]
> Sent: Monday, September 20, 2010 11:44 PM
> To: Chen, Tiejun
> Cc: linuxppc-dev@lists.ozlabs.org; Guillaume Dargaud
> Subject: Re: Generating elf kernel ?
>
> On Sun, 19 Sep 2010 09:40:15 +0800
> "tiejun.chen" wro
> -Original Message-
> From: Shawn Jin [mailto:shawnx...@gmail.com]
> Sent: Tuesday, September 21, 2010 1:53 AM
> To: Chen, Tiejun
> Cc: ppcdev; uboot
> Subject: Re: cuImage and multi image?
>
> >> I have a cuImage kernel in order to support legacy u-boot and a
> >> ramdisk image. Kernel
23 matches
Mail list logo
