* Re: can and mpc5200b
From: S. Fricke @ 2007-10-17 14:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <f87351060710150705l5e4d1ba5v6806686cd25418bb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
Hello list,
> > Hello Friends,
> > what is the reasonable can-driver for a mpc5200b?
> >
> > I have seen for the peak-3.17 driver a port for the mpc5200 from denx on their
> > website, but with kernel 2.6.23 I dont have a chance to use this?
>
> Check this out http://developer.berlios.de/projects/socketcan/ . This
> is the CAN driver we use and it works pretty well for us. It is very
> updated and supports the mscan chipset that is available with the
> mpc5200b.
Socketcan works for me perfectly with the canconfig tool.
Thank you.
Silvio
Mit freundlichen Gruessen
Silvio Fricke
--
-- S. Fricke ----------------------------- MAILTO:silvio.fricke@gmail.com --
Diplom-Informatiker (FH)
Linux-Entwicklung
----------------------------------------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: Grant Likely @ 2007-10-17 14:54 UTC (permalink / raw)
To: aauer1; +Cc: linuxppc-embedded
In-Reply-To: <13252272.post@talk.nabble.com>
On 10/17/07, aauer1 <aauer1@gmx.at> wrote:
> I was able to look at the __log_buf variable with the JTAG cable. So, I
> recognized that the kernel doesn't halt after the "No booting the kernel"
> message. There are many output messages in the __log_buf variable until it
> stops at with a "Kernel panic" because the rootfs is not found (but this is
> the minor problem).
> Now, I know that the kernel boots but I don't get an output with my Xilinx
> UartLite module. Are there some kernel modules which must be activated??
> Btw. I have used the Linux-2.6-virtex kernel from
> http://git.secretlab.ca/git/ and another Kernel (2.6.23 from kernel.org) -
> both with the same result.
Post the output of __log_buf here please.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 01/15] [POWERPC] TQM5200 DTS
From: Grant Likely @ 2007-10-17 14:57 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4715ED92.80503@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
> Grant Likely wrote:
> >> + memory {
> >> + device_type = "memory";
> >> + reg = <00000000 04000000>; // 64MB
> >> + };
> >> +
> >> + soc5200@f0000000 {
> >
> > I think we're moving to the convetion of naming these nodes
> > "soc@<addr>" now. (You can drop the 5200 for the node name)
>
> Seems that this will not be painless, U-boot uses hardcoded
> paths with 'soc5200', so the appropriate patch will be needed.
> That may be ok for new boards but what do we do with lite5200,
> where U-boot upgrade is not always an option?
Hmm; yeah I guess there are probably already deployed tqm5200 boards
with hard coded soc5200. Alright; leave it as is.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] powerpc: Fix 64 bits vDSO dwarf info for CR register
From: Andrew Haley @ 2007-10-17 14:00 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Deepak Bhole, linuxppc-dev list, Benjamin Herrenschmidt,
Paul Mackerras, Alan Modra
In-Reply-To: <20071017135055.GP5451@devserv.devel.redhat.com>
Jakub Jelinek writes:
> On Wed, Oct 17, 2007 at 02:26:50PM +1000, Benjamin Herrenschmidt wrote:
> > Unfortunately, a bug in gcc cause it to not quite work either, but that
> > is being fixed separately with something around the lines of:
> >
> > linux-unwind.h:
> >
> > fs->regs.reg[R_CR2].loc.offset = (long) ®s->ccr - new_cfa;
> > + /* CR? regs are just 32-bit and PPC is big-endian. */
> > + fs->regs.reg[R_CR2].loc.offset += sizeof (long) - 4;
>
> Small correction. If vdso is present, then fixing the vdso is all that is
> needed, the above mentioned code is used only if the vdso is not present
> (or if glibc doesn't support the vdso).
Perhaps we should test this change with a hacked libgcc, just to make
sure it fixes the bug.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
^ permalink raw reply
* Re: [PATCH 04/15] [POWERPC] CM5200 DTS
From: Grant Likely @ 2007-10-17 14:59 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <4715FE6C.2070201@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
> David Gibson wrote:
> > [snip]
> >> + flash@c000000 {
> >> + device_type = "rom";
> >> + compatible = "direct-mapped";
> >> + reg = <0c000000 02000000>;
> >> + probe-type = "CFI";
> >> + bank-width = <2>;
> >> + partitions = <00000000 00060000
> >> + 00060000 00020000
> >> + 00080000 00020000
> >> + 000a0000 00020000
> >> + 000c0000 00200000
> >> + 002c0000 01b40000
> >> + 01e00000 00200000>;
> >> + partition-names = "uboot\0env\0redund_env\0dtb\0kernel\0rootfs\0config";
> >> + };
> >
> > First, this is the old flash binding, please use the new one.
>
> Ok.
>
> > Second, is the flash really part of the SoC?
>
> Not directly, it is attached to LocalPlus Bus Controller, which is
> part of the SoC. And the soc@ is currently the only recognized of bus
> for mpc5200, so if we want to move it to some other place new bindings
> will need to be defined for lpc (LocalPlus Controller) bus. But I am
> not quite sure where this should be attached. Bus is under LPC which
> is a part of the SoC, but on the other hand Soc address range covers
> only device control registers not the address space LPC may handle
> (that may be varied). Any ideas?
My vote is for an lpc node off the root of the tree for devices like
this to hang off.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/4] [POWERPC] Add mpc52xx_find_and_map_path(), refactor utility functions
From: Grant Likely @ 2007-10-17 15:02 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <47160709.5020002@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add helper routine mpc52xx_find_and_map_path(). Extract common code to
> mpc52xx_map_node() and refactor mpc52xx_find_and_map().
>
> Signed-off-by: Jan Wrobel <wrr@semihalf.com>
> Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
Yeah, this is probably okay. Eventually these util functions should
be refactored to be usable by any platform.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 2/4] [POWERPC] Update device tree binding for mpc5200 gpt
From: Grant Likely @ 2007-10-17 15:12 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4716074E.80903@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add 'fsl,' prefix to 'compatible' property for gpt nodes.
> Add 'fsl,' prefix to empty, GPT0 specific 'has-wdt' property.
>
> diff --git a/drivers/char/watchdog/mpc5200_wdt.c b/drivers/char/watchdog/mpc5200_wdt.c
> index 564143d..9aaba7a 100644
> --- a/drivers/char/watchdog/mpc5200_wdt.c
> +++ b/drivers/char/watchdog/mpc5200_wdt.c
> @@ -174,7 +174,7 @@ static int mpc5200_wdt_probe(struct of_d
> const void *has_wdt;
> int size;
>
> - has_wdt = of_get_property(op->node, "has-wdt", NULL);
> + has_wdt = of_get_property(op->node, "fsl,has-wdt", NULL);
> if (!has_wdt)
> return -ENODEV;
Do this instead:
has_wdt = of_get_property(op->node, "has-wdt", NULL);
+ if (!has_wdt)
+ has_wdt = of_get_property(op->node, "fsl,has-wdt", NULL);
if (!has_wdt)
return -ENODEV;
This will allow it to still work with older device trees.
>
> @@ -253,7 +253,7 @@ static int mpc5200_wdt_shutdown(struct o
> }
>
> static struct of_device_id mpc5200_wdt_match[] = {
> - { .compatible = "mpc5200-gpt", },
> + { .compatible = "fsl,mpc5200-gpt", },
Keep both the old and new in the match table for now for the same reason.
Otherwise, looks good. Thanks.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Joachim Fenkes @ 2007-10-17 15:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Q Klein, Jeff Garzik, Paul Mackerras, netdev,
Jan-Bernd Themann, LKML, LinuxPPC-Dev, Christoph Raisch,
Paul Mackerras, Marcus Eder, Stefan Roscher
In-Reply-To: <20071017012706.adbd3188.sfr@canb.auug.org.au>
On Tuesday 16 October 2007 17:27, Stephen Rothwell wrote:
> One small change - I intend to remove the name and owner fields from
> struct of_platform_driver, so you should not bother initialising the name
> field and just initialise the name field of the embedded struct
> device_driver instead. This, of course, means that you don't need
>
> drv->driver.name = drv->name;
>
> in ibmebus_register_driver.
I'd prefer to let this line stay in place until you actually make your
change, to keep the data structures consistent as long as the name field is
present. You could remove it in your patch then.
Regards,
Joachim
^ permalink raw reply
* Re: [PATCH] qe_lib: export symbols to fix compile error when QE drivers compile as modules
From: Kumar Gala @ 2007-10-17 15:30 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev list, Timur Tabi
In-Reply-To: <24BADA7A-1716-43B1-BC92-F4DB7ED0D331@kernel.crashing.org>
On May 25, 2007, at 7:15 AM, Kumar Gala wrote:
>
> On May 24, 2007, at 9:45 PM, Li Yang-r58472 wrote:
>
>>
>>> -----Original Message-----
>>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>>> Sent: Thursday, May 24, 2007 7:44 PM
>>> To: Li Yang-r58472
>>> Cc: Paul; linuxppc-dev@ozlabs.org
>>> Subject: Re: [PATCH] qe_lib: export symbols to fix compile error
>>> when
>> QE drivers
>>> compile as modules
>>>
>>>
>>> On May 24, 2007, at 4:14 AM, Li Yang wrote:
>>>
>>>> Export symbols of qe_lib to be used by QE drivers.
>>>>
>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>> ---
>>>> arch/powerpc/sysdev/qe_lib/ucc.c | 7 +++++++
>>>> arch/powerpc/sysdev/qe_lib/ucc_fast.c | 8 ++++++++
>>>> arch/powerpc/sysdev/qe_lib/ucc_slow.c | 12 ++++++++++--
>>>> 3 files changed, 25 insertions(+), 2 deletions(-)
>>>
>>> A number of the EXPORT_SYMBOL() are not used by any in kernel
>>> drivers
>>> and thus should not be added. See comments below. Also, should
>>> these be EXPORT_SYMBOL_GPL().
>>
>> Some of them are not used by in kernel driver, but they are used by
>> some
>> off kernel drivers and driver in development. Shouldn't we export
>> them?
>
> Nope, its been a pretty established rule that we don't export symbols
> for drivers not in the kernel. These drivers should really be
> submitted for acceptance into the kernel and than we can export the
> symbols they need.
>
> While I can see a need for the *slow* symbols to be exported until
> there is a driver needing them we shouldn't export the symbols.
>
>> I know Linux is again non-GPL modules, but Freescale won't be forcing
>> customers to use GPL as long as Linux doesn't ban non-GPL module
>> completely.
>
> That's fine.
>
>>>> static void get_cmxucr_reg(int ucc_num, volatile u32 ** p_cmxucr,
>>>> u8 * reg_num,
>>>> u8 * shift)
>>>> @@ -122,6 +126,7 @@ static void get_cmxucr_reg(int ucc_num,
>>>> volatile u32 ** p_cmxucr, u8 * reg_num,
>>>> break;
>>>> }
>>>> }
>>>> +EXPORT_SYMBOL(get_cmxucr_reg);
>>>
>>> remove, you shouldn't be exporting something marked static.
>>
>> Good catch.
>>
>> Thanks,
>> Leo
What happened with this?
- k
^ permalink raw reply
* Re: [PATCH 3/4] [POWERPC] Add restart support for mpc52xx based platforms
From: Grant Likely @ 2007-10-17 15:30 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <471607A8.6050203@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Add common helper routines: mpc52xx_map_wdt() and mpc52xx_restart().
>
> This patch relies on Sascha Hauer's patch published in:
> http://patchwork.ozlabs.org/linuxppc/patch?id=8910.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 45 +++++++++++++++++++++++++++
> include/asm-powerpc/mpc52xx.h | 3 +
> 2 files changed, 48 insertions(+)
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> index 74b4b41..553937b 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
> @@ -18,6 +18,13 @@ #include <asm/io.h>
> #include <asm/prom.h>
> #include <asm/mpc52xx.h>
>
> +/*
> + * This variable is mapped in mpc52xx_map_wdt() and used in mpc52xx_restart().
> + * Permanent mapping is required because mpc52xx_restart() can be called
> + * from interrupt context while node mapping (which calls iorenmap())
> + * cannot be used at such point.
> + */
> +static volatile struct mpc52xx_gpt *mpc52xx_wdt = NULL;
>
> static void __iomem *
> mpc52xx_map_node(struct device_node *ofn)
> @@ -126,3 +133,41 @@ mpc52xx_declare_of_platform_devices(void
> "Error while probing of_platform bus\n");
> }
>
> +void __init
> +mpc52xx_map_wdt(void)
> +{
> + const void *has_wdt;
> + struct device_node *np;
> +
> + /* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
> + * possibly from a interrupt context. */
> +
> + for (np = NULL;
> + (np = of_find_compatible_node(np, NULL, "fsl,mpc5200-gpt")) != NULL;
> + ) {
> + /* wdt is only implement on gpt0, check has-wdt property. */
> + has_wdt = of_get_property(np, "fsl,has-wdt", NULL);
Test for both "has-wdt" and "fsl,has-wdt" for now.
Otherwise, looks good.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 4/4] [POWERPC] Enable restart support for lite5200 board
From: Grant Likely @ 2007-10-17 15:31 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <471607DB.4060509@semihalf.com>
On 10/17/07, Marian Balakowicz <m8@semihalf.com> wrote:
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Looks good; I'll pick this one up when you respin the others.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Stephen Hemminger @ 2007-10-17 15:31 UTC (permalink / raw)
To: benh; +Cc: netdev, Roland Dreier, David S. Miller, Jeff Garzik,
linuxppc-dev list
In-Reply-To: <1192591481.11899.134.camel@pasglop>
Please don't use double underscore, for this function name. There is no
reason to not make it a normal API call.
The sky2 fix I am working on will use napi_synchronize as well.
--- a/include/linux/netdevice.h 2007-10-16 16:48:20.000000000 -0700
+++ b/include/linux/netdevice.h 2007-10-17 08:29:55.000000000 -0700
@@ -407,6 +407,24 @@ static inline void napi_enable(struct na
clear_bit(NAPI_STATE_SCHED, &n->state);
}
+#ifdef CONFIG_SMP
+/**
+ * napi_synchronize - wait until NAPI is not running
+ * @n: napi context
+ *
+ * Wait until NAPI is done being scheduled on this context.
+ * Any outstanding processing completes but
+ * does not disable future activations.
+ */
+static inline void napi_synchronize(const struct napi_struct *n)
+{
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ msleep(1);
+}
+#else
+# define napi_synchronize(n) barrier()
+#endif
+
/*
* The DEVICE structure.
* Actually, this whole structure is a big mistake. It mixes I/O
^ permalink raw reply
* Re: mpc 860 boot linux2.6.23 problem
From: Scott Wood @ 2007-10-17 15:31 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <85100356-D95B-4343-98BE-66080EA9887D@embeddedalley.com>
Dan Malek wrote:
>
> On Oct 16, 2007, at 12:18 PM, Scott Wood wrote:
>
>> Upgrading to the latest u-boot certainly shouldn't hurt, but I don't
>> think there's any device tree support for 8xx yet,
>
> Have you tried it? Works for me. In fact, most
> of the development you see today was done
> by Pantelis on the 8xx.
I just pulled Wolfgang's latest u-boot tree, and I don't see any fdt or
ft_ calls in cpu/mpc8xx, nor in any 8xx board that I recognize.
I may have been unclear in that I was talking about device tree support
in u-boot, not the kernel. Obviously there's device tree support in the
kernel, as evidenced by my reference to using cuImage.
-Scott
^ permalink raw reply
* Re: [POWERPC 03/15] [POWERPC] TQM5200 board support
From: Scott Wood @ 2007-10-17 15:33 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev
In-Reply-To: <4715F51D.2060000@semihalf.com>
Marian Balakowicz wrote:
> Scott Wood wrote:
>>> +void tqm5200_show_cpuinfo(struct seq_file *m)
>>> +{
>>> + struct device_node* np = of_find_all_nodes(NULL);
>>> + const char *model = NULL;
>>> +
>>> + if (np)
>>> + model = of_get_property(np, "model", NULL);
>>> +
>>> + seq_printf(m, "vendor\t\t: Freescale Semiconductor\n");
>>> + seq_printf(m, "machine\t\t: %s\n", model ? model : "unknown");
>>> +
>>> + of_node_put(np);
>>> +}
>> Get rid of this.
>
> Agree, that may be overhead in some cases. But there would be also
> cases where printing out a machine name would be informative. CM5200
> is one such example, there are several variants of the hw and platform
> name is too generic.
Maybe, though if we're going to do that it'd be better to just print
/model in the generic cpuinfo (or somewhere else generic). And there's
always /proc/device-tree/model...
-Scott
^ permalink raw reply
* Re: [PATCH v2 1/4] Implement {read,update}_persistent_clock.
From: Sergei Shtylyov @ 2007-10-17 15:34 UTC (permalink / raw)
To: Tony Breeds
Cc: linuxppc-dev, Thomas Gleixner, Paul Mackerras, Realtime Kernel
In-Reply-To: <1190345162.620000.305760830507.qpush@thor>
Hello.
Tony Breeds wrote:
> With these functions implemented we cooperate better with the generic
> timekeeping code. This obsoletes the need for the timer sysdev as a bonus.
Aha, I'm seeing it's not merged to mainline yet! And this can't be merged
to -rt patch either, beucase -rt alsready has read_persistent_clock()
implemented since around 2.6.18-rt...
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
> Patch set updated to powerpc/for-2.6.24
> * Compile tested for arch/powerpc/configs/*_defconfig
> * Booted on pSeries, iSeries, Cell and PS3
> arch/powerpc/Kconfig | 3 +
> arch/powerpc/kernel/time.c | 85 ++++++++++-------------------------
> arch/powerpc/sysdev/Makefile | 5 --
> arch/powerpc/sysdev/timer.c | 81 ---------------------------------
> 4 files changed, 29 insertions(+), 145 deletions(-)
>
> Index: working/arch/powerpc/Kconfig
> ===================================================================
> --- working.orig/arch/powerpc/Kconfig
> +++ working/arch/powerpc/Kconfig
> @@ -21,6 +21,9 @@ config MMU
> bool
> default y
>
> +config GENERIC_CMOS_UPDATE
> + def_bool y
> +
> config GENERIC_HARDIRQS
> bool
> default y
> Index: working/arch/powerpc/kernel/time.c
> ===================================================================
> --- working.orig/arch/powerpc/kernel/time.c
> +++ working/arch/powerpc/kernel/time.c
> @@ -881,12 +837,35 @@ void __init generic_calibrate_decr(void)
> #endif
> }
>
> -unsigned long get_boot_time(void)
> +int update_persistent_clock(struct timespec now)
> {
> struct rtc_time tm;
>
> - if (ppc_md.get_boot_time)
> - return ppc_md.get_boot_time();
> + if (!ppc_md.set_rtc_time)
> + return 0;
> +
> + to_tm(now.tv_sec + 1 + timezone_offset, &tm);
> + tm.tm_year -= 1900;
> + tm.tm_mon -= 1;
> +
> + return ppc_md.set_rtc_time(&tm);
> +}
> +
> +unsigned long read_persistent_clock(void)
> +{
> + struct rtc_time tm;
> + static int first = 1;
> +
> + /* XXX this is a litle fragile but will work okay in the short term */
> + if (first) {
> + first = 0;
> + if (ppc_md.time_init)
> + timezone_offset = ppc_md.time_init();
> +
> + /* get_boot_time() isn't guaranteed to be safe to call late */
> + if (ppc_md.get_boot_time)
> + return ppc_md.get_boot_time() -timezone_offset;
> + }
This looks incomplete.
> @@ -898,14 +877,10 @@ unsigned long get_boot_time(void)
> void __init time_init(void)
> {
> unsigned long flags;
> - unsigned long tm = 0;
> struct div_result res;
> u64 scale, x;
> unsigned shift;
>
> - if (ppc_md.time_init != NULL)
> - timezone_offset = ppc_md.time_init();
> -
> if (__USE_RTC()) {
> /* 601 processor: dec counts down by 128 every 128ns */
> ppc_tb_freq = 1000000000;
> @@ -980,19 +955,14 @@ void __init time_init(void)
> /* Save the current timebase to pretty up CONFIG_PRINTK_TIME */
> boot_tb = get_tb_or_rtc();
>
> - tm = get_boot_time();
> -
> write_seqlock_irqsave(&xtime_lock, flags);
Is there any sense of grabbing xtime_lock in time_init() when you've
implemented read_persistent_clock()?
>
> /* If platform provided a timezone (pmac), we correct the time */
> if (timezone_offset) {
> sys_tz.tz_minuteswest = -timezone_offset / 60;
> sys_tz.tz_dsttime = 0;
> - tm -= timezone_offset;
> }
>
> - xtime.tv_sec = tm;
> - xtime.tv_nsec = 0;
Huh? The 'xtime' should now be set by the *generic* timekeeping code using
read_persistent_clock() -- or else what's the point to implement the function? :-/
> @@ -1010,9 +980,6 @@ void __init time_init(void)
>
> time_freq = 0;
>
> - last_rtc_update = xtime.tv_sec;
> - set_normalized_timespec(&wall_to_monotonic,
> - -xtime.tv_sec, -xtime.tv_nsec);
> write_sequnlock_irqrestore(&xtime_lock, flags);
That 'xtime_lock' grabbing should be gone with this patch, and is not. NAK.
WBR, Sergei
^ permalink raw reply
* Re: linux-2.6.git: cannot build PS3 image
From: Scott Wood @ 2007-10-17 15:35 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <Pine.LNX.4.62.0710171523120.19421@pademelon.sonytel.be>
Geert Uytterhoeven wrote:
>> diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
>> index 39b27e5..795f988 100755
>> --- a/arch/powerpc/boot/wrapper
>> +++ b/arch/powerpc/boot/wrapper
>> @@ -232,7 +232,7 @@ base=0x`${CROSS}nm "$ofile" | grep ' _start$' | cut -d' ' -f1`
>> entry=`${CROSS}objdump -f "$ofile" | grep '^start address ' | cut -d' ' -f3`
>>
>> if [ -n "$binary" ]; then
>> - mv "$ofile" "$ofile".elf
>> + cp "$ofile" "$ofile".elf
>> ${CROSS}objcopy -O binary "$ofile".elf "$ofile".bin
>> fi
>
> No comments?
That'd work in this case, though it'd probably be better to make the
$ofile be the end result that will boot on the ps3, and leave a suffix
on the intermediate files.
I wonder if we may be better off just making zImage a phony target and
removing the link altogether....
-Scott
^ permalink raw reply
* Re: PPC440EPx GPIO control help
From: David Hawkins @ 2007-10-17 16:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4715A9D9.6090308@mock.com>
Hi Dell,
If you do decide to look at kernel drivers, Jeff has sent you
code, and I also have a tutorial with example code you are
welcome to look at:
http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-723-Hawkins.pdf
http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
Feel free to ask questions. I recall writing some test driver
code for the 440EP Yosemite board too. I'm just not sure where
I put it ... :)
Cheers,
Dave
^ permalink raw reply
* RE: Merge dtc
From: Stephen Neuendorffer @ 2007-10-17 16:22 UTC (permalink / raw)
To: Grant Likely, Paul Mackerras, Josh Boyer, linuxppc-dev
In-Reply-To: <fa686aa40710170615q3b69b13ch7a0038e9c6270729@mail.gmail.com>
=20
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.or
> g=20
> [mailto:linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@o
zlabs.org] On Behalf Of Grant Likely
> Sent: Wednesday, October 17, 2007 6:15 AM
> To: Grant Likely; Paul Mackerras; Josh Boyer; linuxppc-dev@ozlabs.org
> Subject: Re: Merge dtc
>=20
> On 10/16/07, David Gibson <dwg@au1.ibm.com> wrote:
> > On Tue, Oct 16, 2007 at 07:17:01AM -0600, Grant Likely wrote:
> > > On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > > > This very large patch incorporates a copy of dtc into the kernel
> > > > source, in arch/powerpc/boot/dtc-src. This means that dtc is no
> > > > longer an external dependency to build kernels with=20
> configurations
> > > > which need a dtb file.
> > >
> > > Powerpc is probably not going to be the only user of dtc.=20
> Microblaze
> > > will be using it too. Can it be put somewhere more common?
> >
> > Well, I guess we can move it to scripts/ when microblaze=20
> starts using
> > it.
> >
> > Also, tell me more about this microblaze, I'm certainly=20
> interested in
> > new users of dtc...
>=20
> It's a 'soft processor'. Implemented in the fabric of an FPGA. It's
> a ucLinux target. Xilinx Virtex and Xilinx MicroBlaze targets share a
> lot of common devices.
>=20
> Cheers,
> g.
Basically, this partially works today. Most of the device information
can come out of a flat device tree, with most of the kernel code copied
straight from arch/powerpc. I'm still trying to sort out how some of
the architecture specific stuff can be extracted in a smart way. For
instance, the microblaze has configurable cache sizes, and may or may
not be available. Currently, this is #defined in the kernel, but I'd
like to get to the point where the same information is pulled out of a
device tree. My main quandry at the moment is that I'm not wild about
self-modifying code and I'm not sure if the extra overhead of
implementing it with conditionals is significant.
In any event, my plan is to get this into a reasonable state and then
post it here for review. The main reason why we went with flat device
trees for this was to get as much symmettry as possible between the soft
microblaze and the embedded ppc405 hard core in some FPGAs.
Steve
^ permalink raw reply
* Re: mpc 860 boot linux2.6.23 problem
From: Dan Malek @ 2007-10-17 16:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <47162AE7.80305@freescale.com>
On Oct 17, 2007, at 11:31 AM, Scott Wood wrote:
> I just pulled Wolfgang's latest u-boot tree, and I don't see any
> fdt or ft_ calls in cpu/mpc8xx, nor in any 8xx board that I recognize.
The STx XTc 885 is supported and was used for
a majority of the FT development in u-boot. I
just built it a few months ago, it worked fine, so
if it isn't working today the changes should be
minimal to bring it up to date.
Thanks.
-- Dan
^ permalink raw reply
* [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
From: Grant Likely @ 2007-10-17 16:36 UTC (permalink / raw)
To: Sven Luther, domen.puncer, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Only the MPC5200 needs this bug fix. MPC5200B is okay.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Sven, Domen;
Can you please test this patch?
Thanks,
g.
arch/powerpc/sysdev/bestcomm/bestcomm.c | 9 ++++++---
include/asm-powerpc/mpc52xx.h | 5 +++++
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/bestcomm/bestcomm.c b/arch/powerpc/sysdev/bestcomm/bestcomm.c
index 48492a8..740ad73 100644
--- a/arch/powerpc/sysdev/bestcomm/bestcomm.c
+++ b/arch/powerpc/sysdev/bestcomm/bestcomm.c
@@ -269,6 +269,7 @@ bcom_engine_init(void)
int task;
phys_addr_t tdt_pa, ctx_pa, var_pa, fdt_pa;
unsigned int tdt_size, ctx_size, var_size, fdt_size;
+ u16 regval;
/* Allocate & clear SRAM zones for FDT, TDTs, contexts and vars/incs */
tdt_size = BCOM_MAX_TASKS * sizeof(struct bcom_tdt);
@@ -319,9 +320,11 @@ bcom_engine_init(void)
/* Init 'always' initiator */
out_8(&bcom_eng->regs->ipr[BCOM_INITIATOR_ALWAYS], BCOM_IPR_ALWAYS);
- /* Disable COMM Bus Prefetch, apparently it's not reliable yet */
- /* FIXME: This should be done on 5200 and not 5200B ... */
- out_be16(&bcom_eng->regs->PtdCntrl, in_be16(&bcom_eng->regs->PtdCntrl) | 1);
+ /* Disable COMM Bus Prefetch on the original 5200; it's broken */
+ if ((mfspr(SPRN_SVR) & MPC5200_SVR_MASK) == MPC5200_SVR) {
+ regval = in_be16(&bcom_eng->regs->PtdCntrl);
+ out_be16(&bcom_eng->regs->PtdCntrl, regval | 1);
+ }
/* Init lock */
spin_lock_init(&bcom_eng->lock);
diff --git a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
index 24751df..25b2e55 100644
--- a/include/asm-powerpc/mpc52xx.h
+++ b/include/asm-powerpc/mpc52xx.h
@@ -18,6 +18,11 @@
#include <asm/prom.h>
#endif /* __ASSEMBLY__ */
+/* Variants of the 5200(B) */
+#define MPC5200_SVR 0x80110010
+#define MPC5200_SVR_MASK 0xfffffff0
+#define MPC5200B_SVR 0x80110020
+#define MPC5200B_SVR_MASK 0xfffffff0
/* ======================================================================== */
/* Structures mapping of some unit register set */
^ permalink raw reply related
* Re: [PATCH] bestcomm: Restrict disabling of bus prefetch to original mpc5200 silicon.
From: Sven Luther @ 2007-10-17 16:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, domen.puncer
In-Reply-To: <20071017163555.24992.40095.stgit@trillian.cg.shawcable.net>
On Wed, Oct 17, 2007 at 10:36:27AM -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> Only the MPC5200 needs this bug fix. MPC5200B is okay.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Sven, Domen;
>
> Can you please test this patch?
I will test it tomorrow. For some obscure reason, my efika refuses to
get the console=ttyPSC0 appended, so i have a hard time testing it.
Friendly,
Sven Luther
^ permalink raw reply
* [PATCH] [POWERPC] lite5200: Add bestcomm to defconfigs
From: Grant Likely @ 2007-10-17 16:55 UTC (permalink / raw)
To: linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
Add bestcomm to lite5200 defconfig
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/configs/lite5200_defconfig | 56 ++++++++++++++++++++++++-------
1 files changed, 43 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/configs/lite5200_defconfig b/arch/powerpc/configs/lite5200_defconfig
index d42e226..f231f44 100644
--- a/arch/powerpc/configs/lite5200_defconfig
+++ b/arch/powerpc/configs/lite5200_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.23-rc4
-# Tue Aug 28 21:24:38 2007
+# Linux kernel version: 2.6.23
+# Wed Oct 17 10:25:12 2007
#
# CONFIG_PPC64 is not set
@@ -21,8 +21,13 @@ CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
# CONFIG_SMP is not set
CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
@@ -65,6 +70,8 @@ CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
+CONFIG_FAIR_GROUP_SCHED=y
+CONFIG_FAIR_USER_SCHED=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
@@ -83,7 +90,6 @@ CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
# CONFIG_EPOLL is not set
CONFIG_SIGNALFD=y
-CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
@@ -122,7 +128,6 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
# Platform support
#
CONFIG_PPC_MULTIPLATFORM=y
-# CONFIG_EMBEDDED6xx is not set
# CONFIG_PPC_82xx is not set
# CONFIG_PPC_83xx is not set
# CONFIG_PPC_86xx is not set
@@ -137,6 +142,7 @@ CONFIG_PPC_LITE5200=y
# CONFIG_PPC_CELL is not set
# CONFIG_PPC_CELL_NATIVE is not set
# CONFIG_PQ2ADS is not set
+# CONFIG_EMBEDDED6xx is not set
# CONFIG_MPIC is not set
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
@@ -150,11 +156,19 @@ CONFIG_PPC_LITE5200=y
# CONFIG_TAU is not set
# CONFIG_CPM2 is not set
# CONFIG_FSL_ULI1575 is not set
+CONFIG_PPC_BESTCOMM=y
+CONFIG_PPC_BESTCOMM_ATA=y
+CONFIG_PPC_BESTCOMM_FEC=y
+CONFIG_PPC_BESTCOMM_GEN_BD=y
#
# Kernel options
#
# CONFIG_HIGHMEM is not set
+# CONFIG_TICK_ONESHOT is not set
+# CONFIG_NO_HZ is not set
+# CONFIG_HIGH_RES_TIMERS is not set
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
@@ -187,10 +201,13 @@ CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP=y
+CONFIG_SUSPEND_UP_POSSIBLE=y
CONFIG_SUSPEND=y
+CONFIG_HIBERNATION_UP_POSSIBLE=y
# CONFIG_HIBERNATION is not set
CONFIG_SECCOMP=y
-# CONFIG_WANT_DEVICE_TREE is not set
+CONFIG_WANT_DEVICE_TREE=y
+CONFIG_DEVICE_TREE=""
CONFIG_ISA_DMA_API=y
#
@@ -225,7 +242,7 @@ CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
-CONFIG_TASK_SIZE=0x80000000
+CONFIG_TASK_SIZE=0xc0000000
CONFIG_BOOT_LOAD=0x00800000
#
@@ -265,6 +282,7 @@ CONFIG_SYN_COOKIES=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
+# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
@@ -322,6 +340,7 @@ CONFIG_DEFAULT_TCP_CONG="cubic"
#
# Generic Driver Options
#
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
@@ -392,6 +411,7 @@ CONFIG_SCSI_WAIT_SCAN=m
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
+# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
@@ -403,6 +423,7 @@ CONFIG_SCSI_LOWLEVEL=y
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
+# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
@@ -471,6 +492,7 @@ CONFIG_PATA_MPC52xx=y
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
+# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
@@ -485,14 +507,7 @@ CONFIG_PATA_MPC52xx=y
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_MD is not set
-
-#
-# Fusion MPT device support
-#
# CONFIG_FUSION is not set
-# CONFIG_FUSION_SPI is not set
-# CONFIG_FUSION_FC is not set
-# CONFIG_FUSION_SAS is not set
#
# IEEE 1394 (FireWire) support
@@ -508,12 +523,15 @@ CONFIG_NETDEVICES=y
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
+# CONFIG_VETH is not set
+# CONFIG_IP1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_NET_ETHERNET is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
+# CONFIG_E1000E is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
@@ -521,6 +539,7 @@ CONFIG_NETDEV_1000=y
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
+# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
@@ -530,11 +549,14 @@ CONFIG_NETDEV_1000=y
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
+# CONFIG_IXGBE is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
+# CONFIG_NIU is not set
# CONFIG_MLX4_CORE is not set
+# CONFIG_TEHUTI is not set
# CONFIG_TR is not set
#
@@ -614,6 +636,12 @@ CONFIG_DEVPORT=y
# CONFIG_HWMON is not set
#
+# Sonics Silicon Backplane
+#
+CONFIG_SSB_POSSIBLE=y
+# CONFIG_SSB is not set
+
+#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
@@ -845,3 +873,5 @@ CONFIG_FORCED_INLINING=y
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_CRYPTO is not set
+CONFIG_PPC_CLOCK=y
+CONFIG_PPC_LIB_RHEAP=y
^ permalink raw reply related
* Re: mpc 860 boot linux2.6.23 problem
From: Scott Wood @ 2007-10-17 17:26 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <5E6FFDE1-D706-4460-8621-0BFA38FDC502@embeddedalley.com>
Dan Malek wrote:
>
> On Oct 17, 2007, at 11:31 AM, Scott Wood wrote:
>
>> I just pulled Wolfgang's latest u-boot tree, and I don't see any fdt
>> or ft_ calls in cpu/mpc8xx, nor in any 8xx board that I recognize.
>
> The STx XTc 885 is supported and was used for
> a majority of the FT development in u-boot. I
> just built it a few months ago, it worked fine, so
> if it isn't working today the changes should be
> minimal to bring it up to date.
OK, that wasn't a board I recognized. :-P
Still, most 8xx boards are not yet converted AFAICT. Not that it'd be
hard to do so, but it might be a bit misleading to say "upgrade u-boot
and get device tree support". :-)
-Scott
^ permalink raw reply
* Re: MPC85xx and linux IDE driver
From: Michael Brian Willis @ 2007-10-17 17:47 UTC (permalink / raw)
To: Ben Warren; +Cc: linuxppc-embedded
In-Reply-To: <470FCF8A.1000504@qstreams.com>
On Fri, 2007-10-12 at 15:48 -0400, Ben Warren wrote:
> Here's what I use:
>
> http://marc.info/?l=linux-kernel&m=113877891224982&w=2
Thanks for the response Ben.
I have put the driver you mentioned in my linux source and added the
necessary information in the Kconfig file and the Makefile. So, I am now
able to build the driver when I make my kernel image. However, I can't
figure out what else needs to be done in order to actually use the
driver for my compact flash device. Do I need to specify anything at the
kernel command line, or do I need to modify any other config files?
(Below is the ide portion of my linux .config file)
Thank you for your help so far, anymore help/direction is greatly
appreciated.
Regards,
Michael Willis
Applied Research Labs - University of Texas
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_IDE_MAX_HWIFS=4
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_IDEDISK is not set
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_IDE_TASK_IOCTL=y
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_IDEPCI is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_CFIDE=y
# CONFIG_BLK_DEV_IDEDMA is not set
# CONFIG_BLK_DEV_HD is not set
^ permalink raw reply
* Re: Linux booting problem on Xilinx ppc
From: aauer1 @ 2007-10-17 18:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40710170754p54aa405au9b046f7039ecb9ac@mail.gmail.com>
Grant Likely-2 wrote:
>
> On 10/17/07, aauer1 <aauer1@gmx.at> wrote:
>> Now, I know that the kernel boots but I don't get an output with my
>> Xilinx
>> UartLite module. Are there some kernel modules which must be activated??
>> Btw. I have used the Linux-2.6-virtex kernel from
>> http://git.secretlab.ca/git/ and another Kernel (2.6.23 from kernel.org)
>> -
>> both with the same result.
>
> Post the output of __log_buf here please.
>
>
Here is my dump of the __log_buf:
======================
<5>[ 0.000000] Linux version 2.6.23-rc2
(aauer@servitus.student.iaik.tugraz.at) (gcc version 4.0.0 (DENX ELDK 4.1
4.0
.0)) #8 Wed Oct 17 20:05:28 CEST 2007
<6>[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
<7>[ 0.000000] Entering add_active_range(0, 0, 16384) 0 entries of 256
used
<4>[ 0.000000] Zone PFN ranges:
<4>[ 0.000000] DMA 0 -> 16384
<4>[ 0.000000] Normal 16384 -> 16384
<4>[ 0.000000] Movable zone start PFN for each node
<4>[ 0.000000] early_node_map[1] active PFN ranges
<4>[ 0.000000] 0: 0 -> 16384
<7>[ 0.000000] On node 0 totalpages: 16384
<7>[ 0.000000] DMA zone: 128 pages used for memmap
<7>[ 0.000000] DMA zone: 0 pages reserved
<7>[ 0.000000] DMA zone: 16256 pages, LIFO batch:3
<7>[ 0.000000] Normal zone: 0 pages used for memmap
<7>[ 0.000000] Movable zone: 0 pages used for memmap
<4>[ 0.000000] Built 1 zonelists in Zone order. Total pages: 16256
<5>[ 0.000000] Kernel command line: console=ttUL0 root=/dev/xsysace2 rw
<6>[ 0.000000] Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
<4>[ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
<4>[ 0.000325] Console: colour dummy device 80x25
<6>[ 0.001380] Dentry cache hash table entries: 8192 (order: 3, 32768
bytes)
<6>[ 0.002924] Inode-cache hash table entries: 4096 (order: 2, 16384
bytes)
<4>[ 0.029750] Memory: 63256k available (1172k kernel code, 384k data,
84k init, 0k highmem)
<7>[ 0.030975] Calibrating delay loop... 299.00 BogoMIPS (lpj=598016)
<4>[ 0.120718] Mount-cache hash table entries: 512
<6>[ 0.171779] io scheduler noop registered
<6>[ 0.171857] io scheduler anticipatory registered (default)
<6>[ 0.171884] io scheduler deadline registered
<6>[ 0.172262] io scheduler cfq registered
<6>[ 0.268268] uartlite.0: ttyUL0 at MMIO 0x40600000 (irq = 2) is a
uartlite
<4>[ 0.281400] RAMDISK driver initialized: 8 RAM disks of 8192K size 1024
blocksize
<6>[ 0.282765] mice: PS/2 mouse device common for all mice
<4>[ 0.286181] VFS: Cannot open root device "xsysace2" or
unknown-block(0,0)
<4>[ 0.286252] Please append a correct "root=" boot option; here are the
available partitions:
<0>[ 0.286323] Kernel panic - not syncing: VFS: Unable to mount root fs
on unknown-block(0,0)
<0>[ 0.286374] Rebooting in 180 seconds..
Thanks,
Andreas
--
View this message in context: http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13259685
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ 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