-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> * Ramdisk is also executing fine, just that prints are not coming out of
> serial. I can see the execution of various user programs with a printk
> in sys_execve() routine. Ramdisk has all the required files like
> /dev/console, /dev/ttyS0, etc.
> *
Wolfgang Denk <[EMAIL PROTECTED]> writes:
> In message <[EMAIL PROTECTED]> you wrote:
>> On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote:
>> > Michael Buesch <[EMAIL PROTECTED]> writes:
>> >
>> > > +set +e
>> > > mkimage -A ppc -O linux -T kernel -C gzip -a -e 00
In message <[EMAIL PROTECTED]> you wrote:
> On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote:
> > Michael Buesch <[EMAIL PROTECTED]> writes:
> >
> > > +set +e
> > > mkimage -A ppc -O linux -T kernel -C gzip -a -e \
> > > $uboot_version -d "$vmz" "$ofile"
> >
Anton Vorontsov wrote:
> I wonder what are the symptoms if microcode is at fault? According
> to errata description, hang isn't something I should get on the
> transmit attempt.
Well, if the microcode fails, you'll never know. I tried to explain the
need for a unified microcode validation mecha
On Thu, Dec 27, 2007 at 09:38:23AM -0600, Timur Tabi wrote:
> Anton Vorontsov wrote:
>
> >I wonder what are the symptoms if microcode is at fault? According
> >to errata description, hang isn't something I should get on the
> >transmit attempt.
>
> Well, if the microcode fails, you'll never know.
On 12/19/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Another rework of the i2c for powerpc device tree patch. This version
> implements standard alias naming only on the powerpc platform and only for
> the device tree names. The old naming mechanism of
> i2c_client.name,driver_name is left in pla
On Thursday 27 December 2007 11:14:04 Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote:
> > > Michael Buesch <[EMAIL PROTECTED]> writes:
> > >
> > > > +set +e
> > > > mkimage -A ppc -O linux -T kernel -C gzip
If this should go in linuxppc-embedded please let me know. It seems that
the board supports are getting posted here.
PIKA has an embedded PPC440EP board based on the AMCC Yosemite board. I
got the Linux 2.6.19.2 kernel working by basically copying the Yosemite
configuration. Now I am trying to
Turns out the Tundra TSI109 has various "problems" trying
to nap -- its not a 7448 issue...
We're working with tundra to get a workaround (in software, they
won't respin the part). It seems DMA while napping is an issue, we
have to turn off the tsi109 ethernet queues before entering nap mode...
On Thu, 27 Dec 2007 17:20:09 -0500
Sean MacLennan <[EMAIL PROTECTED]> wrote:
> If this should go in linuxppc-embedded please let me know. It seems that
> the board supports are getting posted here.
>
> PIKA has an embedded PPC440EP board based on the AMCC Yosemite board. I
> got the Linux 2.6.1
Josh Boyer wrote:
Can you post the full boot messages (send privately if you'd like). One
thing to make sure of is if all the properties in the DTS file that say
"Filled in by zImage wrapper" are actually getting filled in.
I have attached a boot log. The ethernet and IP addresses have been
m
Thank you Jon and Nicholas.
I already have "console=ttyS0" in the kernel command line. That is not
helping me.
I looked at the major/minor numbers with a good working system and it
looks correct for the nodes created in ramdisk.
What is the kernel routine that is first called when there is, for
smp_call_function_map should be static, and for consistency prepend it
with __ like other local helper functions in the same file.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 338950a..cefeee8 100644
--- a/arch/powerpc/
smp_send_stop() will send an IPI to all other cpus to shut them down.
However, for the case of xmon-based reboots (as well as potentially some
panics), the other cpus are (or might be) spinning with interrupts off,
and won't take the IPI.
Current code will drop us into the debugger when the IPI fa
On 12/27/07, Siva Prasad <[EMAIL PROTECTED]> wrote:
> Thank you Jon and Nicholas.
>
> I already have "console=ttyS0" in the kernel command line. That is not
> helping me.
Do you have
CONFIG_EARLY_PRINTK=y
in .config?
>
> I looked at the major/minor numbers with a good working system and it
> loo
Jon,
Yes!... I have CONFIG_EARLY_PRINTK=y, and I could see early prints
during booting the kernel. Afterwards, printk's also work as expected.
Only printf's from user space has problem.
- Siva
-Original Message-
From: Jon Smirl [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 27, 200
On Thu, 2007-12-27 at 17:37 -0500, Leisner, Martin wrote:
> Turns out the Tundra TSI109 has various "problems" trying
> to nap -- its not a 7448 issue...
>
> We're working with tundra to get a workaround (in software, they
> won't respin the part). It seems DMA while napping is an issue, we
> h
On Thu, 27 Dec 2007 11:15:37 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> FUJITA Tomonori wrote:
> > On Thu, 27 Dec 2007 10:08:25 +0530
> > Balbir Singh <[EMAIL PROTECTED]> wrote:
> >
> >> FUJITA Tomonori wrote:
> >>> On Mon, 24 Dec 2007 10:18:50 +0530
> >>> Balbir Singh <[EMAIL PROTECTED]> wr
2.6.10 kernel hangs on my board with PPC64 processors. The log is below. There
must be a fix for this somewhere because it boots just fine on 2.6.14 kernel.
Could someone please point me to the fix for this?
time_init: decrementer frequency = 112.50 MHz
time_init: processor frequency = 180
Josh Boyer wrote:
> As for the USB interrupt, you might
> be missing the device-tree enabled USB driver in your config. The
> interrupt numbers will differ based on various things, so I wouldn't
> worry about that.
>
Just so I am not all bad news, I got the usb going. I borrowed the usb
config
And one more thought, could uClibc be causing problems with the new
kernel? It just seems strange that kernel "stuff" seems to work (e.g. no
problems mounting a usbkey) yet a simple setjmp in a user mode app reeks
havoc.
We are going to be moving away from uClibc in the short term (I am the
on
FUJITA Tomonori wrote:
[snip]
> Thanks,
>
> Can you try this?
>
>
> diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> index e7d8544..495575a 100644
> --- a/lib/iommu-helper.c
> +++ b/lib/iommu-helper.c
> @@ -8,15 +8,20 @@
> static unsigned long find_next_zero_area(unsigned long *map,
>
22 matches
Mail list logo
