* External interrupts with UIO framework on mpc8313e
From: Frank Prepelica @ 2008-02-11 11:24 UTC (permalink / raw)
To: linuxppc-embedded
Hi everyone!
I'm trying to receive external interrupts on the mpc8313erdb board.
I'm also using the UIO framework to register the interrupt handler.=20
It works for me when I register the interrupt handler for external =
interrupt IRQ4 (irq =3D 20)
But when I'm trying the register the handler for IRQ0(48)-IRQ3(17-19) it =
doesn't.=20
I'm using following simple code:
---snip---
static irqreturn_t intHandler(int irq, struct uio_info *dev_info)
{
printk("name: %s\n", dev_info->name);
return IRQ_HANDLED
}
static struct uio_info myinfo =3D {
.name =3D "IRQ4 Kernel Driver",
.version =3D "1.0.0",
.irq =3D 20,
.irq_flags =3D IRQF_SHARED | IRQF_DISABLED,
.handler =3D intHandler,
};
static int uio_probe(struct device *dev)
{
if(uio_register_device(dev,&myinfo))
{
return -ENODEV;
}
else
{
return 0;
}
}
---snip---
After booting the kernel, the driver (for IRQ4) appears correct in =
/proc/interrups and can be triggered.
I guess, this should also work for IRQ0-IRQ3 but it won't. IRQ0 cannot =
registered to 48 at all and the
other ones appear in /proc/interruts but they cannot be triggered (BUT =
shared with serial or i2c).=20
I also checked the value of the SEMSR register and see that IRQ4 is set =
correctly.
Okay, I thought when I set the SEMSR register manually e.g. IRQ2 to "1" =
and trigger the correct interrupt signal I could see in /proc/stat a =
counting value. Nothing happened. But the BAD counter in =
/proc/interrupts is rising.=20
Furthermore there's a mapping issue between the interrupt id number from =
the board manual
(page 8-10) and the output of /proc/interrupts. The kernel registers the =
i2c devices to=20
ID 16 and 17 although the manual says they are mapped to 14 and 15.
Any hint is appreciate!=20
Best regards
Frank Prepelica
Software Design Engineer
Ubidyne GmbH
Lise-Meitner-Str.-14
89081 Ulm - Germany
Phone:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +49 731 88 00 71 58
Fax:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +49 731 88 00 71 99
Email:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
frank.prepelica@ubidyne.com
Homepage:=A0=A0=A0=A0=A0=A0 www.ubidyne.com
=A0
Registered office: Ulm
District court of Ulm: HRB 5295
Managing Directors:
Dipl. Ing. Ken Hawk
Dipl. Ing. Beat M=FCller
Dr. Clemens Rheinfelder
^ permalink raw reply
* Re: APU FPU in Virtex ppc405
From: A. Nolson @ 2008-02-11 11:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40802081132h22b91464xd150e0671ca4fc34@mail.gmail.com>
I have been checking and it seems that the APU FPU patches will give
some headaches now, so I will probably wait until they merge them with
the official GCC release. In any case, it seems that the FPU restricts
the PowerPC and bus frequencies to a max of 200/100.
Anyway, thanks for the info. I will try to keep track of this in case of
an update.
Grant Likely wrote:
> On Feb 8, 2008 11:51 AM, A. Nolson <alohanono@gmail.com> wrote:
>
>> Hi,
>>
>> I have just heard that Xilinx has freed the FPU module for the PPC
>> architecture in EDK9.2i. WIll I be able to make it work with my
>> Secretlab Linux 2.6.24rc3? Will the eldk toolchain for PPC_4xxfp work?
>> Will it be just a matter of integrating it with the XPS BSP?I make an
>> extensive use of floating point in my applications and this will be
>> really useful.
>>
>
> It's been 2 years since I last played with the FPU core. At the time
> it wasn't a complete FPU so the eldk 4xxfp toolchain would not work.
> I had to build my own. I don't know if the new core is a complete
> implementation.
>
> Cheers,
> g.
>
>
>
^ permalink raw reply
* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-11 10:47 UTC (permalink / raw)
To: Dave Hansen
Cc: Jan-Bernd Themann, Greg KH, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, netdev
In-Reply-To: <1202724743.8276.2.camel@nimitz.home.sr71.net>
On Monday 11 February 2008 11:12, Dave Hansen wrote:
> On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> > are you the right person to address this patch to?
>
> You might want to check the top of the file. ;)
>
> > --- a/drivers/base/memory.c
> > +++ b/drivers/base/memory.c
> > @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> > {
> > return blocking_notifier_chain_register(&memory_chain, nb);
> > }
> > +EXPORT_SYMBOL(register_memory_notifier);
> >
> > void unregister_memory_notifier(struct notifier_block *nb)
> > {
> > blocking_notifier_chain_unregister(&memory_chain, nb);
> > }
> > +EXPORT_SYMBOL(unregister_memory_notifier);
>
> Is there a particular reason these can't be GPL?
>
I don't object to make them GPL. Greg, what do you think?
Regards,
Jan-Bernd
^ permalink raw reply
* Re: [PATCH] Fix compilation of powerpc asm-offsets.c with old gcc
From: Geert Uytterhoeven @ 2008-02-11 10:36 UTC (permalink / raw)
To: Simon Holm Thøgersen
Cc: linux-kernel, linuxppc-dev, Paul Jackson, paulus, akpm,
Linus Torvalds, tglx
In-Reply-To: <1202495464.6722.13.camel@odie.local>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 1496 bytes --]
On Fri, 8 Feb 2008, Simon Holm Thøgersen wrote:
> fre, 08 02 2008 kl. 12:06 -0600, skrev Paul Jackson:
> > Linus wrote:
> > > Please, when mentioning hex numbers, also do the one-liner shortlog.
> > > ...
> > > without _requiring_ people to be git users to get the gist of the
> > > matter, ok?
> >
> >
> > Thanks for sticking up for us git-challenged contributors.
> >
> > Can anyone point me at instructions providing the shortest
> > path for getting from one of those git hex numbers to the
> > log or change it represents, for non-git users?
>
> Use gitweb [1], Linus' tree is here [2]. Just search for the hex.
>
> [1] http://git.kernel.org/
> [2]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
As the IDs are supposed to be unique, it doesn't matter where you look it up,
as long as the tree has that commit ;-)
BTW, time for Google to start handling git IDs?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Dave Hansen @ 2008-02-11 10:12 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Jan-Bernd Themann, Greg KH, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, netdev
In-Reply-To: <200802111049.05478.ossthema@de.ibm.com>
On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> are you the right person to address this patch to?
You might want to check the top of the file. ;)
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> {
> return blocking_notifier_chain_register(&memory_chain, nb);
> }
> +EXPORT_SYMBOL(register_memory_notifier);
>
> void unregister_memory_notifier(struct notifier_block *nb)
> {
> blocking_notifier_chain_unregister(&memory_chain, nb);
> }
> +EXPORT_SYMBOL(unregister_memory_notifier);
Is there a particular reason these can't be GPL?
-- Dave
^ permalink raw reply
* [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-11 9:49 UTC (permalink / raw)
To: Greg KH
Cc: Jan-Bernd Themann, netdev, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
Hi Greg,
are you the right person to address this patch to?
Regards,
Jan-Bernd
drivers/base/memory.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 7ae413f..1e1bd4c 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
{
return blocking_notifier_chain_register(&memory_chain, nb);
}
+EXPORT_SYMBOL(register_memory_notifier);
void unregister_memory_notifier(struct notifier_block *nb)
{
blocking_notifier_chain_unregister(&memory_chain, nb);
}
+EXPORT_SYMBOL(unregister_memory_notifier);
/*
* register_memory - Setup a sysfs device for a memory block
--
1.5.2
^ permalink raw reply related
* [PATCH] ppc: Fix arch/ppc compilation - Add missing typedef pgtable_t
From: Stefan Roese @ 2008-02-11 9:41 UTC (permalink / raw)
To: linuxppc-dev
Commit 2f569afd9ced9ebec9a6eb3dbf6f83429be0a7b4 ("CONFIG_HIGHPTE vs.
sub-page page tables.") breaks compilation of arch/ppc since it
introduces the pgtable_t type which was not added to arch/ppc.
This patch now adds the missing typedef.
Signed-off-by: Stefan Roese <sr@denx.de>
---
include/asm-ppc/page.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-ppc/page.h b/include/asm-ppc/page.h
index ad4c5a1..37e4756 100644
--- a/include/asm-ppc/page.h
+++ b/include/asm-ppc/page.h
@@ -125,6 +125,8 @@ extern __inline__ int get_order(unsigned long size)
return 32 - lz;
}
+typedef struct page *pgtable_t;
+
#endif /* __ASSEMBLY__ */
#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \
--
1.5.4.1
^ permalink raw reply related
* Re: Where is fcc_enet.c
From: Vitaly Bordug @ 2008-02-11 9:37 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1AA74@xmb-sjc-212.amer.cisco.com>
On Sun, 10 Feb 2008 15:08:46 -0800
Bizhan Gholikhamseh (bgholikh) wrote:
> Hi,
> I am porting to Linux 2.6.24 from linux 2.6.11 on mpc85xx cds
> platform, I am not able to locate fcc_enet.c file under
> linux 2.6.24 source tree, any idea????
try drivers/net/fs_enet
at least CPM2 FCC is handled in there.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [RFC][POWERPC] bootwrapper: Add a firmware-independent
From: Milton Miller @ 2008-02-11 7:07 UTC (permalink / raw)
To: david, grant.likely; +Cc: linuxppc-dev
On Friday, Feb 8, 2008 David Gibson wrote:
> On Fri, Feb 01, 2008 at 11:55:42PM -0700, Grant Likely wrote:
> From: Grant Likely <grant.likely at secretlab.ca>
[snip]
>> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
>> + unsigned long r6, unsigned long r7)
>> +{
>> +const u32 *na, *ns, *reg, *timebase;
>> +u64 memsize64;
>> +int node, size, i;
>> +
>> +/* Allocate initial heap for probing the tree */
>> +simple_alloc_init(initial_heap, sizeof(initial_heap), 32, 64);
>> +
>> +/* Make sure FDT blob is sane */
>> +if (fdt_check_header(_dtb_start) != 0)
>> +fatal("Invalid device tree blob\n");
>
> I think most of these fatal()s are pretty pointless. This is
> platform_init(), so the console won't even have been initialized to
> actually print any of the messages. Precisely because this is
> simpleboot, in which every bit of information the wrapper has comes
> from teh device tree, if the provided blob is so bad as to fail these
> basic tests, we're totally stuffed anyway. It'll take a hardware
> debugger to track down, and I don't think the fatal()s will actually
> help much at that point.
My experience is the opposite: fatal is very useful even with a hardware debugger. Since the code knows what is wrong, one only has to get the printf assembly buffer out of the map and dump it out. Also, one can find which function called fatal from the nia and/or lr. Much much easier than figuring out what happend when the prcessor jumps into the middle of code because it took an exception.
Also, one can patch in a debug output routine, possibly even in the __zlib_init. Having the assertions is good.
That said, we should be conservative in calling something an error.
milton
^ permalink raw reply
* Re: [PATCH] PPC440EP Interrupt Triggering and Level Settings
From: Stefan Roese @ 2008-02-11 6:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Wolfgang Ocker
In-Reply-To: <1202671442.3384.15.camel@galileo.recco.de>
On Sunday 10 February 2008, Wolfgang Ocker wrote:
> From: Wolfgang Ocker <weo@reccoware.de>
>
> Corrected IRQ triggering and level settings according to latest revision
> of the 440EP User Manual (rev 1.24 nov 16, 2007).
>
> The incorrect settings might cause a failure of the network if both
> onchip ethernet ports are under heavy load.
>
> Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
Thanks, looks good.
Acked-by: Stefan Roese <sr@denx.de>
Best regards,
Stefan
^ permalink raw reply
* Re: Ebony development board
From: Stefan Roese @ 2008-02-11 6:20 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <47AE00FE.1000704@uid0.hu>
Hi Zoltan,
On Saturday 09 February 2008, Zoltan HERPAI wrote:
> I've recently got an Ebony board (440GP) with the original bootloader
> (440GP 1.18 ROM Monitor) which I would like to replace with U-boot. Is
> there a way to boot an U-boot image via TFTP to replace the bootloader,
> or is it possible only with using a JTAG? I've googled through the
> mailing list, but most of the related hits are dated back in 2004-2005,
> they say no, one have to use JTAG, but some time passed since then, and
> I would like to know if there is a way for this.
Does the original ROM monitor support writing to onboard FLASH? If yes, it
should be possible.
Best regards,
Stefan
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Sean MacLennan @ 2008-02-11 3:49 UTC (permalink / raw)
To: LinuxPPC-dev
In-Reply-To: <20080211031110.GD11572@localhost.localdomain>
David Gibson wrote:
> On Sun, Feb 10, 2008 at 09:40:19PM -0500, Sean MacLennan wrote:
>
>> David Gibson wrote:
>>
>>> This doesn't seem right. warp_fixup_one_nor() changes only the
>>> partition's offset, so you're not changing the size of any
>>> partitions. If you're not going to actually use any of the extra
>>> flash space with 64M, I can't see why you'd bother moving around the
>>> partitions you have.
>>>
>>>
>> u-boot must be at the bottom of the flash. Also, for the 64M NOR flash
>> you can put everything in the NOR flash, I just don't show the
>> partitions. Booting from NOR is *much* faster than booting from
>> NAND.
>>
>
> Sorry, still not really following what's going on. Without worrying
> about the dts formatting or fixup code, can you summarise what the two
> flash maps look like?
>
>
I guess what is confusing is that I am actually working with 3 flash
maps right now, although there will only be one map in the final version.
Map1:
NOR:
Kernel @ 0
Ramdisk
User
FPGA
Env
U-boot @ 63.5M
Map 2:
NOR:
FPGA
Env
U-boot @ 63.5M
NAND:
Kernel @ 0
Ramdisk
User
Map 3:
Same as Map 2 only 4M NOR rather than 64M, so u-boot @ 3.5M.
The u-boot, env, and FPGA are anchored at the bottom of the flash.
Kernel is anchored at the top. Everything else goes in the middle.
The FPGA partition contains the FPGA image. The user partition contains
a persistent JFFS2 file system. I don't use the user partition, so it
doesn't show up in the map I sent.
So map 1 was used until we got the NAND working. Map 2 is an interim
solution until we get the 4M flash. Map 3 is the final version.
Cheers,
Sean
^ permalink raw reply
* Re: [libfdt] RFC: Node iterators (v2)
From: David Gibson @ 2008-02-11 3:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <47AB956D.4090805@freescale.com>
On Thu, Feb 07, 2008 at 05:34:05PM -0600, Scott Wood wrote:
> David Gibson wrote:
> > And here's a revised version. This now also handles recursive
> > iteration and iteration across nodes without respect to depth. I've
> > removed the for_each() macros for the time being, because they were
> > making my brain hurt, but I'm still contemplating bringing them back.
> > Several libfdt functions are now implemented using the new iterator,
> > so this ends up as a code-size-reducing patch.
> >
> > I'm pretty happy with the basic outline of this now, although the
> > names and details might want a bit of polish still.
>
> Can we get this merged?
Well, I'm back from holidays now, so I will resume looking at this. I
hope we can merge it soon, yes.
> > +int _fdt_next_node(const void *fdt, int offset, int *depth)
> > +{
>
> This is a public function; why the underscore?
Well, because I still think of it as a low-level "only use if you
really know what you're doing" type function (which is what _ is
supposed to indicate; truly private functions don't need the fdt_
prefix at all).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-11 3:11 UTC (permalink / raw)
To: Sean MacLennan; +Cc: LinuxPPC-dev
In-Reply-To: <47AFB593.30805@pikatech.com>
On Sun, Feb 10, 2008 at 09:40:19PM -0500, Sean MacLennan wrote:
> David Gibson wrote:
> > This doesn't seem right. warp_fixup_one_nor() changes only the
> > partition's offset, so you're not changing the size of any
> > partitions. If you're not going to actually use any of the extra
> > flash space with 64M, I can't see why you'd bother moving around the
> > partitions you have.
> >
> u-boot must be at the bottom of the flash. Also, for the 64M NOR flash
> you can put everything in the NOR flash, I just don't show the
> partitions. Booting from NOR is *much* faster than booting from
> NAND.
Sorry, still not really following what's going on. Without worrying
about the dts formatting or fixup code, can you summarise what the two
flash maps look like?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Sean MacLennan @ 2008-02-11 2:40 UTC (permalink / raw)
To: LinuxPPC-dev
In-Reply-To: <20080211001451.GA11572@localhost.localdomain>
David Gibson wrote:
> This doesn't seem right. warp_fixup_one_nor() changes only the
> partition's offset, so you're not changing the size of any
> partitions. If you're not going to actually use any of the extra
> flash space with 64M, I can't see why you'd bother moving around the
> partitions you have.
>
u-boot must be at the bottom of the flash. Also, for the 64M NOR flash
you can put everything in the NOR flash, I just don't show the
partitions. Booting from NOR is *much* faster than booting from NAND.
>
> In practice, probably not. We already do a similar fixup on Ebony for
> different flash layouts that won't leave the unit names correct. We
> really should get this right - and the fdt_set_name() function that's
> now in libfdt should make that possible, it just needs some wiring up
> to use in the bootwrapper. That can come later, though, for now I
> think applying your fixups without correcting the unit addresses is
> adequate.
>
>
Ok.
>> If anybody has suggestions on better ways to do this, fire away.
>>
>> And looking at this code, and other board ports, why is sysclk a local
>> variable and all the other numbers hardcoded in the args? I left it the
>> same way as the others but it does look a bit strange.
>>
>
> I think this also came from Ebony. IIRC, the sysclk isn't strictly
> speaking fixed, although it almost always has initialized value. The
> point of the local variable was that I planned to replace the static
> initialization with some sort of probing once I figured out the
> details.
>
That makes sense. I don't think you can probe for the sysclk on the
taco, so I may just put it as a constant to the function.
Cheers,
Sean
^ permalink raw reply
* [PATCH] [POWERPC] Wire up new timerfd syscalls
From: Stephen Rothwell @ 2008-02-11 0:38 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, LKML
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/systbl.h | 4 +++-
include/asm-powerpc/unistd.h | 6 ++++--
2 files changed, 7 insertions(+), 3 deletions(-)
Kernel built for ppc64_defconfig, pseries_defconfig, iseries_defconfig,
cell_defconfig and pmac32_defconfig. The latter failed because
check_media_bay is still undefined (i.e. for unrelated reasons).
This has been tested on a pseries_defconfig kernel using the posted test
program built for 64 and 32 bit.
diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h
index e996521..ae7085c 100644
--- a/include/asm-powerpc/systbl.h
+++ b/include/asm-powerpc/systbl.h
@@ -309,8 +309,10 @@ SYSCALL_SPU(getcpu)
COMPAT_SYS(epoll_pwait)
COMPAT_SYS_SPU(utimensat)
COMPAT_SYS_SPU(signalfd)
-SYSCALL(ni_syscall)
+SYSCALL_SPU(timerfd_create)
SYSCALL_SPU(eventfd)
COMPAT_SYS_SPU(sync_file_range2)
COMPAT_SYS(fallocate)
SYSCALL(subpage_prot)
+COMPAT_SYS_SPU(timerfd_settime)
+COMPAT_SYS_SPU(timerfd_gettime)
diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h
index fedc4b8..ce91bb6 100644
--- a/include/asm-powerpc/unistd.h
+++ b/include/asm-powerpc/unistd.h
@@ -328,15 +328,17 @@
#define __NR_epoll_pwait 303
#define __NR_utimensat 304
#define __NR_signalfd 305
-#define __NR_timerfd 306
+#define __NR_timerfd_create 306
#define __NR_eventfd 307
#define __NR_sync_file_range2 308
#define __NR_fallocate 309
#define __NR_subpage_prot 310
+#define __NR_timerfd_settime 311
+#define __NR_timerfd_gettime 312
#ifdef __KERNEL__
-#define __NR_syscalls 311
+#define __NR_syscalls 313
#define __NR__exit __NR_exit
#define NR_syscalls __NR_syscalls
--
1.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: Could the DTS experts look at this?
From: David Gibson @ 2008-02-11 0:14 UTC (permalink / raw)
To: Sean MacLennan; +Cc: LinuxPPC-dev
In-Reply-To: <47ACE630.8090101@pikatech.com>
On Fri, Feb 08, 2008 at 06:30:56PM -0500, Sean MacLennan wrote:
> The Rev B warp is moving to a 4M NOR / 256M NAND flash setup from the
> current 64M NOR / 64M NAND. I would like to keep support for the 64M NOR
> so I modified the boot code to be a bit more dynamic. Here is the new
> NOR parition layout in the DTS:
>
> nor_flash@0,0 {
> compatible = "amd,s29gl512n", "cfi-flash";
> bank-width = <2>;
> reg = <0 0 4000000>;
> #address-cells = <1>;
> #size-cells = <1>;
> partition@300000 {
> label = "fpga";
> reg = <300000 40000>;
> };
> partition@340000 {
> label = "env";
> reg = <340000 40000>;
> };
> partition@380000 {
> label = "u-boot";
> reg = <380000 80000>;
> };
> };
>
> Yes, the top of the NOR will be empty. Here is the code from
> cuboot-warp.c to handle fixups for the 64M flash:
>
> static void warp_fixup_one_nor(u32 from, u32 to)
> {
> void *devp;
> char name[40];
> u32 v[2];
>
> sprintf(name, "/plb/opb/ebc/nor_flash@0,0/partition@%x", from);
>
> devp = finddevice(name);
> if (!devp) return;
>
> if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
> v[0] = to;
> setprop(devp, "reg", v, sizeof(v));
>
> printf("NOR 64M fixup %x -> %x\n", from, to);
> }
> }
>
>
> static void warp_fixups(void)
> {
> unsigned long sysclk = 66000000;
>
> ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
> ibm4xx_sdram_fixup_memsize();
> ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
> dt_fixup_mac_addresses(&bd.bi_enetaddr);
>
> /* Fixup for 64M flash on Rev A boards. */
> if(bd.bi_flashsize == 0x4000000) {
> warp_fixup_one_nor(0x300000, 0x3f00000);
> warp_fixup_one_nor(0x340000, 0x3f40000);
> warp_fixup_one_nor(0x380000, 0x3f80000);
> }
> }
This doesn't seem right. warp_fixup_one_nor() changes only the
partition's offset, so you're not changing the size of any
partitions. If you're not going to actually use any of the extra
flash space with 64M, I can't see why you'd bother moving around the
partitions you have.
> I have tested this with the 64M NOR, and it seems to work. However, are
> there going to be problems with the partition name not matching the reg
> address entry?
In practice, probably not. We already do a similar fixup on Ebony for
different flash layouts that won't leave the unit names correct. We
really should get this right - and the fdt_set_name() function that's
now in libfdt should make that possible, it just needs some wiring up
to use in the bootwrapper. That can come later, though, for now I
think applying your fixups without correcting the unit addresses is
adequate.
> If anybody has suggestions on better ways to do this, fire away.
>
> And looking at this code, and other board ports, why is sysclk a local
> variable and all the other numbers hardcoded in the args? I left it the
> same way as the others but it does look a bit strange.
I think this also came from Ebony. IIRC, the sysclk isn't strictly
speaking fixed, although it almost always has initialized value. The
point of the local variable was that I planned to replace the static
initialization with some sort of probing once I figured out the
details.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Where is fcc_enet.c
From: Bizhan Gholikhamseh (bgholikh) @ 2008-02-10 23:08 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 186 bytes --]
Hi,
I am porting to Linux 2.6.24 from linux 2.6.11 on mpc85xx cds platform,
I am not able to locate fcc_enet.c file under
linux 2.6.24 source tree, any idea????
Thanks,
Bizhan
[-- Attachment #2: Type: text/html, Size: 926 bytes --]
^ permalink raw reply
* [PATCH 1/8] arch/ppc: Use FIELD_SIZEOF
From: Julia Lawall @ 2008-02-10 20:07 UTC (permalink / raw)
To: paulus, linuxppc-dev
From: Julia Lawall <julia@diku.dk>
Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code
that matches its definition.
The modification was made using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@haskernel@
@@
#include <linux/kernel.h>
@depends on haskernel@
type t;
identifier f;
@@
- (sizeof(((t*)0)->f))
+ FIELD_SIZEOF(t, f)
@depends on haskernel@
type t;
identifier f;
@@
- sizeof(((t*)0)->f)
+ FIELD_SIZEOF(t, f)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
diff -u -p a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
--- a/arch/ppc/8xx_io/commproc.c 2008-02-02 15:28:16.000000000 +0100
+++ b/arch/ppc/8xx_io/commproc.c 2008-02-10 17:36:23.000000000 +0100
@@ -43,7 +43,7 @@
({ \
u32 offset = offsetof(immap_t, member); \
void *addr = ioremap (IMAP_ADDR + offset, \
- sizeof( ((immap_t*)0)->member)); \
+ FIELD_SIZEOF(immap_t, member)); \
addr; \
})
^ permalink raw reply
* [PATCH] PPC440EP Interrupt Triggering and Level Settings
From: Wolfgang Ocker @ 2008-02-10 19:24 UTC (permalink / raw)
To: jwboyer, mporter; +Cc: linuxppc-dev
From: Wolfgang Ocker <weo@reccoware.de>
Corrected IRQ triggering and level settings according to latest revision
of the 440EP User Manual (rev 1.24 nov 16, 2007).
The incorrect settings might cause a failure of the network if both
onchip ethernet ports are under heavy load.
Signed-off-by: Wolfgang Ocker <weo@reccoware.de>
---
--- linux-2.6.24/arch/ppc/platforms/4xx/ibm440ep.c.irq-trig 2008-01-24 23:58:37.000000000 +0100
+++ linux-2.6.24/arch/ppc/platforms/4xx/ibm440ep.c 2008-02-10 19:43:32.000000000 +0100
@@ -172,11 +172,11 @@
/* Polarity and triggering settings for internal interrupt sources */
struct ppc4xx_uic_settings ppc4xx_core_uic_cfg[] __initdata = {
{ .polarity = 0xffbffe03,
- .triggering = 0xfffffe00,
+ .triggering = 0x00000000,
.ext_irq_mask = 0x000001fc, /* IRQ0 - IRQ6 */
},
- { .polarity = 0xffffc6ef,
- .triggering = 0xffffc7ff,
+ { .polarity = 0xffffc6af,
+ .triggering = 0x06000140,
.ext_irq_mask = 0x00003800, /* IRQ7 - IRQ9 */
},
};
^ permalink raw reply
* Re: pci_proc_init: proc_dir_entry '00' already registered
From: Alexey Dobriyan @ 2008-02-10 18:00 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080210100757.GA28322@aepfle.de>
On Sun, Feb 10, 2008 at 11:07:57AM +0100, Olaf Hering wrote:
> Current Linus tree gives this new warning during bootup:
>
> +proc_dir_entry '00' already registered
> +Call Trace:
> +[c00000007b0dfba0] [c00000000000e4b0] .show_stack+0x70/0x1bc (unreliable)
> +[c00000007b0dfc50] [c0000000000f2714] .proc_register+0x130/0x210
> +[c00000007b0dfd00] [c0000000000f299c] .proc_mkdir_mode+0x40/0x70
> +[c00000007b0dfd80] [c000000000276ed8] .pci_proc_attach_device+0xac/0x144
> +[c00000007b0dfe20] [c0000000005bdb3c] .pci_proc_init+0x74/0xac
> +[c00000007b0dfea0] [c0000000005a27ac] .kernel_init+0x1d0/0x394
> +[c00000007b0dff90] [c00000000001e258] .kernel_thread+0x4c/0x68
Can you insert dump_stack() when '00' is registered, not just second
time?
^ permalink raw reply
* pci_proc_init: proc_dir_entry '00' already registered
From: Olaf Hering @ 2008-02-10 10:07 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Current Linus tree gives this new warning during bootup:
+proc_dir_entry '00' already registered
+Call Trace:
+[c00000007b0dfba0] [c00000000000e4b0] .show_stack+0x70/0x1bc (unreliable)
+[c00000007b0dfc50] [c0000000000f2714] .proc_register+0x130/0x210
+[c00000007b0dfd00] [c0000000000f299c] .proc_mkdir_mode+0x40/0x70
+[c00000007b0dfd80] [c000000000276ed8] .pci_proc_attach_device+0xac/0x144
+[c00000007b0dfe20] [c0000000005bdb3c] .pci_proc_init+0x74/0xac
+[c00000007b0dfea0] [c0000000005a27ac] .kernel_init+0x1d0/0x394
+[c00000007b0dff90] [c00000000001e258] .kernel_thread+0x4c/0x68
Its a dualcore G5.
DART table allocated at: c00000007f000000
Using PowerMac machine description
Page orders: linear mapping = 24, virtual = 12, io = 12
Found initrd at 0xc000000001300000:0xc000000001559c00
Found U4 memory controller & host bridge @ 0xf8000000 revision: 0x42
Mapped at 0xd000080080000000
Found a Shasta mac-io controller, rev: 0, mapped at 0xd000080080041000
PowerMac motherboard: PowerMac G5 Dual Core
DART IOMMU initialized for U4 type chipset
console [udbg0] enabled
CPU maps initialized for 1 thread per core
(thread shift is 0)
Starting Linux PPC64 #221 SMP Sun Feb 10 10:50:00 CET 2008
-----------------------------------------------------
ppc64_pft_size = 0x0
physicalMemorySize = 0x80000000
htab_address = 0xc00000007c000000
htab_hash_mask = 0x3ffff
-----------------------------------------------------
Linux version 2.6.24-g5-00000-g25f6663 (olaf@g5) (gcc version 4.1.0 (SUSE Linux)) #221 SMP Sun Feb 10 10:50:00 CET 2008
[boot]0012 Setup Arch
Entering add_active_range(0, 0, 524288) 0 entries of 256 used
Found U4-PCIE PCI host bridge. Firmware bus number: 0->255
PCI host bridge /pci@0,f0000000 ranges:
MEM 0x00000000f1000000..0x00000000f1ffffff -> 0x00000000f1000000
IO 0x00000000f0000000..0x00000000f07fffff -> 0x0000000000000000
MEM 0x0000000090000000..0x00000000afffffff -> 0x0000000090000000
Can't get bus-range for /ht@0,f2000000, assume bus 0
Found U3-HT PCI host bridge. Firmware bus number: 0->239
PCI host bridge /ht@0,f2000000 (primary) ranges:
SMU: Driver 0.7 (c) 2005 Benjamin Herrenschmidt, IBM Corp.
nvram: Checking bank 0...
nvram: gen0=208, gen1=209
nvram: Active bank is: 1
nvram: OF partition at 0x410
nvram: XP partition at 0x1020
nvram: NR partition at 0x1120
Top of RAM: 0x80000000, Total RAM: 0x80000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 524288
Normal 524288 -> 524288
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 524288
On node 0 totalpages: 524288
DMA zone: 7168 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 517120 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
[boot]0015 Setup Done
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 517120
Kernel command line: root=UUID=a77c3a2a-dd4a-4cf6-8c74-287c49897b10 sysrq=1 quiet video=nvidiafb:1024x768@85,bpp:16 panic=12
mpic: Setting up MPIC " MPIC 1 " version 1.2 at f8040000, max 4 CPUs
mpic: ISU size: 124, shift: 7, mask: 7f
mpic: Initializing for 124 sources
mpic: Setting up HT PICs workarounds for U3/U4
mpic: - HT:07.0 [0x90] vendor 106b device 0053 has 86 irqs
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 33.333333 MHz
time_init: processor frequency = 2300.000000 MHz
clocksource: timebase mult[7800001] shift[22] registered
clockevent: decrementer mult[888] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [tty0]
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 2005248k/2097152k available (5984k kernel code, 91208k reserved, 940k data, 489k bss, 216k init)
Calibrating delay loop... 66.56 BogoMIPS (lpj=332800)
Mount-cache hash table entries: 256
device-tree: Duplicate name in /ht@0,f2000000/pci@8/mac-io@7/i2c@18000, renamed to "i2c-bus@0#1"
PowerMac SMP probe found 2 cpus
KeyWest i2c @0xf8001003 irq 16 /u4@0,f8000000/i2c@f8001000
channel 1 bus /u4@0,f8000000/i2c@f8001000/i2c-bus@1
KeyWest i2c @0x80018000 irq 27 /ht@0,f2000000/pci@8/mac-io@7/i2c@18000
channel 0 bus /ht@0,f2000000/pci@8/mac-io@7/i2c@18000/i2c-bus@0
channel 0 bus /ht@0,f2000000/pci@8/mac-io@7/i2c@18000/i2c-bus@0
SMU i2c /smu@0,0/smu-i2c-control@0
channel b bus /smu@0,0/smu-i2c-control@0/i2c-bus@b
channel e bus /smu@0,0/smu-i2c-control@0/i2c-bus@e
Processor timebase sync using platform function
mpic: requesting IPIs ...
Processor 1 found.
clockevent: decrementer mult[888] shift[16] cpu[1]
Brought up 2 CPUs
net_namespace: 304 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
IOMMU table initialized, virtual merging enabled
PCI: Closing bogus Apple Firmware region 2 on bus 0x0a
PCI: Closing bogus Apple Firmware region 2 on bus 0x02
PCI: Closing bogus Apple Firmware region 2 on bus 0x01
PCI: Closing bogus Apple Firmware region 2 on bus 0x03
PCI: Cannot allocate resource region 0 of device 0000:0a:00.0, will remap
PCI: Cannot allocate resource region 1 of device 0000:0a:00.0, will remap
PCI: Cannot allocate resource region 3 of device 0000:0a:00.0, will remap
PCI: Bridge: 0000:00:0b.0
IO window: 0000-ffff
MEM window: 0xa8000000-0xa9ffffff
PREFETCH window: 0x0000000090000000-0x00000000a7ffffff
PCI: Bridge: 0001:00:01.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0001:00:02.0
IO window: disabled.
MEM window: 0xfa500000-0xfa5fffff
PREFETCH window: disabled.
PCI: Bridge: 0001:00:03.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0001:00:04.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0001:00:05.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0001:00:06.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0001:00:07.0
IO window: disabled.
MEM window: 0xfa000000-0xfa3fffff
PREFETCH window: disabled.
PCI: Bridge: 0001:00:08.0
IO window: disabled.
MEM window: 0x80000000-0x800fffff
PREFETCH window: disabled.
PCI: Bridge: 0001:00:09.0
IO window: disabled.
MEM window: 0xfa400000-0xfa4fffff
PREFETCH window: disabled.
PCI: Probing PCI hardware done
Registering pmac pic with sysfs...
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
Time: timebase clocksource has been installed.
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
Unpacking initramfs... done
Freeing initrd memory: 2407k freed
nvram_init: Could not find nvram partition for nvram buffered error logging.
Registering G5 CPU frequency driver
Frequency method: SCOM, Voltage method: GPIO
Low: 1150 Mhz, High: 2300 Mhz, Cur: 2300 MHz
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
SGI XFS with large block/inode numbers, no debug enabled
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
proc_dir_entry '00' already registered
Call Trace:
[c00000007b0dfba0] [c00000000000e4b0] .show_stack+0x70/0x1bc (unreliable)
[c00000007b0dfc50] [c0000000000f2714] .proc_register+0x130/0x210
[c00000007b0dfd00] [c0000000000f299c] .proc_mkdir_mode+0x40/0x70
[c00000007b0dfd80] [c000000000276ed8] .pci_proc_attach_device+0xac/0x144
[c00000007b0dfe20] [c0000000005bdb3c] .pci_proc_init+0x74/0xac
[c00000007b0dfea0] [c0000000005a27ac] .kernel_init+0x1d0/0x394
[c00000007b0dff90] [c00000000001e258] .kernel_thread+0x4c/0x68
nvidiafb: Device ID: 10de0141
nvidiafb: CRTC0 analog found
nvidiafb: CRTC1 analog found
i2c-adapter i2c-0: unable to read EDID block.
i2c-adapter i2c-0: unable to read EDID block.
i2c-adapter i2c-0: unable to read EDID block.
nvidiafb: Found OF EDID for head 1
nvidiafb: EDID found from BUS1
nvidiafb: EDID found from BUS2
nvidiafb: CRTC 0 appears to have a CRT attached
nvidiafb: Using CRT on CRTC 0
Console: switching to colour frame buffer device 128x48
nvidiafb: PCI nVidia NV14 framebuffer (64MB @ 0x90000000)
Generic RTC Driver v1.07
loop: module loaded
tg3.c:v3.87 (December 20, 2007)
eth0: Tigon3 [partno(BCM95780) rev 8003 PHY(5780)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:14:51:68:b7:00
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[76144000] dma_mask[40-bit]
eth1: Tigon3 [partno(BCM95780) rev 8003 PHY(5780)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:14:51:68:b7:01
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[76144000] dma_mask[40-bit]
usbcore: registered new interface driver asix
Linux video capture interface: v2.00
usbcore: registered new interface driver zr364xx
/home/olaf/kernel/linux-2.6/drivers/media/video/zr364xx.c: Zoran 364xx module loaded
MacIO PCI driver attached to Shasta chipset
windfarm: initializing for dual-core desktop G5
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PCI: Enabling device 0001:03:0d.0 (0004 -> 0006)
ide0: Found Apple Shasta ATA-6 controller, bus ID 3, irq 38
Probing IDE interface ide0...
hda: HL-DT-ST DVD-RW GWA-4165B, ATAPI CD/DVD-ROM drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/66 mode selected
ide0 at 0xd0000800822fa000-0xd0000800822fa007,0xd0000800822fa160 on irq 38
hda: ATAPI 32X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.20
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
sata_svw 0001:03:0c.0: version 2.3
scsi0 : sata_svw
scsi1 : sata_svw
scsi2 : sata_svw
scsi3 : sata_svw
ata1: SATA max UDMA/133 mmio m8192@0xfa402000 port 0xfa402000 irq 18
ata2: SATA max UDMA/133 mmio m8192@0xfa402000 port 0xfa402100 irq 18
ata3: SATA max UDMA/133 mmio m8192@0xfa402000 port 0xfa402200 irq 18
ata4: SATA max UDMA/133 mmio m8192@0xfa402000 port 0xfa402300 irq 18
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7: WDC WD2500JS-41MVB1, 10.02E01, max UDMA/133
ata1.00: 488397168 sectors, multi 0: LBA48
ata1.00: configured for UDMA/133
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata2.00: ATA-7: Maxtor 6V250F0, VA111630, max UDMA/133
ata2.00: 490234752 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata2.00: configured for UDMA/133
ata3: SATA link down (SStatus 0 SControl 0)
ata4: SATA link down (SStatus 0 SControl 0)
scsi 0:0:0:0: Direct-Access ATA WDC WD2500JS-41M 10.0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: Direct-Access ATA Maxtor 6V250F0 VA11 PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 490234752 512-byte hardware sectors (251000 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 1:0:0:0: [sdb] 490234752 512-byte hardware sectors (251000 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdb: [mac] sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12
sd 1:0:0:0: [sdb] Attached SCSI disk
sd 1:0:0:0: Attached scsi generic sg1 type 0
PCI: Enabling device 0001:03:0e.0 (0000 -> 0002)
firewire_ohci: Added fw-ohci device 0001:03:0e.0, OHCI version 1.0
video1394: Installed video1394 module
ieee1394: raw1394: /dev/raw1394 device initialized
PCI: Enabling device 0001:01:0b.2 (0004 -> 0006)
ehci_hcd 0001:01:0b.2: EHCI Host Controller
ehci_hcd 0001:01:0b.2: new USB bus registered, assigned bus number 1
ehci_hcd 0001:01:0b.2: irq 70, io mem 0x80080000
ehci_hcd 0001:01:0b.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.24-g5-00000-g25f6663 ehci_hcd
usb usb1: SerialNumber: 0001:01:0b.2
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
PCI: Enabling device 0001:01:0b.0 (0000 -> 0002)
ohci_hcd 0001:01:0b.0: OHCI Host Controller
ohci_hcd 0001:01:0b.0: new USB bus registered, assigned bus number 2
ohci_hcd 0001:01:0b.0: irq 70, io mem 0x80082000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OHCI Host Controller
usb usb2: Manufacturer: Linux 2.6.24-g5-00000-g25f6663 ohci_hcd
usb usb2: SerialNumber: 0001:01:0b.0
PCI: Enabling device 0001:01:0b.1 (0000 -> 0002)
ohci_hcd 0001:01:0b.1: OHCI Host Controller
ohci_hcd 0001:01:0b.1: new USB bus registered, assigned bus number 3
ohci_hcd 0001:01:0b.1: irq 70, io mem 0x80081000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
firewire_core: created new fw device fw0 (0 config rom retries, S800)
firewire_core: phy config: card 0, new root=ffc1, gap_count=5
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: OHCI Host Controller
usb usb3: Manufacturer: Linux 2.6.24-g5-00000-g25f6663 ohci_hcd
usb usb3: SerialNumber: 0001:01:0b.1
usb 2-1: new full speed USB device using ohci_hcd and address 2
usb 2-1: configuration #1 chosen from 2 choices
usb 2-1: New USB device found, idVendor=06cd, idProduct=0110
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1: Product: Keyspan USB Serial Adapter
usb 2-1: Manufacturer: Keyspan, a division of InnoSys Inc.
usb 3-2: new full speed USB device using ohci_hcd and address 2
usb 3-2: configuration #1 chosen from 1 choice
hub 3-2:1.0: USB hub found
hub 3-2:1.0: 3 ports detected
usb 3-2: New USB device found, idVendor=05ac, idProduct=1003
usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-2: Product: Hub in Apple Extended USB Keyboard
usb 3-2: Manufacturer: Mitsumi Electric
usbcore: registered new interface driver usblp
Initializing USB Mass Storage driver...
usb 3-2.1: new low speed USB device using ohci_hcd and address 3
usb 3-2.1: configuration #1 chosen from 1 choice
usb 3-2.1: New USB device found, idVendor=05ac, idProduct=0304
usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-2.1: Product: Apple Optical USB Mouse
usb 3-2.1: Manufacturer: Mitsumi Electric
usb 3-2.3: new full speed USB device using ohci_hcd and address 4
usb 3-2.3: configuration #1 chosen from 1 choice
usb 3-2.3: New USB device found, idVendor=05ac, idProduct=020b
usb 3-2.3: New USB device strings: Mfr=1, Product=3, SerialNumber=0
usb 3-2.3: Product: Apple Extended USB Keyboard
usb 3-2.3: Manufacturer: Mitsumi Electric
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
usbcore: registered new interface driver usbserial
/home/olaf/kernel/linux-2.6/drivers/usb/serial/usb-serial.c: USB Serial Driver core
/home/olaf/kernel/linux-2.6/drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan - (without firmware)
/home/olaf/kernel/linux-2.6/drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan 1 port adapter
/home/olaf/kernel/linux-2.6/drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan 2 port adapter
/home/olaf/kernel/linux-2.6/drivers/usb/serial/usb-serial.c: USB Serial support registered for Keyspan 4 port adapter
keyspan 2-1:1.0: Keyspan 2 port adapter converter detected
usb 2-1: Keyspan 2 port adapter converter now attached to ttyUSB0
usb 2-1: Keyspan 2 port adapter converter now attached to ttyUSB1
usbcore: registered new interface driver keyspan
/home/olaf/kernel/linux-2.6/drivers/usb/serial/keyspan.c: v1.1.5:Keyspan USB to Serial Converter Driver
mice: PS/2 mouse device common for all mice
PowerMac i2c bus smu 14 registered
wf_sat: creating sat at address b0
PowerMac i2c bus smu 11 registered
PowerMac i2c bus mac-io 0 registered
PowerMac i2c bus mac-io 0 registered
found max6690, loc=BACKSIDE addr=0x98
found max6690, loc=TUNNEL addr=0x9c
PowerMac i2c bus u4 1 registered
usbcore: registered new interface driver hiddev
input: Mitsumi Electric Apple Optical USB Mouse as /class/input/input0
input: USB HID v1.10 Mouse [Mitsumi Electric Apple Optical USB Mouse] on usb-0001:01:0b.1-2.1
input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/input1
input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:01:0b.1-2.3
input: Mitsumi Electric Apple Extended USB Keyboard as /class/input/input2
input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:01:0b.1-2.3
usbcore: registered new interface driver usbhid
/home/olaf/kernel/linux-2.6/drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.16rc2 (Thu Jan 31 16:40:16 2008 UTC).
usbcore: registered new interface driver snd-usb-audio
usbcore: registered new interface driver snd-usb-usx2y
snd-aoa-fabric-layout: found bus with layout 68
snd-aoa-fabric-layout: Using PMF GPIOs
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
snd-aoa: fabric didn't like codec onyx
snd-aoa-codec-onyx: found pcm3052
snd-aoa-fabric-layout: can use this codec
snd-aoa-codec-onyx: attached to onyx codec via i2c
snd-aoa-codec-onyx: created and attached onyx instance
ALSA device list:
#0: SoundByLayout
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Freeing unused kernel memory: 216k freed
ioctl32(showconsole:476): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffcd8bb8) on /dev/console
ioctl32(showconsole:479): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffdafbb8) on /dev/console
windfarm: CPUs control loops started.
sat 0 partition c8: c8 6 2 7f ff 2 ff 1 fb bf 0 41 0 20 0 0 0 7 89 37 0 a0 0 0
ioctl32(showconsole:838): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffefbbb8) on /dev/console
sat 0 partition c4: c4 4 1 7f 22 11 e0 e6 ff 55 7b 12 ec 11 0 0
ioctl32(showconsole:870): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffc87b18) on /dev/console
Adding 1048568k swap on /dev/sdb3. Priority:-1 extents:1 across:1048568k
ioctl32(showconsole:897): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffb73aa8) on /dev/console (deleted)
sat 0 partition c9: c9 6 2 7f ff 2 ff 1 fb bf 0 41 0 20 0 0 0 7 89 37 0 a0 0 0
sat 0 partition c5: c5 4 1 7f 22 11 e0 e6 ff 55 7b 12 ec 11 0 0
windfarm: Backside control loop started.
windfarm: Slots control loop started.
windfarm: Drive bay control loop started.
ioctl32(showconsole:1781): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffbf2aa8) on /dev/console (deleted)
XFS mounting filesystem sdb11
Ending clean XFS mount for filesystem: sdb11
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
ioctl32(showconsole:1953): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ff976ab8) on /dev/console (deleted)
ioctl32(showconsole:2058): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffa39af8) on /dev/console
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
ioctl32(showconsole:2641): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(fff16a88) on /dev/tty0
ioctl32(showconsole:3052): Unknown cmd fd(0) cmd(40045432){t:'T';sz:4} arg(ffedaac8) on /dev/tty0
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Sean MacLennan @ 2008-02-10 6:05 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: LinuxPPC-dev
In-Reply-To: <200802100647.56590.arnd@arndb.de>
Arnd Bergmann wrote:
> I guess the cleanest solution would be to include two complete device trees
> for this platform, and then choose the correct one in cuboot-warp.c based
> on the board revision.
>
> The obvious disadvantage of this is that you'd get two device trees
> that you need to keep in sync with every change, so it might not
> be very practical.
>
>
Keeping two device trees would be awkward. My final solution will
probably be to just have
the 4M flash partition layout. Since we really only use the partition
information to write to the partitions from a user mode program, I can
live with having to flash the images from u-boot.
But if we where planning on moving forward with two configurations,
which we where planning to do, this would not be an option. We would
need to auto configure *and* possibly add partitions based on size.
> Maybe we can introduce a more generic way of having conditional
> device nodes in the tree that get knocked out in the boot wrapper.
>
Of even a way to have ifdefs in the dts. In this case, we have to build
a specific version of u-boot for each nor size (WARNING: This may not be
*technically* true, but this is how we are handling it). Having to set a
config and build a specific kernel, while not ideal, would also be a
reasonable solution.
Just throwing out ideas. In the short term this is not a problem, but in
the long term?
Cheers,
Sean
^ permalink raw reply
* Re: Could the DTS experts look at this?
From: Arnd Bergmann @ 2008-02-10 5:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47ACE630.8090101@pikatech.com>
On Saturday 09 February 2008, Sean MacLennan wrote:
> If anybody has suggestions on better ways to do this, fire away.
I guess the cleanest solution would be to include two complete device trees
for this platform, and then choose the correct one in cuboot-warp.c based
on the board revision.
The obvious disadvantage of this is that you'd get two device trees
that you need to keep in sync with every change, so it might not
be very practical.
Maybe we can introduce a more generic way of having conditional
device nodes in the tree that get knocked out in the boot wrapper.
Arnd <><
^ permalink raw reply
* Re: of_iomap and request_mem_region
From: Arnd Bergmann @ 2008-02-10 3:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <9e4733910802091859o3e91b6f6y4b0e6b31f722d8e6@mail.gmail.com>
On Sunday 10 February 2008, Jon Smirl wrote:
> On 2/9/08, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Sunday 10 February 2008, Jon Smirl wrote:
> > > of_iomap doesn't implicitly do a request_mem_region(). How should
> > > request_mem_region() be handled? When using of_iomap you don't get the
> > > length of the region back so it isn't easy to call request_mem_region.
> > >
> > > What about adding a third param to of_iomap for the driver name? If it
> > > is non-null also do the request region. If it is null check to make
> > > sure the region has already be requested.
> >
> > I'd prefer changing of_iomap so that it gets the of_device instead of
> > the device_node. That would help us do two changes at once:
> >
> > 1. call request_mem_region using dev->driver->name, as you mentioned.
> > 2. use managed registrations, as lib/devres.c does e.g. in pcim_iomap,
> > so that we can kill all the calls to iounmap in the cleanup path
> > of OF drivers.
> >
> > maybe we can do a new ofm_iomap interface first, and then move
> > drivers over to use that one.
>
> There are only four drivers using of_iomap.
$ git-ls-files | xargs grep of_iomap | cut -f 1 -d: | uniq | wc -l
19
Unfortunately, many of them don't even use an of_device, so the
conversion is not trivial.
> There are a lot of drivers using of_address_to_resource. They could
> probably be converted to of_iomap if it gets changed. All of the ones
> I checked follow the of_address_to_resource with a request_resource
> call.
Right, but again, we are still in the progress of converting drivers
from using of_find_node_by_type() and similar to of_platform_driver.
If we don't have an of_device, the interface as I would prefer
it doesn't work.
Arnd <><
^ 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