* Re: Problems with arch/powerpc
From: Sean MacLennan @ 2007-12-28 6:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <477493D9.7070700@pikatech.com>
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
only one left using it). So if this could be an issue I might have to
bite the bullet and switch now.
Cheers,
Sean
^ permalink raw reply
* Re: Problems with arch/powerpc
From: Sean MacLennan @ 2007-12-28 6:12 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071227194753.56bc92f8@vader.jdub.homelinux.org>
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 from bamboo.dts. I then had to patch the top level usb Kconfig.
It basically relies on PCI, and the taco has no PCI, so I added the
taco as a special case.
Cheers,
Sean
^ permalink raw reply
* Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
From: FUJITA Tomonori @ 2007-12-28 5:30 UTC (permalink / raw)
To: balbir; +Cc: fujita.tomonori, linuxppc-dev, akpm, linux-kernel, linux-scsi
In-Reply-To: <47733C01.1080002@linux.vnet.ibm.com>
On Thu, 27 Dec 2007 11:15:37 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> FUJITA Tomonori wrote:
> > On Thu, 27 Dec 2007 10:08:25 +0530
> > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> >
> >> FUJITA Tomonori wrote:
> >>> On Mon, 24 Dec 2007 10:18:50 +0530
> >>> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> >>>
> >> [snip]
> >>
> >>> I might break the IOMMU code. Can you reproduce it easily? If so,
> >>> reverting my IOMMU patches (I've attached a patch to revert them) fix
> >>> the problem?
> >> [snip]
> >>
> >>
> >> Yes, this patch fixes the problem for me.
> >
> > Thanks, so you can reproduce it easily, right?
> >
>
> Yes, quite easily
>
> > The problem is that I don't want to revert these changes. I'll see
> > how these changes cause the problem shortly.
>
> I'll try and find some bandwidth to review/test the patches and help you
> figure out the right solution.
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,
unsigned long size,
unsigned long start,
- unsigned int nr)
+ unsigned int nr,
+ unsigned long align_mask)
{
unsigned long index, end, i;
again:
index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) & ~align_mask;
+
end = index + nr;
- if (end > size)
+ if (end >= size)
return -1;
- for (i = index + 1; i < end; i++) {
+ for (i = index; i < end; i++) {
if (test_bit(i, map)) {
start = i+1;
goto again;
@@ -50,9 +55,8 @@ unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
{
unsigned long index;
again:
- index = find_next_zero_area(map, size, start, nr);
+ index = find_next_zero_area(map, size, start, nr, align_mask);
if (index != -1) {
- index = (index + align_mask) & ~align_mask;
if (is_span_boundary(index, nr, shift, boundary_size)) {
/* we could do more effectively */
start = index + 1;
^ permalink raw reply related
* Re: update: RE: nap/dfs on 7448
From: Benjamin Herrenschmidt @ 2007-12-28 5:19 UTC (permalink / raw)
To: Leisner, Martin; +Cc: linuxppc-dev
In-Reply-To: <556445368AFA1C438794ABDA8901891C07C113CC@USA0300MS03.na.xerox.net>
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
> have to turn off the tsi109 ethernet queues before entering nap mode...
>
> If anyone needs this work, let me know (it will be covered under GPL).
This looks like yet another f*cked up bridge ... I wonder if we'll ever
get a half decent working northbridge for those processors...
Unfortunately, it looks like the market for those is limited to junk
from vendor A and shit from vendor B...
Is the problem limited to the TSI internal ethernet or it happens with
any DMA ?
Looks to me like turning off DMA in NAP mode basically makes NAP mode
unuseable, perdiod. You can't start loosing packets because your
processor is idle. So no power saving, and let's eat the watts since
they won't respin the part. Great !
Ben.
^ permalink raw reply
* How to do IO mapped Implimentation ???
From: Misbah khan @ 2007-12-28 5:12 UTC (permalink / raw)
To: linuxppc-embedded
Hi all...
I am writing a driver in which device port is mapped to CPLD and 8 bit data
bus is directly connected from processor to CPLD. Read write on CPLD memory
mapped (buffer/register) is required to control the device. This is now IO
mapped to processor.
I need to know whether i am right if i impliment like this :-
addr=ioremap(base_addr); // Remap to Mem mapped address
outb(addr) and inb(addr);
Please suggest me if i am wrong or there could be better solution to this .
-----Misbah <><
--
View this message in context: http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14522349.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: Device node - How does kernel know about it
From: Siva Prasad @ 2007-12-28 4:55 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, Nicholas Mc Guire, linuxppc-embedded
In-Reply-To: <9e4733910712272015m30ffc13cu6022ee9d29f9bddc@mail.gmail.com>
Jon,
Yes!... I have CONFIG_EARLY_PRINTK=3Dy, 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:jonsmirl@gmail.com]=20
Sent: Thursday, December 27, 2007 8:16 PM
To: Siva Prasad
Cc: Nicholas Mc Guire; linuxppc-dev@ozlabs.org;
linuxppc-embedded@ozlabs.org
Subject: Re: Device node - How does kernel know about it
On 12/27/07, Siva Prasad <sprasad@bivio.net> wrote:
> Thank you Jon and Nicholas.
>
> I already have "console=3DttyS0" in the kernel command line. That is =
not
> helping me.
Do you have
CONFIG_EARLY_PRINTK=3Dy
in .config?
>
> 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
> example a read() function call from user program?
> I would like to start debugging from there and see if any thing at all
> happens when there is a call. Appreciate your help with this question.
>
> Thanks
> Siva
>
>
> -----Original Message-----
> From: Nicholas Mc Guire [mailto:der.herr@hofr.at]
> Sent: Friday, December 28, 2007 12:39 AM
> To: Siva Prasad
> Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: Re: Device node - How does kernel know about it
>
> -----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.
> > * Looking further into tty driver, I noticed that call to
tty_write()
> or
> > do_tty_write() is not happening at all. So, somewhere the interface
> > between kernel and user program is lost.
> > * Just to check it out, I tried to write a small kernel module and a
> > test program.
> > - Attached memtest.c module (not really testing memory there. :-))
> > - Attached testmemtest.c user program, that just open's it and
reads
> > the information
> > - Created a device node using "mknod /dev/memtest c 168 0"
> > - When I do "insmod memtest.ko" inside the ramdisk bootup scripts,
I
> > could see all the printk's on the console
> > - When I execute "testmemtest" next in the same script, it does not
> > display the printk inside of memtest.c module. This only indicates
> that
> > read call did not really go to the kernel side.
> > - Just to check my program's validity, I checked on a similar
machine
> > and all the code works fine.
> > - "uname -r" also matches with what I built. So, chances of exiting
> > from open call because of mismatch is remote. Since userland cannot
> > print, I have no idea what exactly is happening there.
> >
> The kernel will simply look at the major:minor numbers - so maybe you
> simply have a wrong major/minor for /dev/ttyS0 ? in that case you will
> see nothing but other than that most things will go on working.
>
> hofrat
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK
> hrfpn2RMn5l23ZqCOXV5rd8=3D
> =3DGfsF
> -----END PGP SIGNATURE-----
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Device node - How does kernel know about it
From: Jon Smirl @ 2007-12-28 4:15 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev, Nicholas Mc Guire, linuxppc-embedded
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D7012AFA2D@corpexc01.corp.networkrobots.com>
On 12/27/07, Siva Prasad <sprasad@bivio.net> 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
> looks correct for the nodes created in ramdisk.
>
> What is the kernel routine that is first called when there is, for
> example a read() function call from user program?
> I would like to start debugging from there and see if any thing at all
> happens when there is a call. Appreciate your help with this question.
>
> Thanks
> Siva
>
>
> -----Original Message-----
> From: Nicholas Mc Guire [mailto:der.herr@hofr.at]
> Sent: Friday, December 28, 2007 12:39 AM
> To: Siva Prasad
> Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: Re: Device node - How does kernel know about it
>
> -----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.
> > * Looking further into tty driver, I noticed that call to tty_write()
> or
> > do_tty_write() is not happening at all. So, somewhere the interface
> > between kernel and user program is lost.
> > * Just to check it out, I tried to write a small kernel module and a
> > test program.
> > - Attached memtest.c module (not really testing memory there. :-))
> > - Attached testmemtest.c user program, that just open's it and reads
> > the information
> > - Created a device node using "mknod /dev/memtest c 168 0"
> > - When I do "insmod memtest.ko" inside the ramdisk bootup scripts, I
> > could see all the printk's on the console
> > - When I execute "testmemtest" next in the same script, it does not
> > display the printk inside of memtest.c module. This only indicates
> that
> > read call did not really go to the kernel side.
> > - Just to check my program's validity, I checked on a similar machine
> > and all the code works fine.
> > - "uname -r" also matches with what I built. So, chances of exiting
> > from open call because of mismatch is remote. Since userland cannot
> > print, I have no idea what exactly is happening there.
> >
> The kernel will simply look at the major:minor numbers - so maybe you
> simply have a wrong major/minor for /dev/ttyS0 ? in that case you will
> see nothing but other than that most things will go on working.
>
> hofrat
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK
> hrfpn2RMn5l23ZqCOXV5rd8=
> =GfsF
> -----END PGP SIGNATURE-----
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH 2/2] [POWERPC] Make smp_send_stop() handle panic and xmon reboot
From: Olof Johansson @ 2007-12-28 4:11 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071228040836.GA23635@lixom.net>
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 fails, which
means we're in an infinite loop that we can't get out of without an
external reset of some sort.
Instead, make the smp_send_stop() IPI call path just print the warning
about being unable to send IPIs, but make it return so the rest of the
shutdown sequence can continue. It's not perfect, but the lesser of
two evils.
Also move the call_lock handling outside of smp_call_function_map so we
can avoid deadlocks in smp_send_stop().
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index cefeee8..8730687 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -76,6 +76,8 @@ void smp_call_function_interrupt(void);
int smt_enabled_at_boot = 1;
+static int ipi_fail_ok;
+
static void (*crash_ipi_function_ptr)(struct pt_regs *) = NULL;
#ifdef CONFIG_PPC64
@@ -204,8 +206,6 @@ static int __smp_call_function_map(void (*func) (void *info), void *info,
if (wait)
atomic_set(&data.finished, 0);
- spin_lock(&call_lock);
-
/* remove 'self' from the map */
if (cpu_isset(smp_processor_id(), map))
cpu_clear(smp_processor_id(), map);
@@ -232,7 +232,8 @@ static int __smp_call_function_map(void (*func) (void *info), void *info,
printk("smp_call_function on cpu %d: other cpus not "
"responding (%d)\n", smp_processor_id(),
atomic_read(&data.started));
- debugger(NULL);
+ if (!ipi_fail_ok)
+ debugger(NULL);
goto out;
}
}
@@ -259,15 +260,18 @@ static int __smp_call_function_map(void (*func) (void *info), void *info,
out:
call_data = NULL;
HMT_medium();
- spin_unlock(&call_lock);
return ret;
}
static int __smp_call_function(void (*func)(void *info), void *info,
int nonatomic, int wait)
{
- return __smp_call_function_map(func, info, nonatomic, wait,
+ int ret;
+ spin_lock(&call_lock);
+ ret =__smp_call_function_map(func, info, nonatomic, wait,
cpu_online_map);
+ spin_unlock(&call_lock);
+ return ret;
}
int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
@@ -293,9 +297,11 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
return -EINVAL;
cpu_set(cpu, map);
- if (cpu != get_cpu())
+ if (cpu != get_cpu()) {
+ spin_lock(&call_lock);
ret = __smp_call_function_map(func, info, nonatomic, wait, map);
- else {
+ spin_unlock(&call_lock);
+ } else {
local_irq_disable();
func(info);
local_irq_enable();
@@ -307,7 +313,22 @@ EXPORT_SYMBOL(smp_call_function_single);
void smp_send_stop(void)
{
- __smp_call_function(stop_this_cpu, NULL, 1, 0);
+ int nolock;
+
+ /* It's OK to fail sending the IPI, since the alternative is to
+ * be stuck forever waiting on the other CPU to take the interrupt.
+ *
+ * It's better to at least continue and go through reboot, since this
+ * function is usually called at panic or reboot time in the first
+ * place.
+ */
+ ipi_fail_ok = 1;
+
+ /* Don't deadlock in case we got called through panic */
+ nolock = !spin_trylock(&call_lock);
+ __smp_call_function_map(stop_this_cpu, NULL, 1, 0, cpu_online_map);
+ if (!nolock)
+ spin_unlock(&call_lock);
}
void smp_call_function_interrupt(void)
^ permalink raw reply related
* [PATCH 1/2] [POWERPC] smp_call_function_map should be static
From: Olof Johansson @ 2007-12-28 4:08 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
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 <olof@lixom.net>
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 338950a..cefeee8 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -181,12 +181,13 @@ static struct call_data_struct {
* <wait> If true, wait (atomically) until function has completed on other CPUs.
* [RETURNS] 0 on success, else a negative status code. Does not return until
* remote CPUs are nearly ready to execute <<func>> or are or have executed.
+ * <map> is a cpu map of the cpus to send IPI to.
*
* You must not call this function with disabled interrupts or from a
* hardware interrupt handler or from a bottom half handler.
*/
-int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,
- int wait, cpumask_t map)
+static int __smp_call_function_map(void (*func) (void *info), void *info,
+ int nonatomic, int wait, cpumask_t map)
{
struct call_data_struct data;
int ret = -1, num_cpus;
@@ -265,7 +266,8 @@ int smp_call_function_map(void (*func) (void *info), void *info, int nonatomic,
static int __smp_call_function(void (*func)(void *info), void *info,
int nonatomic, int wait)
{
- return smp_call_function_map(func,info,nonatomic,wait,cpu_online_map);
+ return __smp_call_function_map(func, info, nonatomic, wait,
+ cpu_online_map);
}
int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
@@ -278,8 +280,8 @@ int smp_call_function(void (*func) (void *info), void *info, int nonatomic,
}
EXPORT_SYMBOL(smp_call_function);
-int smp_call_function_single(int cpu, void (*func) (void *info), void *info, int nonatomic,
- int wait)
+int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
+ int nonatomic, int wait)
{
cpumask_t map = CPU_MASK_NONE;
int ret = 0;
@@ -292,7 +294,7 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info, int
cpu_set(cpu, map);
if (cpu != get_cpu())
- ret = smp_call_function_map(func,info,nonatomic,wait,map);
+ ret = __smp_call_function_map(func, info, nonatomic, wait, map);
else {
local_irq_disable();
func(info);
^ permalink raw reply related
* 2.6.10 kernel hangs after timer_init
From: goog long @ 2007-12-28 3:49 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
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.500000 MHz
time_init: processor frequency = 1800.000000 MHz
-> set_preferred_console()
stdout is /ht@0/isa@8,2/serial@a0
Found serial console at ttyS0
smp_prepare_cpus
smp_mpic_probe()...
nr_cpus: 2
smp: kicking cpu 1
---------------------------------
Never miss a thing. Make Yahoo your homepage.
[-- Attachment #2: Type: text/html, Size: 790 bytes --]
^ permalink raw reply
* RE: Device node - How does kernel know about it
From: Siva Prasad @ 2007-12-28 3:27 UTC (permalink / raw)
To: Nicholas Mc Guire, Jon Smirl; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.60.0712280936420.1827@rtl14.hofr.at>
Thank you Jon and Nicholas.
I already have "console=3DttyS0" 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
example a read() function call from user program?=20
I would like to start debugging from there and see if any thing at all
happens when there is a call. Appreciate your help with this question.
Thanks
Siva
-----Original Message-----
From: Nicholas Mc Guire [mailto:der.herr@hofr.at]=20
Sent: Friday, December 28, 2007 12:39 AM
To: Siva Prasad
Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
Subject: Re: Device node - How does kernel know about it
-----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.
> * Looking further into tty driver, I noticed that call to tty_write()
or
> do_tty_write() is not happening at all. So, somewhere the interface
> between kernel and user program is lost.
> * Just to check it out, I tried to write a small kernel module and a
> test program.
> - Attached memtest.c module (not really testing memory there. :-))
> - Attached testmemtest.c user program, that just open's it and reads
> the information
> - Created a device node using "mknod /dev/memtest c 168 0"
> - When I do "insmod memtest.ko" inside the ramdisk bootup scripts, I
> could see all the printk's on the console
> - When I execute "testmemtest" next in the same script, it does not
> display the printk inside of memtest.c module. This only indicates
that
> read call did not really go to the kernel side.
> - Just to check my program's validity, I checked on a similar machine
> and all the code works fine.
> - "uname -r" also matches with what I built. So, chances of exiting
> from open call because of mismatch is remote. Since userland cannot
> print, I have no idea what exactly is happening there.
>
The kernel will simply look at the major:minor numbers - so maybe you
simply have a wrong major/minor for /dev/ttyS0 ? in that case you will
see nothing but other than that most things will go on working.
hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFHdLY2nU7rXZKfY2oRApFpAKCKfGanKHGuFFJmUFy3aQtjmWNjEACfU7uK
hrfpn2RMn5l23ZqCOXV5rd8=3D
=3DGfsF
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Problems with arch/powerpc
From: Sean MacLennan @ 2007-12-28 3:03 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071227194753.56bc92f8@vader.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
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
modified, but everything else is correct.
I checked all the dts entries marked by /* Filled in by zImage */ by
checking /proc/device-tree and they all match what is printed after the
log message "Uncompressing Kernel Image ... OK".
FYI: It is a 533MHz PPC but the HW guys read the spec wrong and are
running the system clock at 66.0MHz rather than 66.6MHz, so the 528MHz
value is correct.
Cheers,
Sean
[-- Attachment #2: boot --]
[-- Type: text/plain, Size: 6593 bytes --]
U-Boot 1.3.0-gf92edbd8-dirty (Dec 7 2007 - 11:06:34)
CPU: AMCC PowerPC 440EP Rev. C at 533.333 MHz (PLB=133, OPB=66, EBC=66 MHz)
I2C boot EEPROM enabled
Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
, PCI async ext clock used 32 kB I-Cache 32 kB D-Cache
Board: PIKA Embedded Appliance
I2C: ready
DRAM: 256 MB
FLASH: 64 MB
NAND: 64 MiB
In: serial
Out: serial
Err: serial
Protected 2 sectors
FPGA download...complete.
FPGA code revision 1.2.2.0
Starting board diagnostics:
1. RAM walking bit test, first bank... test complete.
2. RAM walking bit test, second bank... test complete.
3. FPGA walking bit test... test complete.
4. Skipping user test - start_test_addr or end_test_addr env. vars not set.
Board diagnostics complete.
Net: ppc_4xx_eth0
Type "run flash_nfs" to mount root filesystem over NFS
Hit any key to stop autoboot: 0
Waiting for PHY auto negotiation to complete. done
ENET Speed is 100 Mbps - FULL duplex connection (EMAC0)
Using ppc_4xx_eth0 device
TFTP from server 192.168.0.164; our IP address is 192.168.0.99
Filename 'uImage'.
Load address: 0x200000
Loading: #################################################################
#################################################################
#################################################################
#############################################################
done
Bytes transferred = 1308159 (13f5ff hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.24-rc6-pika
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1308095 Bytes = 1.2 MB
Load Address: 00400000
Entry Point: 004003c8
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
CPU clock-frequency <- 0x1f78a400 (528MHz)
CPU timebase-frequency <- 0x1f78a400 (528MHz)
/plb: clock-frequency <- 7de2900 (132MHz)
/plb/opb: clock-frequency <- 3ef1480 (66MHz)
/plb/opb/ebc: clock-frequency <- 3ef1480 (66MHz)
/plb/opb/serial@ef600300: clock-frequency <- a8c000 (11MHz)
Memory <- <0x0 0x0 0x10000000> (256MB)
ENET0: local-mac-address <- <mac address>
zImage starting: loaded at 0x00400000 (sp: 0x0ff2a558)
Allocating 0x2b84a0 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x006ba364)...done 0x297408 bytes
Linux/PowerPC load: root=/dev/nfs rw nfsroot=192.168.x.x:/usr/src/eldk/taco ip=192.168.x.x:192.168.x.x:192.168.x.x:255.255.252.0:tigger:eth0:off panic=1 console=ttyS0,1150
Finalizing device tree... flat tree at 0x6c7300
Using Taco machine description
Linux version 2.6.24-rc6-pika (seanm@lappy) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #14 Thu Dec 27 16:33:16 EST 2007
console [udbg0] enabled
setup_arch: bootmem
arch: exit
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/nfs rw nfsroot=192.168.x.x:/usr/src/eldk/taco ip=192.168.x.x:192.168.x.x:192.168.x.x:255.255.252.0:tigger:eth0:off panic=1 console=ttyS0,110
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
PID hash table entries: 1024 (order: 10, 4096 bytes)
clocksource: timebase mult[79364e] shift[22] registered
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256768k/262144k available (2516k kernel code, 5056k reserved, 116k data, 129k bss, 140k init)
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
SCSI subsystem initialized
NET: Registered protocol family 2
Time: timebase clocksource has been installed.
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
JFFS2 version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xef600300 (irq = 16) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
PPC 4xx OCP EMAC driver, version 3.54
MAL v1 /plb/mcmal, 4 TX channels, 2 RX channels
ZMII /plb/opb/emac-zmii@ef600d00 initialized
/plb/opb/emac-zmii@ef600d00: bridge in RMII mode
eth0: EMAC-0 /plb/opb/ethernet@ef600e00, MAC 00:1e:84:ff:n.n
eth0: found Generic MII PHY (0x01)
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
eth0: link is down
IP-Config: Complete:
device=eth0, addr=192.168.x.x, mask=255.255.252.0, gw=192.168.x.x,
host=tigger, domain=, nis-domain=(none),
bootserver=192.168.x.x, rootserver=192.168.x.x, rootpath=
Looking up port of RPC 100003/2 on 192.168.x.x
eth0: link is up, 100 FDX, pause enabled
Looking up port of RPC 100005/1 on 192.168.x.x
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 140k init
init started: BusyBox v1.6.1 (2007-09-17 15:31:56 EDT) multi-call binary
starting pid 16, tty '': '/sbin/syslogd'
starting pid 19, tty '': '/etc/rc.S'
starting pid 28, tty '': '/sbin/getty'
tigger login:
^ permalink raw reply
* Re: Problems with arch/powerpc
From: Josh Boyer @ 2007-12-28 1:47 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <47742519.8060502@pikatech.com>
On Thu, 27 Dec 2007 17:20:09 -0500
Sean MacLennan <smaclennan@pikatech.com> 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.19.2 kernel working by basically copying the Yosemite
> configuration. Now I am trying to move from the ppc to the powerpc
> architecture using Josh Boyer's for-2.6.25 kernel. And there is no
> Yosemite config :( We are using u-boot 1.3.0.
Yeah, I've no Yosemite board so no port for it yet.
> I have the kernel booting, but the OS runs very strange. I cannot run
> the ash shell, it fails on the first setjmp. But I can run the hush
> shell (we are using busybox). So it goes, many things work, others don't.
>
> I am mounting the root filesystem over NFS, so the ethernet seem to work
> well.
>
> But cat /proc/interrupts shows:
>
> CPU0
> 16: 126 UIC Level serial
> 17: 520 UIC Level MAL TX EOB
> 18: 804 UIC Level MAL RX EOB
> 19: 0 UIC Level MAL SERR
> 20: 0 UIC Level MAL TX DE
> 21: 0 UIC Level MAL RX DE
> 28: 0 UIC Level EMAC
> BAD: 0
Looks fairly normal to me.
>
> Which is quite different from the older kernel:
>
> CPU0
> 0: 3075 UIC0 Level serial
> 2: 1526 UIC0 Level IBM IIC
> 7: 0 UIC0 Level IBM IIC
> 10: 1388 UIC0 Level MAL TX EOB
> 11: 1839 UIC0 Level MAL RX EOB
> 32: 0 UIC1 Level MAL SERR
> 33: 0 UIC1 Level MAL TX DE
> 34: 0 UIC1 Level MAL RX DE
> 40: 1 UIC1 Level ohci_hcd:usb1
> 60: 0 UIC1 Level EMAC
> BAD: 0
>
There's no support for the i2c devices on 440 in arch/powerpc yet,
which is why those don't show up. 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.
> I have attached the dts file. It is based on the bamboo. I can provide
> any other config, the only thing I can't provide is the hardware ;)
> Since the new kernel doesn't show UIC0 or UIC1, just UIC I am wondering
> if something is wrong with the dts.
I didn't see anything wrong in my cursory glance. But I need to look
at it a bit closer to be sure.
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.
josh
^ permalink raw reply
* update: RE: nap/dfs on 7448
From: Leisner, Martin @ 2007-12-27 22:37 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191304917.6310.99.camel@pasglop>
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=20
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...
If anyone needs this work, let me know (it will be covered under GPL).
marty
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> Sent: Tuesday, October 02, 2007 2:02 AM
> To: Leisner, Martin
> Cc: linuxppc-dev
> Subject: Re: nap/dfs on 7448
> =20
> =20
> On Mon, 2007-10-01 at 17:32 -0400, Leisner, Martin wrote:
> > I asked this on linuxppc-embedded a week ago (I didn't even know
this
> > list existed until last week -- another reason to get rid of
> > linuxpcc-embedded).
> >
> > Has anyone gotten NAP/DFS to reliably work on a 7448?
> >
> > I'm seeing strange problems with peripherals...(using a ram disk
> > works fine).
> =20
> Could it be that your host bridge isn't properly waking up the CPU
to
> DOZE state for snooping DMA ? (It might require some delays on QACK
in
> some cases, I know Apple had workarounds in those areas, maybe
something
> along those lines need to be configured in the chipset).
> =20
> Ben.
> =20
^ permalink raw reply
* Problems with arch/powerpc
From: Sean MacLennan @ 2007-12-27 22:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stefan Roese
[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]
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 move from the ppc to the powerpc
architecture using Josh Boyer's for-2.6.25 kernel. And there is no
Yosemite config :( We are using u-boot 1.3.0.
I have the kernel booting, but the OS runs very strange. I cannot run
the ash shell, it fails on the first setjmp. But I can run the hush
shell (we are using busybox). So it goes, many things work, others don't.
I am mounting the root filesystem over NFS, so the ethernet seem to work
well.
But cat /proc/interrupts shows:
CPU0
16: 126 UIC Level serial
17: 520 UIC Level MAL TX EOB
18: 804 UIC Level MAL RX EOB
19: 0 UIC Level MAL SERR
20: 0 UIC Level MAL TX DE
21: 0 UIC Level MAL RX DE
28: 0 UIC Level EMAC
BAD: 0
Which is quite different from the older kernel:
CPU0
0: 3075 UIC0 Level serial
2: 1526 UIC0 Level IBM IIC
7: 0 UIC0 Level IBM IIC
10: 1388 UIC0 Level MAL TX EOB
11: 1839 UIC0 Level MAL RX EOB
32: 0 UIC1 Level MAL SERR
33: 0 UIC1 Level MAL TX DE
34: 0 UIC1 Level MAL RX DE
40: 1 UIC1 Level ohci_hcd:usb1
60: 0 UIC1 Level EMAC
BAD: 0
I have attached the dts file. It is based on the bamboo. I can provide
any other config, the only thing I can't provide is the hardware ;)
Since the new kernel doesn't show UIC0 or UIC1, just UIC I am wondering
if something is wrong with the dts.
I have to admit the dts file confuses me a bit. So I suspect that is
where the problem is. If anybody has any other ideas, don't hesitate to
suggest!
Cheers,
Sean
[-- Attachment #2: taco.dts --]
[-- Type: text/plain, Size: 4665 bytes --]
/*
* Device Tree Source for PIKA Taco
*
* Copyright 2007 PIKA Technologies
*
* 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.
*/
/ {
#address-cells = <2>;
#size-cells = <1>;
model = "pika,taco";
compatible = "pika,taco";
dcr-parent = <&/cpus/cpu@0>;
aliases {
ethernet0 = &EMAC0;
serial0 = &UART0;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
model = "PowerPC,440EP";
reg = <0>;
clock-frequency = <0>; /* Filled in by zImage */
timebase-frequency = <0>; /* Filled in by zImage */
i-cache-line-size = <20>;
d-cache-line-size = <20>;
i-cache-size = <8000>;
d-cache-size = <8000>;
dcr-controller;
dcr-access-method = "native";
};
};
memory {
device_type = "memory";
reg = <0 0 0>; /* Filled in by zImage */
};
UIC0: interrupt-controller0 {
compatible = "ibm,uic-440ep","ibm,uic";
interrupt-controller;
cell-index = <0>;
dcr-reg = <0c0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
};
UIC1: interrupt-controller1 {
compatible = "ibm,uic-440ep","ibm,uic";
interrupt-controller;
cell-index = <1>;
dcr-reg = <0d0 009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <1e 4 1f 4>; /* cascade */
interrupt-parent = <&UIC0>;
};
SDR0: sdr {
compatible = "ibm,sdr-440ep";
dcr-reg = <00e 002>;
};
CPR0: cpr {
compatible = "ibm,cpr-440ep";
dcr-reg = <00c 002>;
};
plb {
compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4";
#address-cells = <2>;
#size-cells = <1>;
ranges;
clock-frequency = <0>; /* Filled in by zImage */
SDRAM0: sdram {
compatible = "ibm,sdram-440ep", "ibm,sdram-405gp";
dcr-reg = <010 2>;
};
DMA0: dma {
compatible = "ibm,dma-440ep", "ibm,dma-440gp";
dcr-reg = <100 027>;
};
MAL0: mcmal {
compatible = "ibm,mcmal-440ep", "ibm,mcmal-440gp", "ibm,mcmal";
dcr-reg = <180 62>;
num-tx-chans = <4>;
num-rx-chans = <2>;
interrupt-parent = <&MAL0>;
interrupts = <0 1 2 3 4>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
/*RXEOB*/ 1 &UIC0 b 4
/*SERR*/ 2 &UIC1 0 4
/*TXDE*/ 3 &UIC1 1 4
/*RXDE*/ 4 &UIC1 2 4>;
};
POB0: opb {
compatible = "ibm,opb-440ep", "ibm,opb-440gp", "ibm,opb";
#address-cells = <1>;
#size-cells = <1>;
ranges = <00000000 0 00000000 80000000
80000000 0 80000000 80000000>;
interrupt-parent = <&UIC1>;
interrupts = <7 4>;
clock-frequency = <0>; /* Filled in by zImage */
EBC0: ebc {
compatible = "ibm,ebc-440ep", "ibm,ebc-440gp", "ibm,ebc";
dcr-reg = <012 2>;
#address-cells = <2>;
#size-cells = <1>;
clock-frequency = <0>; /* Filled in by zImage */
interrupts = <5 1>;
interrupt-parent = <&UIC1>;
};
UART0: serial@ef600300 {
device_type = "serial";
compatible = "ns16550";
reg = <ef600300 8>;
virtual-reg = <ef600300>;
clock-frequency = <0>; /* Filled in by zImage */
current-speed = <1c200>;
interrupt-parent = <&UIC0>;
interrupts = <0 4>;
};
IIC0: i2c@ef600700 {
device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
};
IIC1: i2c@ef600800 {
device_type = "i2c";
compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
reg = <ef600800 14>;
interrupt-parent = <&UIC0>;
interrupts = <7 4>;
};
ZMII0: emac-zmii@ef600d00 {
device_type = "zmii-interface";
compatible = "ibm,zmii-440ep", "ibm,zmii-440gp", "ibm,zmii";
reg = <ef600d00 c>;
};
EMAC0: ethernet@ef600e00 {
linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
interrupts = <1c 4 1d 4>;
reg = <ef600e00 70>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <0 1>;
mal-rx-channel = <0>;
cell-index = <0>;
max-frame-size = <5dc>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rmii";
phy-map = <00000000>;
zmii-device = <&ZMII0>;
zmii-channel = <0>;
};
usb@ef601000 {
compatible = "ohci-be";
reg = <ef601000 80>;
interrupts = <8 1 9 1>;
interrupt-parent = < &UIC1 >;
};
};
};
chosen {
linux,stdout-path = "/plb/opb/serial@ef600300";
};
};
^ permalink raw reply
* Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
From: Michael Buesch @ 2007-12-27 18:13 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Andrew Morton, paulus, linuxppc-dev
In-Reply-To: <20071227101404.2C05F2405E@gemini.denx.de>
On Thursday 27 December 2007 11:14:04 Wolfgang Denk wrote:
> In message <200712261708.51432.mb@bu3sch.de> you wrote:
> > On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote:
> > > Michael Buesch <mb@bu3sch.de> writes:
> > >
> > > > + set +e
> > > > mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
> > > > $uboot_version -d "$vmz" "$ofile"
> > > > + [ $? -eq 0 ] || exit 0
> > > > + set -e
> > >
> > > mkimage ... || exit 0
> >
> > Could you PLEASE increase your verbosity?
> > Why is mkimage || exit 0 any better than my test?
>
> Because it works, while your's doesn't.
>
> Make runs each command in a new shell. Your "set +e" is in vain, and
> so is your test of the return code.
>
> Um... doesn't make throw an error anyway when the execution of
> mkimage fails?
I'm not sure what you are talking about at all, sorry.
set +e simply disables the abortion of the shell script if
the mkimage command fails. The test after that checks whether it failed
and returns success in that event, so the calling makefile does
_not_ interrupt. It only gives you a mkimage not found message.
I did test this patch on my machine where there is no mkimage
and it correctly aborts the shell script and throws an error,
while it does not abort the makefile process. And that is what we want.
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH 0/5] Version 17, series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-27 16:47 UTC (permalink / raw)
To: i2c, linuxppc-dev, linux-kernel
In-Reply-To: <20071220044136.20091.70984.stgit@terra.home>
On 12/19/07, Jon Smirl <jonsmirl@gmail.com> 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 place and not changed for non-powerpc platforms. This patch is fully capable of dynamically loading the i2c modules. You can modprobe in the i2c-mpc driver and the i2c modules described in the device tree will be automatically loaded. Modules also work if compiled in.
Are there any further objections to this patch? Can it all go in
through the powerpc trees or do the i2c people want to send it on?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
From: Anton Vorontsov @ 2007-12-27 16:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <4773C6EF.1020106@freescale.com>
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. I tried to explain the
> need for a unified microcode validation mechanism to the QE microcode
> developers, but I didn't get very far.
>
> >Well. All I've found is: QERAMPTCH.zip ("RAM Microcode Patches for
> >PowerQUICC II Pro Family QE Errata"), which should fix QE_UART5 errata
> >for MPC8323 Rev 1.1.
>
> I don't know what that is, but it doesn't apply. I'm talking about the
> QE and QE UART patches I've posted to this mailing list over the past
> month.
:-) I didn't get it wrong. QERAMPTCH.zip is the microcode (they
name it "microcode patches") I've tried, it has nothing to do with
your Linux patches.
> Once Kumar applies them to them to his for-2.6.25 branch, it'll
> make life easier for everyone.
>
> Can I assume it works for MPC8360 too?
>
> No. Microcode is very sensitive to the processor and the revision. A
> microcode for 8360 2.1 won't work on 8360 2.0.
>
> I forgot to give you the actual microcode. :-) I'll email it to you later.
Much thanks! Also, could you provide the magic python script to
generate binary firmwares to try loading fw from the linux? Or
just a .bin file.
> >Here are dts entries I use:
> >
> > firmware {
> > id = "Soft-UART";
> > extended_modes = <0 0>;
> > virtual_traps = <0 0 0 0 0 0 0 0>;
> > };
>
> This entry is created by U-Boot only if it uploads the microcode. This
> should not be in the DTS.
Sure thing. That was just a quirk for the quick testing, to not tinker
with u-boot part.
> >
> > ucc@2400 {
> > device_type = "serial";
> > compatible = "ucc_uart";
> > reg = <0x2400 0x200>;
> > device-id = <5>;
> > port-number = <0>;
> > rx-clock-name = "brg7";
> > tx-clock-name = "brg8";
> > interrupts = <40>;
> > interrupt-parent = <&qeic>;
> > soft-uart;
> > };
> >
> > ucc@3400 {
> > device_type = "serial";
> > compatible = "ucc_uart";
> > reg = <0x3400 0x200>;
> > device-id = <6>;
> > port-number = <1>;
> > rx-clock-name = "brg14";
> > tx-clock-name = "brg14";
> > interrupts = <41>;
> > interrupt-parent = <&qeic>;
> > };
>
> You need to have separate BRGs for TX and RX when using soft-uart mode,
> and you MUST use soft-uart mode on the 8360.
Yup, I know. In the original email I've explained that I deliberately
configured two uarts differently for the testing purposes.
Thanks!
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] [POWERPC] MPC8360E-RDK: Device tree and board file
From: Timur Tabi @ 2007-12-27 15:38 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20071226162943.GB11230@localhost.localdomain>
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 mechanism to the QE microcode
developers, but I didn't get very far.
> Well. All I've found is: QERAMPTCH.zip ("RAM Microcode Patches for
> PowerQUICC II Pro Family QE Errata"), which should fix QE_UART5 errata
> for MPC8323 Rev 1.1.
I don't know what that is, but it doesn't apply. I'm talking about the
QE and QE UART patches I've posted to this mailing list over the past
month. Once Kumar applies them to them to his for-2.6.25 branch, it'll
make life easier for everyone.
Can I assume it works for MPC8360 too?
No. Microcode is very sensitive to the processor and the revision. A
microcode for 8360 2.1 won't work on 8360 2.0.
I forgot to give you the actual microcode. :-) I'll email it to you later.
> Here are dts entries I use:
>
> firmware {
> id = "Soft-UART";
> extended_modes = <0 0>;
> virtual_traps = <0 0 0 0 0 0 0 0>;
> };
This entry is created by U-Boot only if it uploads the microcode. This
should not be in the DTS.
>
> ucc@2400 {
> device_type = "serial";
> compatible = "ucc_uart";
> reg = <0x2400 0x200>;
> device-id = <5>;
> port-number = <0>;
> rx-clock-name = "brg7";
> tx-clock-name = "brg8";
> interrupts = <40>;
> interrupt-parent = <&qeic>;
> soft-uart;
> };
>
> ucc@3400 {
> device_type = "serial";
> compatible = "ucc_uart";
> reg = <0x3400 0x200>;
> device-id = <6>;
> port-number = <1>;
> rx-clock-name = "brg14";
> tx-clock-name = "brg14";
> interrupts = <41>;
> interrupt-parent = <&qeic>;
> };
You need to have separate BRGs for TX and RX when using soft-uart mode,
and you MUST use soft-uart mode on the 8360.
^ permalink raw reply
* Re: Using SPI in lite5200
From: Miguel Angel Alvarez @ 2007-12-27 15:17 UTC (permalink / raw)
To: Miguel Angel Alvarez; +Cc: linuxppc-embedded
In-Reply-To: <477385A4.8020808@ziv.es>
Hi
It seems the problem is much harder that I thought. I was trying to use=20
SPI_MOSI, SPI_MISO, SPI_SS and SPI_CLK lines in the PSC3 of my MPC5200,=20
and this made me thought that I could use the "mpc52xx-psc-spi" driver.
Reading better the user guide, I have found that the "mpc52xx-psc-spi"=20
driver is related to the "codec" spi of the PSC3 and not to the SPI=20
subsystem. Am I right?
In this case... Which code should I use as "master driver"?=20
mpc52xx-devices.c talks about a "mpc52xx-spi" driver, but I cannot find=20
it. Does it exist?
All suggestions will be appreciated.
Thanks
Miguel =C1ngel=20
=20
----------------------------------------- PLEASE NOTE =
-------------------------------------------
This message, along with any attachments, may be confidential or legally =
privileged.=20
It is intended only for the named person(s), who is/are the only =
authorized recipients.
If this message has reached you in error, kindly destroy it without =
review and notify the sender immediately.
Thank you for your help.
=B5SysCom uses virus scanning software but excludes any liability for =
viruses contained in any attachment.
=20
------------------------------------ ROGAMOS LEA ESTE TEXTO =
-------------------------------
Este mensaje y sus anexos pueden contener informaci=F3n confidencial y/o =
con derecho legal.=20
Est=E1 dirigido =FAnicamente a la/s persona/s o entidad/es rese=F1adas =
como =FAnico destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elim=EDnelo sin =
revisarlo ni reenviarlo y notif=EDquelo inmediatamente al remitente. =
Gracias por su colaboraci=F3n. =20
=B5SysCom utiliza software antivirus, pero no se hace responsable de los =
virus contenidos en los ficheros anexos.
^ permalink raw reply
* Using SPI in lite5200
From: Miguel Angel Alvarez @ 2007-12-27 10:59 UTC (permalink / raw)
To: linuxppc-embedded
Hi.
We are trying to use the SPI subsystem in the MPC5200 to write a driver=20
that supports SC16IS752 (SPI->2 UARTs).
Although I have read the spi-summary in the Documentation of the kernel, =
I am not quite sure of having understood all the pieces that I require=20
to make the system work.
First of all, I am using the SPI associated to PSC3, so in the=20
mpc52xx_devices.c I have added a "[MPC52xx_PSC_SPI]" entry with exactly=20
the same parameters as "[MPC52xx_PSC3]", except for the name, which I=20
assign to mpc52xx-psc-spi (I suppose this is the correct driver for the=20
master of the SPI bus).
That is:
[MPC52xx_PSC_SPI] =3D {
.name =3D "mpc52xx-psc-spi",
.id =3D 2,
.num_resources =3D 2,
.resource =3D (struct resource[]) {
{
.start =3D 0x2400,
.end =3D 0x249f,
.flags =3D IORESOURCE_MEM,
},
{
.start =3D MPC52xx_PSC3_IRQ,
.end =3D MPC52xx_PSC3_IRQ,
.flags =3D IORESOURCE_IRQ,
},
},
},
My question is: Am I using the correct IRQ? Where can I find which is=20
the correct one?
Thanks
Miguel =C1ngel=20
=20
----------------------------------------- PLEASE NOTE =
-------------------------------------------
This message, along with any attachments, may be confidential or legally =
privileged.=20
It is intended only for the named person(s), who is/are the only =
authorized recipients.
If this message has reached you in error, kindly destroy it without =
review and notify the sender immediately.
Thank you for your help.
ZIV uses virus scanning software but excludes any liability for viruses =
contained in any attachment.
=20
------------------------------------ ROGAMOS LEA ESTE TEXTO =
-------------------------------
Este mensaje y sus anexos pueden contener informaci=F3n confidencial y/o =
con derecho legal.=20
Est=E1 dirigido =FAnicamente a la/s persona/s o entidad/es rese=F1adas =
como =FAnico destinatario autorizado.
Si este mensaje le hubiera llegado por error, por favor elim=EDnelo sin =
revisarlo ni reenviarlo y notif=EDquelo inmediatamente al remitente. =
Gracias por su colaboraci=F3n. =20
ZIV utiliza software antivirus, pero no se hace responsable de los virus =
contenidos en los ficheros anexos.
^ permalink raw reply
* Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
From: Andreas Schwab @ 2007-12-27 10:17 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Andrew Morton, linuxppc-dev, paulus
In-Reply-To: <20071227101404.2C05F2405E@gemini.denx.de>
Wolfgang Denk <wd@denx.de> writes:
> In message <200712261708.51432.mb@bu3sch.de> you wrote:
>> On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote:
>> > Michael Buesch <mb@bu3sch.de> writes:
>> >
>> > > + set +e
>> > > mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
>> > > $uboot_version -d "$vmz" "$ofile"
>> > > + [ $? -eq 0 ] || exit 0
>> > > + set -e
>> >
>> > mkimage ... || exit 0
>>
>> Could you PLEASE increase your verbosity?
>> Why is mkimage || exit 0 any better than my test?
>
> Because it works, while your's doesn't.
>
> Make runs each command in a new shell.
This is a shell script, not a makefile.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v2] powerpc: Do not fail build if mkimage is not available
From: Wolfgang Denk @ 2007-12-27 10:14 UTC (permalink / raw)
To: Michael Buesch; +Cc: Andrew Morton, paulus, linuxppc-dev
In-Reply-To: <200712261708.51432.mb@bu3sch.de>
In message <200712261708.51432.mb@bu3sch.de> you wrote:
> On Wednesday 26 December 2007 17:03:43 Andreas Schwab wrote:
> > Michael Buesch <mb@bu3sch.de> writes:
> >
> > > + set +e
> > > mkimage -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 \
> > > $uboot_version -d "$vmz" "$ofile"
> > > + [ $? -eq 0 ] || exit 0
> > > + set -e
> >
> > mkimage ... || exit 0
>
> Could you PLEASE increase your verbosity?
> Why is mkimage || exit 0 any better than my test?
Because it works, while your's doesn't.
Make runs each command in a new shell. Your "set +e" is in vain, and
so is your test of the return code.
Um... doesn't make throw an error anyway when the execution of
mkimage fails?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Success in marriage is not so much finding the right person as it is
being the right person.
^ permalink raw reply
* Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
From: Balbir Singh @ 2007-12-27 5:45 UTC (permalink / raw)
To: FUJITA Tomonori; +Cc: linuxppc-dev, akpm, linux-kernel, linux-scsi
In-Reply-To: <20071227134335O.fujita.tomonori@lab.ntt.co.jp>
FUJITA Tomonori wrote:
> On Thu, 27 Dec 2007 10:08:25 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>
>> FUJITA Tomonori wrote:
>>> On Mon, 24 Dec 2007 10:18:50 +0530
>>> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>>>
>> [snip]
>>
>>> I might break the IOMMU code. Can you reproduce it easily? If so,
>>> reverting my IOMMU patches (I've attached a patch to revert them) fix
>>> the problem?
>> [snip]
>>
>>
>> Yes, this patch fixes the problem for me.
>
> Thanks, so you can reproduce it easily, right?
>
Yes, quite easily
> The problem is that I don't want to revert these changes. I'll see
> how these changes cause the problem shortly.
I'll try and find some bandwidth to review/test the patches and help you
figure out the right solution.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
From: FUJITA Tomonori @ 2007-12-27 4:43 UTC (permalink / raw)
To: balbir; +Cc: fujita.tomonori, linuxppc-dev, akpm, linux-kernel, linux-scsi
In-Reply-To: <47732C41.7000003@linux.vnet.ibm.com>
On Thu, 27 Dec 2007 10:08:25 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> FUJITA Tomonori wrote:
> > On Mon, 24 Dec 2007 10:18:50 +0530
> > Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> >
> [snip]
>
> >
> > I might break the IOMMU code. Can you reproduce it easily? If so,
> > reverting my IOMMU patches (I've attached a patch to revert them) fix
> > the problem?
>
> [snip]
>
>
> Yes, this patch fixes the problem for me.
Thanks, so you can reproduce it easily, right?
The problem is that I don't want to revert these changes. I'll see
how these changes cause the problem shortly.
^ 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