* RE: does Gianfar Ethernet Controller Version 1.1 support MARVELL 88E1111?
From: Guo Jaffe @ 2006-06-09 15:43 UTC (permalink / raw)
To: DaveLiu, afleming; +Cc: Linuxppc-embedded
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673026FD945@zch01exm40.ap.freescale.net>
Hi Dave,
The PHY ID I read is MARVELL 88E1101(1410cc2)
Today I took the MPC 8540 off the board, and checked the two GMII phy chips
alone. I manually pulled up the phys's RST pins when the cable was in
position. But the link LED still can't light up. So it turned out not the
driver's problem.
The hardware configuration of 88E1111 is GMII to copper, Auto-Neg,
advertise all capabilities, prefer Master.
The PHY's power is correct and clean. And for interface between TESC and
PHY I think even TESC power is set for 3.3V environment it still can work
with the 88e1111 whose VDD is 2.5V. Because the datasheet of 88e1111 says
that input pins are 3.3V tolerant. Am I right?
regards,
Jaffe
----------------------------------------------------------------------------
>As you said, the MDIO bus looks like well. If the PHY address it is right,
>You can read the PHY ID from PHY. What is the PHY ID you read?
>
>Please check the hardware status
>
>1) 8540 hardware reset configuration for GMII interface;
>Make sure it is GMII interface.
>
>2) MARVELL 88E1111 configuration and GMII interface connection.
>You can reference the 8540 ref board.
>
>3)TSEC and PHY power
>
>4)The 125M reference clock---GTX_CLK125, This looks
>well as you said.
>
>5)The GTX_CLK for GMII transmit clock, and TX_CLK for MII transmit clock.
>What speed ethernet does the TSEC connect to? 1000Mbps or 100Mbps?
>
>6) The RX_CLK for receive clock.
>
>7)Of cause, need check the RX_DV and TX_EN to see if have some traffic.
>
>-Dave
^ permalink raw reply
* Re: [PATCH 2/10 v2] Add the MPC8641 HPCN platform files.
From: Jon Loeliger @ 2006-06-09 15:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1149826559.12687.41.camel@localhost.localdomain>
So, like, the other day Benjamin Herrenschmidt mumbled:
> On Thu, 2006-06-08 at 16:57 -0500, Jon Loeliger wrote:
>
> > +void
> > +mpc86xx_restart(char *cmd)
> > +{
> > + void __iomem *rstcr;
> > +
> > + local_irq_disable();
> > +
> > + /* Assert reset request to Reset Control Register */
> > + rstcr = ioremap(get_immrbase() + MPC86XX_RSTCR_OFFSET, 0x100);
> > + out_be32(rstcr, 0x2);
> > +
> > + /* not reached */
> > +}
>
> ioremap with irq disabled isn't great.... You should do the ioremap
> once at boot.
OK. Would this be acceptable instead:
mpc86xx_restart(char *cmd)
{
void __iomem *rstcr;
rstcr = ioremap(get_immrbase() + MPC86XX_RSTCR_OFFSET, 0x100);
local_irq_disable();
/* Assert reset request to Reset Control Register */
out_be32(rstcr, 0x2);
/* not reached */
}
> Overall, that file is too small :) Move those into your setup.c and make
> those static...
Will do.
> [SMP code snipped]
>
> This file could/should be called *_smp.c and not need #ifdef's :)
OK.
> Most of the values above should probably be retreived from the
> device-tree.
I'll see what I can remove. Some of the PCI/PCI-e bits
_will_ be device tree derived, but just not quite there yet...
It's just not going to be a perfect first patch; there
will have to be incremental development in that direction.
> As I suggested before, the 2 above should be static in your setup file.
Right.
> > +extern int __init add_bridge(struct device_node *dev);
>
> Aren't we exposing that already via some header ?
Perhaps. I'll look around for it.
> > +extern void __init setup_indirect_pex_nomap(struct pci_controller* hose,
> > + void __iomem * cfg_addr,
> > + void __iomem * cfg_data);
> > +
> > +extern struct smp_ops_t smp_8641_ops;
>
> See my comments about the PCI stuff with the PCI patch.
and...
> All of the above should of course come from the device-tree. 2.6.18 will
> have the support for having interrupt routing from it without having
> nodes for all devices. I'll post it to the list in a week or so, I'm
> coding right now :)
Right. We're not quite entirely able to convert it
all to device tree yet. Working on it still...
> > + phys_addr_t OpenPIC_PAddr;
> > +
> > + /* Determine the Physical Address of the OpenPIC regs */
> > + OpenPIC_PAddr = get_immrbase() + MPC86xx_OPENPIC_OFFSET;
>
> Do you really _need_ studly caps ? I know we did that before but you
> don't have to copy ugly stuff :)
Uh, sorry. No problem.
> In general, you -need- a device node for the interrupt controller. It
> will be made mandatory by the new code.
I know. There is a fully defined node for that in my
device tree already.
> You'll have to provide proper
> interrupt informations in your device-tree (it's easy, really).
It's there.
> If you get that right, it will be very easy to "just work" with my new
> code.
I'll send that to the list too for reference
just to make sure we are in sync here.
> > + /* Alloc mpic structure and per isu has 16 INT entries. */
> > + mpic1 = mpic_alloc(OpenPIC_PAddr,
> > + MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
> > + 16, MPC86xx_OPENPIC_IRQ_OFFSET, 0, 250,
> > + mpc86xx_hpcn_openpic_initsenses,
> > + sizeof(mpc86xx_hpcn_openpic_initsenses),
> > + " MPIC ");
> > + BUG_ON(mpic1 == NULL);
> > +
> > + /* 48 Internal Interrupts */
> > + mpic_assign_isu(mpic1, 0, OpenPIC_PAddr + 0x10200);
> > + mpic_assign_isu(mpic1, 1, OpenPIC_PAddr + 0x10400);
> > + mpic_assign_isu(mpic1, 2, OpenPIC_PAddr + 0x10600);
>
> I haven't looked in detail at your memory map, but do you need separate
> ISUs ? They seem to be quite close together to me... Also, you should
> invent properties in the mpic node for some of those things, like
> big-endian (like apple does) indicating it's a big endian openpic,
> etc... If you manage to get close enough to spec & common usage, you
> might not even need your own init function at all in the future.
OK. We'll work in that direction, but incrementally.
> > + /* 16 External interrupts */
> > + mpic_assign_isu(mpic1, 3, OpenPIC_PAddr + 0x10000);
>
> That looks like you used ISUs in order to "re-order" them... why ?
Heck if I know. We'll have to ask around some here... :-)
> > +#ifdef CONFIG_PEX
> > + mpic_setup_cascade(MPC86xx_IRQ_EXT9, i8259_irq_cascade, NULL);
> > + i8259_init(0, I8259_OFFSET);
> > +#endif
> > +}
>
> Cascade handling is changing with my genirq port. It will be easy to
> adapt though. Same comments howveer, you should have a device-tree node
> for the 8259 (under an ISA bridge, those shall really be in the
> device-tree). In general, on-board bridges should be in the device-tree,
> only slots or standardly routed child PCI devices need not.
Can you send me an example?
>
> All of the above shall be in the device-tree.
Yes, eventually. But not yet... We're working on
this with other folks like Kumar, and Monta Vista,
and other folks.
> > +static void __init
> > +mpc86xx_hpcn_setup_arch(void)
> > +{
> > + struct device_node *np;
> > +
> > +#ifdef CONFIG_SMP
> > + phys_addr_t mcm_paddr;
> > + void *mcm_vaddr = NULL;
> > + unsigned long vaddr;
> > +#endif
> > +
> > + if (ppc_md.progress)
> > + ppc_md.progress("mpc86xx_hpcn_setup_arch()", 0);
> > +
> > + np = of_find_node_by_type(NULL, "cpu");
> > + if (np != 0) {
> > + unsigned int *fp;
> > +
> > + fp = (int *)get_property(np, "clock-frequency", NULL);
> > + if (fp != 0)
> > + loops_per_jiffy = *fp / HZ;
> > + else
> > + loops_per_jiffy = 50000000 / HZ;
> > + of_node_put(np);
> > + }
>
> The above looks dodgy... powerpc uses the timebase frequency for delays
> anyway, lpj will be initialized by the bogomips code, and should but
> unused mostly nowadays anyway.
Uh, you want I should rip it out, boss? :-)
> > +#ifdef CONFIG_PEX
> > + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> > + add_bridge(np);
> > +
> > + ppc_md.pci_swizzle = common_swizzle;
> > + ppc_md.pci_map_irq = mpc86xx_map_irq;
> > + ppc_md.pci_exclude_device = mpc86xx_exclude_device;
> > +#endif
>
> I'm not sure I like this CONFIG_PEX (in general). Just use CONFIG_PCI
> for now all over the place. PCI-E has it's own binding that we don't
> quite respect yet but will do and all of that will be in the
> device-tree. However, as far as the kernel is concerned, this is all
> under CONFIG_PCI.
But I think we are looking for independent PCI/PCI-E options
to be independently configurable still...?
> > +#ifdef CONFIG_SMP
> > + /* Release Core 1 in boot holdoff */
> > + mcm_paddr = get_immrbase() + MPC86xx_MCM_OFFSET;
> > + mcm_vaddr = ioremap(mcm_paddr, MPC86xx_MCM_SIZE);
> > +
> > + vaddr = (unsigned long)mcm_vaddr + MCM_PORT_CONFIG_OFFSET;
> > + out_be32((volatile unsigned *)vaddr, CPU_ALL_RELEASED);
> > + smp_ops = &smp_8641_ops;
> > +#endif
> > +}
>
> Instead of ifdef's, just do a mpc86xx_smp_init() and put it somewhere
> with the other SMP things in the file that contains them (and remove the
> #ifdef's there too, just only build the file if CONFIG_SMP is set).
OK, I catch your drift, but if the file is missing and
there is a hard call to mpc86xx_smp_init() here, how is
that resolved? Is mpc86xx_smp_init #defined empty when
compiled non-SMP then? Like in the header file:
#ifndef CONFIG_SMP
#define mpc86xx_smp_init()
#endif
> > +void
> > +mpc86xx_hpcn_show_cpuinfo(struct seq_file *m)
> > +{
> > + uint pvid, svid, phid1;
> > + uint memsize = total_memory;
> > +
> > + pvid = mfspr(SPRN_PVR);
> > + svid = mfspr(SPRN_SVR);
> >
> > + seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
> > + seq_printf(m, "Machine\t\t: MPC86xx HPCN Board\n");
> > + seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
> > + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
>
> The PVR is probably a duplicate and the SVR should be added to per-cpu
> info instead.
I confess, I am not sure what you mean here. Could you
clarify this a bit for me, or point to an example perhaps?
Thanks for you feedback!
jdl
^ permalink raw reply
* Re: [PATCH 4/10 v2] Guard L3CR references with CPU_FTR_L3CR.
From: Jon Loeliger @ 2006-06-09 16:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1149826679.12687.44.camel@localhost.localdomain>
So, like, the other day Benjamin Herrenschmidt mumbled:
> On Thu, 2006-06-08 at 16:58 -0500, Jon Loeliger wrote:
> > Signed-off-by: Jon Loeliger <jdl@freescale.com>
>
> Beware about this one... the CPU setup code might run before the feature
> fixup in the future...
> ...
> or go read the feature bit directly in the structure
> rather than relying on the fixup mecanism.
OK.
> you should probably do a separate setup function for your core
Truth be told, this is a pretty generic fix for other
parts as well. If I recall correctly, 7447, 7448, 7448A and 7450
as well as the new 8641 now.
But I can certainly introduce a new setup function here
if you think that is the right thing to do. No problem.
Thanks,
jdl
> > --- a/arch/powerpc/kernel/cpu_setup_6xx.S
> > +++ b/arch/powerpc/kernel/cpu_setup_6xx.S
> > +BEGIN_FTR_SECTION
> > mfspr r11,SPRN_L3CR
> > andis. r11,r11,L3CR_L3E@h
> > beq 1f
> > +END_FTR_SECTION_IFSET(CPU_FTR_L3CR)
> > lwz r6,CPU_SPEC_FEATURES(r5)
> > andi. r0,r6,CPU_FTR_L3_DISABLE_NAP
> > beq 1f
^ permalink raw reply
* Re: [PATCH 5/10 v2] Add 8641 CPU and i8259 Setup
From: Jon Loeliger @ 2006-06-09 16:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1149826989.12687.50.camel@localhost.localdomain>
So, like, the other day Benjamin Herrenschmidt mumbled:
>
> [A bunch of SMP issues.]
>
> The above is wrong, it prevents using the same kernel image on another
> platform.
> Same comment above... #ifdef is bad. You are entering from 0x100 with
> address translation not disabled ?
> > + bl clear_bats
> > bl load_up_mmu
>
> Why do you need to call clear_bats here ? load_up_mmu should load BATs.
> If it doesn't handle the high BATs, then fix it :)
> > +#ifdef CONFIG_I8259_LEVEL_TRIGGER
> > + outb(0xfa, 0x4d0); /* level triggered */
> > + outb(0xde, 0x4d1);
> > +#endif
>
> Another change that breaks multiplatform... Can you explain precisely
> what you are trying to acheive here ? If necessary, we can add an
> argument to i8259_init. Or you could do the above in your platform
> code ... though I agree it would be a bit ugly :)
OK. I don't have direct answers in hand for some of
these questions and issues. I'll get with original
authors and see what we can do clean this up!
Thanks!
jdl
^ permalink raw reply
* Re: [PATCH 3/10 v2] Add MPC8641 HPCN PCI and PCI-Express files.
From: Jon Loeliger @ 2006-06-09 16:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1149827596.12687.53.camel@localhost.localdomain>
So, like, the other day Benjamin Herrenschmidt mumbled:
> On Thu, 2006-06-08 at 16:57 -0500, Jon Loeliger wrote:
> > Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
> > Signed-off-by: Wei Zhang <Wei.Zhang@freescale.com>
> > Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
> > Signed-off-by: Jon Loeliger <jdl@freescale.com>
>
> There are various things in this code that duplicate names used by other
> platforms and thus makes the board unsuitable for use in a common
> kernel. That needs to be fixed. Try avoiding too generic names. Also,
> PCI Express shall be named "pcie" and not "pex" :)
>
> I don't have time at the moment to go too deep in the details here.
>
> Ben.
I will also prefix some routines with mpc86xx_ to avoid
the generic names problems. But I'm not sure which other
platforms you expect this one kernel image to run on.
Specifically, this pcie code is very similar to the 8548
family, but not exactly the same.
My understanding is that we are shooting for a single 86xx
family kernel image here, with this 8641 HPCN platform being
the first such port.
I will s/pex/pcie/g and rename files accordingly.
jdl
^ permalink raw reply
* Re: a problem of kernel-module version mismatch.
From: Arnd Bergmann @ 2006-06-09 14:18 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY110-F337711EB19C0B1D8417B18B2880@phx.gbl>
On Friday 09 June 2006 16:07, Ming Liu wrote:
> Are in_le32 and out_le32 two functions defined by the kernel to input and
> output 32-bit data? When we define XIo_In32 and XIo_Out32 as them, which is
> we use out_le32 and in_le32 to input and output data, they are still not
> resolvable. Any other suggestions? Thanks a lot.
They should be defined in include/asm-powerpc/io.h, include <asm/io.h>
to get the definition.
If your kernel is too old, they may not be there however, so you need
to use readl/writel or inl/outl, also defined in that file.
Arnd <><
^ permalink raw reply
* Re: help with inittab
From: Chris Dumoulin @ 2006-06-09 16:14 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060608214239.A71EE35265D@atlas.denx.de>
I've now determined that my kernel seems to stop in the following line
of code, in the function init(void * unused), in init/main.c:
run_init_process("/sbin/init");
I've determined that it stops at this call by stepping through the code
with a BDI2000.
My boot arguments are:
console=ttyS0,57600n8 ip=off root=/dev/ram0 rw
My current inittab is:
::sysinit:/etc/rc.sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
::respawn:/bin/sh
I've tried adding an "echo" command to the /etc/rc.sh script that is
called, but I don't see any output. I've also trying changing the
::sysinit line in inittab to point to some non-existent script, to see
if I'll get some error message, but I still see nothing. Is it possible
that /sbin/init is dying before it gets to the point of reading inittab?
Any ideas?
Regards,
Chris Dumoulin
Wolfgang Denk wrote:
>In message <44888B92.40409@ics-ltd.com> you wrote:
>
>
>>I am using the linux kernel 2.6.15 and initrd ramdisk image from ELDK
>>4.0. Currently, I seem to be able to boot without errors, but after the
>>root filesystem is mounted, things just stop.
>>
>>
>
>And what's your console device? Are you passing any console=
>arguments on the command line? Is the corresponding device entry
>present in the /dev/directory?
>
>Best regards,
>
>Wolfgang Denk
>
>
>
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: [PATCH 5/10 v2] Add 8641 CPU and i8259 Setup
From: Xianghua Xiao @ 2006-06-09 17:16 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1FojUI-0004N5-E7@jdl.com>
Jon Loeliger wrote:
>So, like, the other day Benjamin Herrenschmidt mumbled:
>
>
>>[A bunch of SMP issues.]
>>
>>The above is wrong, it prevents using the same kernel image on another
>>platform.
>>
>>
>
>
>
>>Same comment above... #ifdef is bad. You are entering from 0x100 with
>>address translation not disabled ?
>>
>>
>
>
>
>>>+ bl clear_bats
>>> bl load_up_mmu
>>>
>>>
>>Why do you need to call clear_bats here ? load_up_mmu should load BATs.
>>If it doesn't handle the high BATs, then fix it :)
>>
>>
>
>
>
I will fix this...
>>>+#ifdef CONFIG_I8259_LEVEL_TRIGGER
>>>+ outb(0xfa, 0x4d0); /* level triggered */
>>>+ outb(0xde, 0x4d1);
>>>+#endif
>>>
>>>
>>Another change that breaks multiplatform... Can you explain precisely
>>what you are trying to acheive here ? If necessary, we can add an
>>argument to i8259_init. Or you could do the above in your platform
>>code ... though I agree it would be a bit ugly :)
>>
>>
>
>
>
The above code is a must-have on our 8641D HPCN board to get PCI-Express
ULI1575 southbridge going. The 8259(which is residing inside the
southbridge) is collecting all PCI devices' interrupts( from both inside
the ULI1575 and at its external PCI slots) before it reports to MPIC.
PCI interrupts are level-triggered and shared thus we have to configure
8259 to be level-triggered on this particular board.
>OK. I don't have direct answers in hand for some of
>these questions and issues. I'll get with original
>authors and see what we can do clean this up!
>
>Thanks!
>
>jdl
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [RFC/PATCH] powersave_nap cleanup
From: Nathan Lynch @ 2006-06-09 17:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17545.15326.767523.342562@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Nathan Lynch writes:
>
> > Rename machdep_calls.power_save to machdep_calls.powersave_nap to make
> > more apparent the connection with the powersave_nap sysctl.
>
> Hmmm, it's possibly a bit confusing to have a variable and a function
> with the same name...
Heh, I thought you had suggested doing that, maybe I misunderstood.
So, what to do? Leave the machdep_calls.power_save name as it is?
^ permalink raw reply
* RFC: dma_mmap_coherent() for powerpc/ppc architecture and ALSA?
From: Gerhard Pircher @ 2006-06-09 18:01 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel
Hi,
I'm trying to adapt Linux for the AmigaOne, which is a G3/G4 PPC desktop system with a non cache coherent northbridge (MAI ArticiaS), a VIA82C686B southbridge and the U-boot firmware. Due to the cache coherency problem I compiled in the CONFIG_NOT_COHERENT_CACHE option (arch/ppc/kernel/dma-mapping.c) in the AmigaOne Linux kernel.
While that fixes the DMA data corruption problem, it causes a kernel oops or a complete system lookup after starting sound playback. With kernel versions =<2.6.14 the oops messages refered to a BUG() entry in mm/rmap.c. Therefore I tried out a newer kernel (2.6.16.15), where the oops refers to the ALSA function snd_pcm_mmap_data_nopage() implemented in pcm_native.c.
Well, after searching a while in some old linux kernel threads, I found this thread here:
http://www.thisishull.net/showthread.php?t=22080&page=3&pp=10
Based on the information in this thread, I came to the conclusion that ALSA simply won't work on non cache coherent architectures (except ARM), because the generic DMA API was never expanded to support the functionality required by ALSA (namely mapping dma pages into user space with dma_mmap_coherent()).
This leads me to the question, if there are any plans to include the dma_mmap_coherent() function (for powerpc/ppc and/or any other platform) in one of the next kernel versions and if an adapation of the ALSA drivers is planned. Or is there a simple way (hack) to fix this problem?
Thanks!
Regards,
Gerhard
--
--
-- email : gerhard_pircher -AT- gmx -DOT- net
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
^ permalink raw reply
* Re: help with inittab
From: Steve Iribarne (GMail) @ 2006-06-09 18:23 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <44899E7C.7080903@ics-ltd.com>
On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> I've now determined that my kernel seems to stop in the following line
> of code, in the function init(void * unused), in init/main.c:
> run_init_process("/sbin/init");
Who's init are you using??
Are you using Busyboxes or sysinit from GNU?
> I've determined that it stops at this call by stepping through the code
> with a BDI2000.
>
> My boot arguments are:
> console=ttyS0,57600n8 ip=off root=/dev/ram0 rw
>
> My current inittab is:
> ::sysinit:/etc/rc.sh
> ::ctrlaltdel:/sbin/reboot
> ::shutdown:/sbin/swapoff -a
> ::shutdown:/bin/umount -a -r
> ::restart:/sbin/init
> ::respawn:/bin/sh
>
> I've tried adding an "echo" command to the /etc/rc.sh script that is
> called, but I don't see any output. I've also trying changing the
> ::sysinit line in inittab to point to some non-existent script, to see
> if I'll get some error message, but I still see nothing. Is it possible
> that /sbin/init is dying before it gets to the point of reading inittab?
> Any ideas?
>
> Regards,
> Chris Dumoulin
>
>
> Wolfgang Denk wrote:
>
> >In message <44888B92.40409@ics-ltd.com> you wrote:
> >
> >
> >>I am using the linux kernel 2.6.15 and initrd ramdisk image from ELDK
> >>4.0. Currently, I seem to be able to boot without errors, but after the
> >>root filesystem is mounted, things just stop.
> >>
> >>
> >
> >And what's your console device? Are you passing any console=
> >arguments on the command line? Is the corresponding device entry
> >present in the /dev/directory?
> >
> >Best regards,
> >
> >Wolfgang Denk
> >
> >
> >
>
> --
> *--Christopher Dumoulin--*
> Software Team Leader
>
> <http://ics-ltd.com/>
> <http://ics-ltd.com/>
>
> Interactive Circuits and Systems Ltd.
> 5430 Canotek Road
> Ottawa, ON
> K1J 9G2
> (613)749-9241
> 1-800-267-9794 (USA only)
>
> ------------------------------------------------------------------------
> This e-mail is private and confidential and is for the addressee only.
> If misdirected, please notify us by telephone and confirm that it has
> been deleted from your system and any hard copies destroyed. You are
> strictly prohibited from using, printing, distributing or disseminating
> it or any information contained in it save to the intended recipient.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: help with inittab
From: Chris Dumoulin @ 2006-06-09 19:14 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690606091123q6a31a9d2xf7219de14b94003a@mail.gmail.com>
The init is from Busybox. Since I'm getting output from my serial port
during the kernel boot process, I think it's safe to say that my
/dev/ttyS0 is properly configured. Besides passing the kernel argument
console=ttyS0,57600, is there anything else I need to do to properly
configure the console? I've looked through my kernel configuration to
make sure that any serial device or console related stuff was enabled
and configured.
I'm feeling pretty stumped.
- Chris
Steve Iribarne (GMail) wrote:
> On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>
>> I've now determined that my kernel seems to stop in the following line
>> of code, in the function init(void * unused), in init/main.c:
>> run_init_process("/sbin/init");
>
>
> Who's init are you using??
>
> Are you using Busyboxes or sysinit from GNU?
>
>
>> I've determined that it stops at this call by stepping through the code
>> with a BDI2000.
>>
>> My boot arguments are:
>> console=ttyS0,57600n8 ip=off root=/dev/ram0 rw
>>
>> My current inittab is:
>> ::sysinit:/etc/rc.sh
>> ::ctrlaltdel:/sbin/reboot
>> ::shutdown:/sbin/swapoff -a
>> ::shutdown:/bin/umount -a -r
>> ::restart:/sbin/init
>> ::respawn:/bin/sh
>>
>> I've tried adding an "echo" command to the /etc/rc.sh script that is
>> called, but I don't see any output. I've also trying changing the
>> ::sysinit line in inittab to point to some non-existent script, to see
>> if I'll get some error message, but I still see nothing. Is it possible
>> that /sbin/init is dying before it gets to the point of reading inittab?
>> Any ideas?
>>
>> Regards,
>> Chris Dumoulin
>>
>>
>> Wolfgang Denk wrote:
>>
>> >In message <44888B92.40409@ics-ltd.com> you wrote:
>> >
>> >
>> >>I am using the linux kernel 2.6.15 and initrd ramdisk image from ELDK
>> >>4.0. Currently, I seem to be able to boot without errors, but after
>> the
>> >>root filesystem is mounted, things just stop.
>> >>
>> >>
>> >
>> >And what's your console device? Are you passing any console=
>> >arguments on the command line? Is the corresponding device entry
>> >present in the /dev/directory?
>> >
>> >Best regards,
>> >
>> >Wolfgang Denk
>> >
>> >
>> >
>>
>> --
>> *--Christopher Dumoulin--*
>> Software Team Leader
>>
>> <http://ics-ltd.com/>
>> <http://ics-ltd.com/>
>>
>> Interactive Circuits and Systems Ltd.
>> 5430 Canotek Road
>> Ottawa, ON
>> K1J 9G2
>> (613)749-9241
>> 1-800-267-9794 (USA only)
>>
>> ------------------------------------------------------------------------
>> This e-mail is private and confidential and is for the addressee only.
>> If misdirected, please notify us by telephone and confirm that it has
>> been deleted from your system and any hard copies destroyed. You are
>> strictly prohibited from using, printing, distributing or disseminating
>> it or any information contained in it save to the intended recipient.
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: [PATCH] powerpc: oprofile support for POWER6
From: Sonny Rao @ 2006-06-09 19:03 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060608042915.C568867B1A@ozlabs.org>
On Thu, Jun 08, 2006 at 02:29:01PM +1000, Michael Neuling wrote:
> > > /*
> > > - * SIHV / SIPR bits are only implemented on POWER4+ (GQ) and above.
> > > - * However we disable it on all POWER4 until we verify it works
> > > - * (I was seeing some strange behaviour last time I tried).
> > > - *
> > > - * It has been verified to work on POWER5 so we enable it there.
> > > - */
> >
> > The patched code doesn't handle GQ at all. Is this on purpose? Add a
> > similar comment to the CPU feature tables perhaps?
>
> Yeah, those bits are bust on POWER4+. We didn't touch them previously
> and we still don't with this patch.
>
> You're right, we should keep that comment. I'll update and retransmit.
I'm pretty sure SIHV is busted on GQ for sure
Sonny
^ permalink raw reply
* booting Linux 2.6.15 using a ramdisk and greater than 512MB of DRAM
From: Scott Coulter @ 2006-06-09 19:28 UTC (permalink / raw)
To: linuxppc-embedded
Hi everyone,
I am not sure if this is a linux question or a u-boot question. I have
a custom MPC8540 board running U-boot 1.1.4. With a NFS root
configuration, I have booted and run 2.6.15 with memory from 256MB to
2GB. If I build a ramdisk image (or even if I use the ramdisk image
with the 85xx version of ELDK 4.0) and then combine it with the kernel
image (vmlinux.gz) using "mkimage", the linux boot blows out with an
oops if I boot the board with more that 512MB of DRAM. From the U-boot
output, it looks like the ramdisk image is getting copied to the upper
portion of DRAM. Is it possible that the kernel doesn't map enough DRAM
to allow the image to be read?
I haven't spent a lot of time debugging this once I saw that the 512MB
configuration worked OK. Has anyone run into this?
Thanks,
Scott
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
^ permalink raw reply
* RE: help with inittab
From: Scott Coulter @ 2006-06-09 19:19 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
Chris,
Does your serial output stop after "Freeing unused kernel memory..."
If it does, you may have an interrupt problem with the UART. I had to
track down that very problem the other day. As a test, even if my UART
interrupt was purposely misconfigured, I still saw all of the output up
to and including "Freeing unused kernel memory..."
Scott
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
-----Original Message-----
From: linuxppc-embedded-bounces+scott.coulter=3Dcyclone.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+scott.coulter=3Dcyclone.com@ozlabs.org]=
On Behalf Of Chris Dumoulin
Sent: Friday, June 09, 2006 3:15 PM
To: Steve Iribarne (GMail)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: help with inittab
The init is from Busybox. Since I'm getting output from my serial port=20
during the kernel boot process, I think it's safe to say that my=20
/dev/ttyS0 is properly configured. Besides passing the kernel argument=20
console=3DttyS0,57600, is there anything else I need to do to properly=20
configure the console? I've looked through my kernel configuration to=20
make sure that any serial device or console related stuff was enabled=20
and configured.
I'm feeling pretty stumped.
- Chris
Steve Iribarne (GMail) wrote:
> On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>
>> I've now determined that my kernel seems to stop in the following
line
>> of code, in the function init(void * unused), in init/main.c:
>> run_init_process("/sbin/init");
>
>
> Who's init are you using??
>
> Are you using Busyboxes or sysinit from GNU?
>
>
>> I've determined that it stops at this call by stepping through the
code
>> with a BDI2000.
>>
>> My boot arguments are:
>> console=3DttyS0,57600n8 ip=3Doff root=3D/dev/ram0 rw
>>
>> My current inittab is:
>> ::sysinit:/etc/rc.sh
>> ::ctrlaltdel:/sbin/reboot
>> ::shutdown:/sbin/swapoff -a
>> ::shutdown:/bin/umount -a -r
>> ::restart:/sbin/init
>> ::respawn:/bin/sh
>>
>> I've tried adding an "echo" command to the /etc/rc.sh script that is
>> called, but I don't see any output. I've also trying changing the
>> ::sysinit line in inittab to point to some non-existent script, to
see
>> if I'll get some error message, but I still see nothing. Is it
possible
>> that /sbin/init is dying before it gets to the point of reading
inittab?
>> Any ideas?
>>
>> Regards,
>> Chris Dumoulin
>>
>>
>> Wolfgang Denk wrote:
>>
>> >In message <44888B92.40409@ics-ltd.com> you wrote:
>> >
>> >
>> >>I am using the linux kernel 2.6.15 and initrd ramdisk image from
ELDK
>> >>4.0. Currently, I seem to be able to boot without errors, but after
>> the
>> >>root filesystem is mounted, things just stop.
>> >>
>> >>
>> >
>> >And what's your console device? Are you passing any
console=3D
>> >arguments on the command line? Is the corresponding device
entry
>> >present in the /dev/directory?
>> >
>> >Best regards,
>> >
>> >Wolfgang Denk
>> >
>> >
>> >
>>
>> --=20
>> *--Christopher Dumoulin--*
>> Software Team Leader
>>
>> <http://ics-ltd.com/>
>> <http://ics-ltd.com/>
>>
>> Interactive Circuits and Systems Ltd.
>> 5430 Canotek Road
>> Ottawa, ON
>> K1J 9G2
>> (613)749-9241
>> 1-800-267-9794 (USA only)
>>
>>
------------------------------------------------------------------------
>> This e-mail is private and confidential and is for the addressee
only.
>> If misdirected, please notify us by telephone and confirm that it has
>> been deleted from your system and any hard copies destroyed. You are
>> strictly prohibited from using, printing, distributing or
disseminating
>> it or any information contained in it save to the intended recipient.
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
--=20
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.=20
If misdirected, please notify us by telephone and confirm that it has=20
been deleted from your system and any hard copies destroyed. You are=20
strictly prohibited from using, printing, distributing or disseminating=20
it or any information contained in it save to the intended recipient.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: booting Linux 2.6.15 using a ramdisk and greater than 512MB of DRAM
From: Xianghua Xiao @ 2006-06-09 19:46 UTC (permalink / raw)
To: Scott Coulter, linuxppc-embedded
In-Reply-To: <43EB80E07C42E1408726E4905FB96B0466C6C1@CYBORG3.cyclone.com>
I think it's a u-boot 'feature' and has nothing to do with the kernel.
xianghua
Scott Coulter wrote:
>Xianghua,
>
>That seems to have worked.
>
>Do you think that this is worth investigating?
>
>Thanks,
>
>
>Scott
>
>
>
>
>
>
>___________________________________________________________________
>
> Scott N. Coulter
> Senior Software Engineer
>
> Cyclone Microsystems
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
>___________________________________________________________________
>
>-----Original Message-----
>From: Xianghua Xiao [mailto:x.xiao@freescale.com]
>Sent: Friday, June 09, 2006 3:37 PM
>To: Scott Coulter
>Subject: Re: booting Linux 2.6.15 using a ramdisk and greater than 512MB
>of DRAM
>
>try set initrd_high=0xffffffff under u-boot, see if it helps
>
>Scott Coulter wrote:
>
>
>
>>Hi everyone,
>>
>>I am not sure if this is a linux question or a u-boot question. I have
>>a custom MPC8540 board running U-boot 1.1.4. With a NFS root
>>configuration, I have booted and run 2.6.15 with memory from 256MB to
>>2GB. If I build a ramdisk image (or even if I use the ramdisk image
>>with the 85xx version of ELDK 4.0) and then combine it with the kernel
>>image (vmlinux.gz) using "mkimage", the linux boot blows out with an
>>oops if I boot the board with more that 512MB of DRAM. From the U-boot
>>output, it looks like the ramdisk image is getting copied to the upper
>>portion of DRAM. Is it possible that the kernel doesn't map enough
>>
>>
>DRAM
>
>
>>to allow the image to be read?
>>
>>I haven't spent a lot of time debugging this once I saw that the 512MB
>>configuration worked OK. Has anyone run into this?
>>
>>Thanks,
>>
>>Scott
>>
>>
>>
>>___________________________________________________________________
>>
>> Scott N. Coulter
>> Senior Software Engineer
>>
>> Cyclone Microsystems
>> 370 James Street Phone: 203.786.5536 ext. 118
>> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
>> U.S.A. Web: http://www.cyclone.com
>>___________________________________________________________________
>>
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>>
>>
^ permalink raw reply
* Re: help with inittab
From: Chris Dumoulin @ 2006-06-09 19:49 UTC (permalink / raw)
To: Scott Coulter; +Cc: linuxppc-embedded
In-Reply-To: <43EB80E07C42E1408726E4905FB96B0466C6BF@CYBORG3.cyclone.com>
Hi Scott,
That is where my output stops. What was the cause of your interrupt
problem? Were you able to fix it?
- Chris
Scott Coulter wrote:
>Chris,
>
>Does your serial output stop after "Freeing unused kernel memory..."
>
>If it does, you may have an interrupt problem with the UART. I had to
>track down that very problem the other day. As a test, even if my UART
>interrupt was purposely misconfigured, I still saw all of the output up
>to and including "Freeing unused kernel memory..."
>
>Scott
>
>
>
>
>___________________________________________________________________
>
> Scott N. Coulter
> Senior Software Engineer
>
> Cyclone Microsystems
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
>___________________________________________________________________
>
>-----Original Message-----
>From: linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org
>[mailto:linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org]
>On Behalf Of Chris Dumoulin
>Sent: Friday, June 09, 2006 3:15 PM
>To: Steve Iribarne (GMail)
>Cc: linuxppc-embedded@ozlabs.org
>Subject: Re: help with inittab
>
>The init is from Busybox. Since I'm getting output from my serial port
>during the kernel boot process, I think it's safe to say that my
>/dev/ttyS0 is properly configured. Besides passing the kernel argument
>console=ttyS0,57600, is there anything else I need to do to properly
>configure the console? I've looked through my kernel configuration to
>make sure that any serial device or console related stuff was enabled
>and configured.
>
>I'm feeling pretty stumped.
>
>- Chris
>
>Steve Iribarne (GMail) wrote:
>
>
>
>>On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>>
>>
>>
>>>I've now determined that my kernel seems to stop in the following
>>>
>>>
>line
>
>
>>>of code, in the function init(void * unused), in init/main.c:
>>>run_init_process("/sbin/init");
>>>
>>>
>>Who's init are you using??
>>
>>Are you using Busyboxes or sysinit from GNU?
>>
>>
>>
>>
>>>I've determined that it stops at this call by stepping through the
>>>
>>>
>code
>
>
>>>with a BDI2000.
>>>
>>>My boot arguments are:
>>>console=ttyS0,57600n8 ip=off root=/dev/ram0 rw
>>>
>>>My current inittab is:
>>>::sysinit:/etc/rc.sh
>>>::ctrlaltdel:/sbin/reboot
>>>::shutdown:/sbin/swapoff -a
>>>::shutdown:/bin/umount -a -r
>>>::restart:/sbin/init
>>>::respawn:/bin/sh
>>>
>>>I've tried adding an "echo" command to the /etc/rc.sh script that is
>>>called, but I don't see any output. I've also trying changing the
>>>::sysinit line in inittab to point to some non-existent script, to
>>>
>>>
>see
>
>
>>>if I'll get some error message, but I still see nothing. Is it
>>>
>>>
>possible
>
>
>>>that /sbin/init is dying before it gets to the point of reading
>>>
>>>
>inittab?
>
>
>>>Any ideas?
>>>
>>>Regards,
>>>Chris Dumoulin
>>>
>>>
>>>Wolfgang Denk wrote:
>>>
>>>
>>>
>>>>In message <44888B92.40409@ics-ltd.com> you wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>I am using the linux kernel 2.6.15 and initrd ramdisk image from
>>>>>
>>>>>
>ELDK
>
>
>>>>>4.0. Currently, I seem to be able to boot without errors, but after
>>>>>
>>>>>
>
>
>
>>>the
>>>
>>>
>>>>>root filesystem is mounted, things just stop.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>And what's your console device? Are you passing any
>>>>
>>>>
>console=
>
>
>>>>arguments on the command line? Is the corresponding device
>>>>
>>>>
>entry
>
>
>>>>present in the /dev/directory?
>>>>
>>>>Best regards,
>>>>
>>>>Wolfgang Denk
>>>>
>>>>
>>>>
>>>>
>>>>
>>>--
>>>*--Christopher Dumoulin--*
>>>Software Team Leader
>>>
>>><http://ics-ltd.com/>
>>><http://ics-ltd.com/>
>>>
>>>Interactive Circuits and Systems Ltd.
>>>5430 Canotek Road
>>>Ottawa, ON
>>>K1J 9G2
>>>(613)749-9241
>>>1-800-267-9794 (USA only)
>>>
>>>
>>>
>>>
>------------------------------------------------------------------------
>
>
>>>This e-mail is private and confidential and is for the addressee
>>>
>>>
>only.
>
>
>>>If misdirected, please notify us by telephone and confirm that it has
>>>been deleted from your system and any hard copies destroyed. You are
>>>strictly prohibited from using, printing, distributing or
>>>
>>>
>disseminating
>
>
>>>it or any information contained in it save to the intended recipient.
>>>_______________________________________________
>>>Linuxppc-embedded mailing list
>>>Linuxppc-embedded@ozlabs.org
>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>>>
>
>
>
>
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* RE: help with inittab
From: Scott Coulter @ 2006-06-09 19:53 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
Chris,
I was getting linux 2.6.15 running an MPC8560 board with an external
UART. In my board specific code that was setting up the Programmable
Interrupt Controller (openpic), I had a problem with a loop index and
the external interrupts were not getting setup correctly, but the
internal interrupts were...
Once I fixed the loop, there was output from the init process...
What type of board are you running on? Do you have the UART interrupt
configured correctly (interrupt level high or low, interrupt input
definition, etc.)?
Scott
___________________________________________________________________
Scott N. Coulter
Senior Software Engineer
=20
Cyclone Microsystems =20
370 James Street Phone: 203.786.5536 ext. 118
New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
U.S.A. Web: http://www.cyclone.com
___________________________________________________________________
-----Original Message-----
From: Chris Dumoulin [mailto:cdumoulin@ics-ltd.com]=20
Sent: Friday, June 09, 2006 3:50 PM
To: Scott Coulter
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: help with inittab
Hi Scott,
That is where my output stops. What was the cause of your interrupt=20
problem? Were you able to fix it?
- Chris
Scott Coulter wrote:
>Chris,
>
>Does your serial output stop after "Freeing unused kernel memory..."
>
>If it does, you may have an interrupt problem with the UART. I had to
>track down that very problem the other day. As a test, even if my UART
>interrupt was purposely misconfigured, I still saw all of the output up
>to and including "Freeing unused kernel memory..."
>
>Scott
>
>
>
>
>___________________________________________________________________
>
> Scott N. Coulter
> Senior Software Engineer
> =20
> Cyclone Microsystems =20
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
>___________________________________________________________________
>
>-----Original Message-----
>From: linuxppc-embedded-bounces+scott.coulter=3Dcyclone.com@ozlabs.org
>[mailto:linuxppc-embedded-bounces+scott.coulter=3Dcyclone.com@ozlabs.org=
]
>On Behalf Of Chris Dumoulin
>Sent: Friday, June 09, 2006 3:15 PM
>To: Steve Iribarne (GMail)
>Cc: linuxppc-embedded@ozlabs.org
>Subject: Re: help with inittab
>
>The init is from Busybox. Since I'm getting output from my serial port=20
>during the kernel boot process, I think it's safe to say that my=20
>/dev/ttyS0 is properly configured. Besides passing the kernel argument=20
>console=3DttyS0,57600, is there anything else I need to do to properly=20
>configure the console? I've looked through my kernel configuration to=20
>make sure that any serial device or console related stuff was enabled=20
>and configured.
>
>I'm feeling pretty stumped.
>
>- Chris
>
>Steve Iribarne (GMail) wrote:
>
> =20
>
>>On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>>
>> =20
>>
>>>I've now determined that my kernel seems to stop in the following
>>> =20
>>>
>line
> =20
>
>>>of code, in the function init(void * unused), in init/main.c:
>>>run_init_process("/sbin/init");
>>> =20
>>>
>>Who's init are you using??
>>
>>Are you using Busyboxes or sysinit from GNU?
>>
>>
>> =20
>>
>>>I've determined that it stops at this call by stepping through the
>>> =20
>>>
>code
> =20
>
>>>with a BDI2000.
>>>
>>>My boot arguments are:
>>>console=3DttyS0,57600n8 ip=3Doff root=3D/dev/ram0 rw
>>>
>>>My current inittab is:
>>>::sysinit:/etc/rc.sh
>>>::ctrlaltdel:/sbin/reboot
>>>::shutdown:/sbin/swapoff -a
>>>::shutdown:/bin/umount -a -r
>>>::restart:/sbin/init
>>>::respawn:/bin/sh
>>>
>>>I've tried adding an "echo" command to the /etc/rc.sh script that is
>>>called, but I don't see any output. I've also trying changing the
>>>::sysinit line in inittab to point to some non-existent script, to
>>> =20
>>>
>see
> =20
>
>>>if I'll get some error message, but I still see nothing. Is it
>>> =20
>>>
>possible
> =20
>
>>>that /sbin/init is dying before it gets to the point of reading
>>> =20
>>>
>inittab?
> =20
>
>>>Any ideas?
>>>
>>>Regards,
>>>Chris Dumoulin
>>>
>>>
>>>Wolfgang Denk wrote:
>>>
>>> =20
>>>
>>>>In message <44888B92.40409@ics-ltd.com> you wrote:
>>>>
>>>>
>>>> =20
>>>>
>>>>>I am using the linux kernel 2.6.15 and initrd ramdisk image from
>>>>> =20
>>>>>
>ELDK
> =20
>
>>>>>4.0. Currently, I seem to be able to boot without errors, but after
>>>>> =20
>>>>>
>
> =20
>
>>>the
>>> =20
>>>
>>>>>root filesystem is mounted, things just stop.
>>>>>
>>>>>
>>>>> =20
>>>>>
>>>>And what's your console device? Are you passing any
>>>> =20
>>>>
>console=3D
> =20
>
>>>>arguments on the command line? Is the corresponding device
>>>> =20
>>>>
>entry
> =20
>
>>>>present in the /dev/directory?
>>>>
>>>>Best regards,
>>>>
>>>>Wolfgang Denk
>>>>
>>>>
>>>>
>>>> =20
>>>>
>>>--=20
>>>*--Christopher Dumoulin--*
>>>Software Team Leader
>>>
>>><http://ics-ltd.com/>
>>><http://ics-ltd.com/>
>>>
>>>Interactive Circuits and Systems Ltd.
>>>5430 Canotek Road
>>>Ottawa, ON
>>>K1J 9G2
>>>(613)749-9241
>>>1-800-267-9794 (USA only)
>>>
>>>
>>> =20
>>>
>-----------------------------------------------------------------------
-
> =20
>
>>>This e-mail is private and confidential and is for the addressee
>>> =20
>>>
>only.
> =20
>
>>>If misdirected, please notify us by telephone and confirm that it has
>>>been deleted from your system and any hard copies destroyed. You are
>>>strictly prohibited from using, printing, distributing or
>>> =20
>>>
>disseminating
> =20
>
>>>it or any information contained in it save to the intended recipient.
>>>_______________________________________________
>>>Linuxppc-embedded mailing list
>>>Linuxppc-embedded@ozlabs.org
>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>> =20
>>>
>
>
> =20
>
--=20
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.=20
If misdirected, please notify us by telephone and confirm that it has=20
been deleted from your system and any hard copies destroyed. You are=20
strictly prohibited from using, printing, distributing or disseminating=20
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: help with inittab
From: Steve Iribarne (GMail) @ 2006-06-09 20:24 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <4489C8A9.1080401@ics-ltd.com>
On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> The init is from Busybox. Since I'm getting output from my serial port
> during the kernel boot process, I think it's safe to say that my
> /dev/ttyS0 is properly configured. Besides passing the kernel argument
> console=ttyS0,57600, is there anything else I need to do to properly
> configure the console? I've looked through my kernel configuration to
> make sure that any serial device or console related stuff was enabled
> and configured.
>
> I'm feeling pretty stumped.
>
Ok.. so if you are using the init from Busybox, there should be a
softlink and I can't remember where they put it. I think it is the
root file system. I think they call in linuxrc or something like
that. I'd make sure you have that.
**OR** what I did..
Get sysinit from GNU and tell Busybox not to use the init. I've had
this exact same problem and it was my init.
-stv
> - Chris
>
> Steve Iribarne (GMail) wrote:
>
> > On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> >
> >> I've now determined that my kernel seems to stop in the following line
> >> of code, in the function init(void * unused), in init/main.c:
> >> run_init_process("/sbin/init");
> >
> >
> > Who's init are you using??
> >
> > Are you using Busyboxes or sysinit from GNU?
> >
> >
> >> I've determined that it stops at this call by stepping through the code
> >> with a BDI2000.
> >>
> >> My boot arguments are:
> >> console=ttyS0,57600n8 ip=off root=/dev/ram0 rw
> >>
> >> My current inittab is:
> >> ::sysinit:/etc/rc.sh
> >> ::ctrlaltdel:/sbin/reboot
> >> ::shutdown:/sbin/swapoff -a
> >> ::shutdown:/bin/umount -a -r
> >> ::restart:/sbin/init
> >> ::respawn:/bin/sh
> >>
> >> I've tried adding an "echo" command to the /etc/rc.sh script that is
> >> called, but I don't see any output. I've also trying changing the
> >> ::sysinit line in inittab to point to some non-existent script, to see
> >> if I'll get some error message, but I still see nothing. Is it possible
> >> that /sbin/init is dying before it gets to the point of reading inittab?
> >> Any ideas?
> >>
> >> Regards,
> >> Chris Dumoulin
> >>
> >>
> >> Wolfgang Denk wrote:
> >>
> >> >In message <44888B92.40409@ics-ltd.com> you wrote:
> >> >
> >> >
> >> >>I am using the linux kernel 2.6.15 and initrd ramdisk image from ELDK
> >> >>4.0. Currently, I seem to be able to boot without errors, but after
> >> the
> >> >>root filesystem is mounted, things just stop.
> >> >>
> >> >>
> >> >
> >> >And what's your console device? Are you passing any console=
> >> >arguments on the command line? Is the corresponding device entry
> >> >present in the /dev/directory?
> >> >
> >> >Best regards,
> >> >
> >> >Wolfgang Denk
> >> >
> >> >
> >> >
> >>
> >> --
> >> *--Christopher Dumoulin--*
> >> Software Team Leader
> >>
> >> <http://ics-ltd.com/>
> >> <http://ics-ltd.com/>
> >>
> >> Interactive Circuits and Systems Ltd.
> >> 5430 Canotek Road
> >> Ottawa, ON
> >> K1J 9G2
> >> (613)749-9241
> >> 1-800-267-9794 (USA only)
> >>
> >> ------------------------------------------------------------------------
> >> This e-mail is private and confidential and is for the addressee only.
> >> If misdirected, please notify us by telephone and confirm that it has
> >> been deleted from your system and any hard copies destroyed. You are
> >> strictly prohibited from using, printing, distributing or disseminating
> >> it or any information contained in it save to the intended recipient.
> >> _______________________________________________
> >> Linuxppc-embedded mailing list
> >> Linuxppc-embedded@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >
>
>
> --
> *--Christopher Dumoulin--*
> Software Team Leader
>
> <http://ics-ltd.com/>
> <http://ics-ltd.com/>
>
> Interactive Circuits and Systems Ltd.
> 5430 Canotek Road
> Ottawa, ON
> K1J 9G2
> (613)749-9241
> 1-800-267-9794 (USA only)
>
> ------------------------------------------------------------------------
> This e-mail is private and confidential and is for the addressee only.
> If misdirected, please notify us by telephone and confirm that it has
> been deleted from your system and any hard copies destroyed. You are
> strictly prohibited from using, printing, distributing or disseminating
> it or any information contained in it save to the intended recipient.
>
^ permalink raw reply
* Re: help with inittab
From: Chris Dumoulin @ 2006-06-09 20:43 UTC (permalink / raw)
To: Scott Coulter; +Cc: linuxppc-embedded
In-Reply-To: <43EB80E07C42E1408726E4905FB96B0466C6C5@CYBORG3.cyclone.com>
Scott, you are my saviour. The problem was in fact the IRQ setting. I
changed the IRQ and now I get a shell, prompt, and everything. I never
would have thought to check the UART settings, since I was getting
output during kernel boot-up, I thought everything was good.
Thanks again,
Chris
Scott Coulter wrote:
>Chris,
>
>I was getting linux 2.6.15 running an MPC8560 board with an external
>UART. In my board specific code that was setting up the Programmable
>Interrupt Controller (openpic), I had a problem with a loop index and
>the external interrupts were not getting setup correctly, but the
>internal interrupts were...
>
>Once I fixed the loop, there was output from the init process...
>
>What type of board are you running on? Do you have the UART interrupt
>configured correctly (interrupt level high or low, interrupt input
>definition, etc.)?
>
>
>Scott
>
>
>
>
>
>___________________________________________________________________
>
> Scott N. Coulter
> Senior Software Engineer
>
> Cyclone Microsystems
> 370 James Street Phone: 203.786.5536 ext. 118
> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
> U.S.A. Web: http://www.cyclone.com
>___________________________________________________________________
>
>-----Original Message-----
>From: Chris Dumoulin [mailto:cdumoulin@ics-ltd.com]
>Sent: Friday, June 09, 2006 3:50 PM
>To: Scott Coulter
>Cc: linuxppc-embedded@ozlabs.org
>Subject: Re: help with inittab
>
>Hi Scott,
>That is where my output stops. What was the cause of your interrupt
>problem? Were you able to fix it?
>
>- Chris
>
>Scott Coulter wrote:
>
>
>
>>Chris,
>>
>>Does your serial output stop after "Freeing unused kernel memory..."
>>
>>If it does, you may have an interrupt problem with the UART. I had to
>>track down that very problem the other day. As a test, even if my UART
>>interrupt was purposely misconfigured, I still saw all of the output up
>>to and including "Freeing unused kernel memory..."
>>
>>Scott
>>
>>
>>
>>
>>___________________________________________________________________
>>
>> Scott N. Coulter
>> Senior Software Engineer
>>
>> Cyclone Microsystems
>> 370 James Street Phone: 203.786.5536 ext. 118
>> New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com
>> U.S.A. Web: http://www.cyclone.com
>>___________________________________________________________________
>>
>>-----Original Message-----
>>From: linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org
>>[mailto:linuxppc-embedded-bounces+scott.coulter=cyclone.com@ozlabs.org]
>>On Behalf Of Chris Dumoulin
>>Sent: Friday, June 09, 2006 3:15 PM
>>To: Steve Iribarne (GMail)
>>Cc: linuxppc-embedded@ozlabs.org
>>Subject: Re: help with inittab
>>
>>The init is from Busybox. Since I'm getting output from my serial port
>>during the kernel boot process, I think it's safe to say that my
>>/dev/ttyS0 is properly configured. Besides passing the kernel argument
>>console=ttyS0,57600, is there anything else I need to do to properly
>>configure the console? I've looked through my kernel configuration to
>>make sure that any serial device or console related stuff was enabled
>>and configured.
>>
>>I'm feeling pretty stumped.
>>
>>- Chris
>>
>>Steve Iribarne (GMail) wrote:
>>
>>
>>
>>
>>
>>>On 6/9/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>>>I've now determined that my kernel seems to stop in the following
>>>>
>>>>
>>>>
>>>>
>>line
>>
>>
>>
>>
>>>>of code, in the function init(void * unused), in init/main.c:
>>>>run_init_process("/sbin/init");
>>>>
>>>>
>>>>
>>>>
>>>Who's init are you using??
>>>
>>>Are you using Busyboxes or sysinit from GNU?
>>>
>>>
>>>
>>>
>>>
>>>
>>>>I've determined that it stops at this call by stepping through the
>>>>
>>>>
>>>>
>>>>
>>code
>>
>>
>>
>>
>>>>with a BDI2000.
>>>>
>>>>My boot arguments are:
>>>>console=ttyS0,57600n8 ip=off root=/dev/ram0 rw
>>>>
>>>>My current inittab is:
>>>>::sysinit:/etc/rc.sh
>>>>::ctrlaltdel:/sbin/reboot
>>>>::shutdown:/sbin/swapoff -a
>>>>::shutdown:/bin/umount -a -r
>>>>::restart:/sbin/init
>>>>::respawn:/bin/sh
>>>>
>>>>I've tried adding an "echo" command to the /etc/rc.sh script that is
>>>>called, but I don't see any output. I've also trying changing the
>>>>::sysinit line in inittab to point to some non-existent script, to
>>>>
>>>>
>>>>
>>>>
>>see
>>
>>
>>
>>
>>>>if I'll get some error message, but I still see nothing. Is it
>>>>
>>>>
>>>>
>>>>
>>possible
>>
>>
>>
>>
>>>>that /sbin/init is dying before it gets to the point of reading
>>>>
>>>>
>>>>
>>>>
>>inittab?
>>
>>
>>
>>
>>>>Any ideas?
>>>>
>>>>Regards,
>>>>Chris Dumoulin
>>>>
>>>>
>>>>Wolfgang Denk wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>In message <44888B92.40409@ics-ltd.com> you wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>I am using the linux kernel 2.6.15 and initrd ramdisk image from
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>ELDK
>>
>>
>>
>>
>>>>>>4.0. Currently, I seem to be able to boot without errors, but after
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>>
>>
>>
>>>>the
>>>>
>>>>
>>>>
>>>>
>>>>>>root filesystem is mounted, things just stop.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>And what's your console device? Are you passing any
>>>>>
>>>>>
>>>>>
>>>>>
>>console=
>>
>>
>>
>>
>>>>>arguments on the command line? Is the corresponding device
>>>>>
>>>>>
>>>>>
>>>>>
>>entry
>>
>>
>>
>>
>>>>>present in the /dev/directory?
>>>>>
>>>>>Best regards,
>>>>>
>>>>>Wolfgang Denk
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>*--Christopher Dumoulin--*
>>>>Software Team Leader
>>>>
>>>><http://ics-ltd.com/>
>>>><http://ics-ltd.com/>
>>>>
>>>>Interactive Circuits and Systems Ltd.
>>>>5430 Canotek Road
>>>>Ottawa, ON
>>>>K1J 9G2
>>>>(613)749-9241
>>>>1-800-267-9794 (USA only)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>-----------------------------------------------------------------------
>>
>>
>-
>
>
>>
>>
>>
>>
>>>>This e-mail is private and confidential and is for the addressee
>>>>
>>>>
>>>>
>>>>
>>only.
>>
>>
>>
>>
>>>>If misdirected, please notify us by telephone and confirm that it has
>>>>been deleted from your system and any hard copies destroyed. You are
>>>>strictly prohibited from using, printing, distributing or
>>>>
>>>>
>>>>
>>>>
>>disseminating
>>
>>
>>
>>
>>>>it or any information contained in it save to the intended recipient.
>>>>_______________________________________________
>>>>Linuxppc-embedded mailing list
>>>>Linuxppc-embedded@ozlabs.org
>>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>>
>
>
>
>
--
*--Christopher Dumoulin--*
Software Team Leader
<http://ics-ltd.com/>
<http://ics-ltd.com/>
Interactive Circuits and Systems Ltd.
5430 Canotek Road
Ottawa, ON
K1J 9G2
(613)749-9241
1-800-267-9794 (USA only)
------------------------------------------------------------------------
This e-mail is private and confidential and is for the addressee only.
If misdirected, please notify us by telephone and confirm that it has
been deleted from your system and any hard copies destroyed. You are
strictly prohibited from using, printing, distributing or disseminating
it or any information contained in it save to the intended recipient.
^ permalink raw reply
* Re: [PATCH 2/10 v2] Add the MPC8641 HPCN platform files.
From: Benjamin Herrenschmidt @ 2006-06-09 22:07 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1FojK9-0004AD-DN@jdl.com>
> > Cascade handling is changing with my genirq port. It will be easy to
> > adapt though. Same comments howveer, you should have a device-tree node
> > for the 8259 (under an ISA bridge, those shall really be in the
> > device-tree). In general, on-board bridges should be in the device-tree,
> > only slots or standardly routed child PCI devices need not.
>
> Can you send me an example?
I'll try to dig something. Power3 at least has MPIC<->8259 cascade, as
do some IBM blades when running bare metal kernels.
> > The above looks dodgy... powerpc uses the timebase frequency for delays
> > anyway, lpj will be initialized by the bogomips code, and should but
> > unused mostly nowadays anyway.
>
> Uh, you want I should rip it out, boss? :-)
Well, in any case it's bogus... your loops_per_jiffies is generally not
your processor frequency... I might be close on some CPUs and not on
others (it was double of it on early G4s for example), it may also
depend if things like BTIC are enabled.
I think you may just rip that out. Just check it doesn't break
anything :)
> > > +#ifdef CONFIG_PEX
> > > + for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
> > > + add_bridge(np);
> > > +
> > > + ppc_md.pci_swizzle = common_swizzle;
> > > + ppc_md.pci_map_irq = mpc86xx_map_irq;
> > > + ppc_md.pci_exclude_device = mpc86xx_exclude_device;
> > > +#endif
> >
> > I'm not sure I like this CONFIG_PEX (in general). Just use CONFIG_PCI
> > for now all over the place. PCI-E has it's own binding that we don't
> > quite respect yet but will do and all of that will be in the
> > device-tree. However, as far as the kernel is concerned, this is all
> > under CONFIG_PCI.
>
> But I think we are looking for independent PCI/PCI-E options
> to be independently configurable still...?
Well, if you want to separately configure a given PCI-E bridge, then do
a CONFIG_MPC86xx_PCIE or something like that, but in general, PCI-E
support _is_ the same as PCI support as far as the kernel is concerned.
> > > +#ifdef CONFIG_SMP
> > > + /* Release Core 1 in boot holdoff */
> > > + mcm_paddr = get_immrbase() + MPC86xx_MCM_OFFSET;
> > > + mcm_vaddr = ioremap(mcm_paddr, MPC86xx_MCM_SIZE);
> > > +
> > > + vaddr = (unsigned long)mcm_vaddr + MCM_PORT_CONFIG_OFFSET;
> > > + out_be32((volatile unsigned *)vaddr, CPU_ALL_RELEASED);
> > > + smp_ops = &smp_8641_ops;
> > > +#endif
> > > +}
> >
> > Instead of ifdef's, just do a mpc86xx_smp_init() and put it somewhere
> > with the other SMP things in the file that contains them (and remove the
> > #ifdef's there too, just only build the file if CONFIG_SMP is set).
>
> OK, I catch your drift, but if the file is missing and
> there is a hard call to mpc86xx_smp_init() here, how is
> that resolved? Is mpc86xx_smp_init #defined empty when
> compiled non-SMP then? Like in the header file:
>
> #ifndef CONFIG_SMP
> #define mpc86xx_smp_init()
> #endif
Well, you could keep a #ifdef around the call, or you can define it as a
weak empty function
> > > +void
> > > +mpc86xx_hpcn_show_cpuinfo(struct seq_file *m)
> > > +{
> > > + uint pvid, svid, phid1;
> > > + uint memsize = total_memory;
> > > +
> > > + pvid = mfspr(SPRN_PVR);
> > > + svid = mfspr(SPRN_SVR);
> > >
> > > + seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
> > > + seq_printf(m, "Machine\t\t: MPC86xx HPCN Board\n");
> > > + seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
> > > + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
> >
> > The PVR is probably a duplicate and the SVR should be added to per-cpu
> > info instead.
>
> I confess, I am not sure what you mean here. Could you
> clarify this a bit for me, or point to an example perhaps?
Well, the generic cpuinfo code already displays the PVR for each CPU and
you have a per-cpu hook you can use to display the SVR.
^ permalink raw reply
* Re: [PATCH 4/10 v2] Guard L3CR references with CPU_FTR_L3CR.
From: Benjamin Herrenschmidt @ 2006-06-09 22:07 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1FojPE-0004Aj-0l@jdl.com>
On Fri, 2006-06-09 at 11:00 -0500, Jon Loeliger wrote:
> So, like, the other day Benjamin Herrenschmidt mumbled:
> > On Thu, 2006-06-08 at 16:58 -0500, Jon Loeliger wrote:
> > > Signed-off-by: Jon Loeliger <jdl@freescale.com>
> >
> > Beware about this one... the CPU setup code might run before the feature
> > fixup in the future...
> > ...
> > or go read the feature bit directly in the structure
> > rather than relying on the fixup mecanism.
>
> OK.
>
> > you should probably do a separate setup function for your core
>
> Truth be told, this is a pretty generic fix for other
> parts as well. If I recall correctly, 7447, 7448, 7448A and 7450
> as well as the new 8641 now.
>
> But I can certainly introduce a new setup function here
> if you think that is the right thing to do. No problem.
No, go for the generic fix.
Ben.
^ permalink raw reply
* Re: [PATCH 3/10 v2] Add MPC8641 HPCN PCI and PCI-Express files.
From: Benjamin Herrenschmidt @ 2006-06-09 22:11 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1FojYV-0004O8-L0@jdl.com>
On Fri, 2006-06-09 at 11:09 -0500, Jon Loeliger wrote:
> So, like, the other day Benjamin Herrenschmidt mumbled:
> > On Thu, 2006-06-08 at 16:57 -0500, Jon Loeliger wrote:
> > > Signed-off-by: Xianghua Xiao <x.xiao@freescale.com>
> > > Signed-off-by: Wei Zhang <Wei.Zhang@freescale.com>
> > > Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
> > > Signed-off-by: Jon Loeliger <jdl@freescale.com>
> >
> > There are various things in this code that duplicate names used by other
> > platforms and thus makes the board unsuitable for use in a common
> > kernel. That needs to be fixed. Try avoiding too generic names. Also,
> > PCI Express shall be named "pcie" and not "pex" :)
> >
> > I don't have time at the moment to go too deep in the details here.
> >
> > Ben.
>
> I will also prefix some routines with mpc86xx_ to avoid
> the generic names problems. But I'm not sure which other
> platforms you expect this one kernel image to run on.
> Specifically, this pcie code is very similar to the 8548
> family, but not exactly the same.
It's a policy. On powerpc, MULTIPLATFORM will be the default. One can
build an image that boots a powermac, a pseries and your machines. The
user doesn't _have_ to but the possibility is there. Might be useful in
the long run for embedded distros. It also force us into staying clean
and that's a good thing in general.
> My understanding is that we are shooting for a single 86xx
> family kernel image here, with this 8641 HPCN platform being
> the first such port.
>
> I will s/pex/pcie/g and rename files accordingly.
There is no compelling reason to prevent a true multiplatform kernel
since it's not a different enough CPU (like 4xx or 8xx would be), thus
it shall be in the common config. That's something that we need to fix
about Kumar couple of initial ports to arch/powerpc too.
Ben
^ permalink raw reply
* Re: booting Linux 2.6.15 using a ramdisk and greater than 512MB of DRAM
From: Wolfgang Denk @ 2006-06-09 22:41 UTC (permalink / raw)
To: Scott Coulter; +Cc: linuxppc-embedded
In-Reply-To: <43EB80E07C42E1408726E4905FB96B0466C6C0@CYBORG3.cyclone.com>
Dear Scott,
in message <43EB80E07C42E1408726E4905FB96B0466C6C0@CYBORG3.cyclone.com> you wrote:
>
> I am not sure if this is a linux question or a u-boot question. I have
> a custom MPC8540 board running U-boot 1.1.4. With a NFS root
> configuration, I have booted and run 2.6.15 with memory from 256MB to
> 2GB. If I build a ramdisk image (or even if I use the ramdisk image
> with the 85xx version of ELDK 4.0) and then combine it with the kernel
> image (vmlinux.gz) using "mkimage", the linux boot blows out with an
> oops if I boot the board with more that 512MB of DRAM. From the U-boot
Do you see something like
mem_pieces_remove: [3fe32000,3ff93ec7) not in any region
in your boot messages?
> output, it looks like the ramdisk image is getting copied to the upper
> portion of DRAM. Is it possible that the kernel doesn't map enough DRAM
> to allow the image to be read?
>
> I haven't spent a lot of time debugging this once I saw that the 512MB
> configuration worked OK. Has anyone run into this?
Yes. Normally you can use only use 0x30000000 (768MB) RAM (lowmem);
if you need more you have to change your kernel configuration,
including shifting the kernel start address.
For example, on on a 1 GB system something like this could work:
CONFIG_ADVANCED_OPTIONS=y
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x40000000
CONFIG_KERNEL_START_BOOL=y
CONFIG_KERNEL_START=0xa0000000
# CONFIG_CONSISTENT_START_BOOL is not set
# CONFIG_CONSISTENT_SIZE_BOOL is not set
# CONFIG_BOOT_LOAD_BOOL is not set
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Disobedience: The silver lining to the cloud of servitude.
- Ambrose Bierce
^ permalink raw reply
* Re: pmf_register_irq_client gives sleep with locks held warning
From: Benjamin Herrenschmidt @ 2006-06-10 0:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Morton, linuxppc-dev list
In-Reply-To: <1149793098.11525.34.camel@johannes>
On Thu, 2006-06-08 at 20:58 +0200, Johannes Berg wrote:
> On Thu, 2006-06-01 at 10:59 +1000, Benjamin Herrenschmidt wrote:
>
> > This fixes request_irq() potentially called from atomic context.
> > [...]
>
> Sorry, almost forgot about this.
>
> I don't think your patch is right, it seems to me that now
> pmf_unregister_irq_client races against pmf_do_irq: what happens when an
> interrupt comes in right in the middle of the list_del()?
Yeah, possibly... too late for 2.6.17 tho.
> By the way, what do I do when like this I change a patch? Do I rely on
> your Signed-off-by and simply put mine instead (like I did now)?
You add yours.
> Anyway, here's a changed patch that illustrates my point. I've tested it
> and it works and as expected fixes the problem :)
Too late :)
Cheers,
Ben.
> ---
> This fixes request_irq() being called with interrupts disabled in the
> powermac platform function code when registering the first irq client
> for a given platform function.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>
> --- a/arch/powerpc/platforms/powermac/pfunc_core.c
> +++ b/arch/powerpc/platforms/powermac/pfunc_core.c
> @@ -11,6 +11,7 @@ #include <linux/delay.h>
> #include <linux/kernel.h>
> #include <linux/spinlock.h>
> #include <linux/module.h>
> +#include <linux/mutex.h>
>
> #include <asm/semaphore.h>
> #include <asm/prom.h>
> @@ -546,6 +547,7 @@ struct pmf_device {
>
> static LIST_HEAD(pmf_devices);
> static spinlock_t pmf_lock = SPIN_LOCK_UNLOCKED;
> +static DEFINE_MUTEX(pmf_irq_mutex);
>
> static void pmf_release_device(struct kref *kref)
> {
> @@ -864,16 +866,25 @@ int pmf_register_irq_client(struct devic
>
> spin_lock_irqsave(&pmf_lock, flags);
> func = __pmf_find_function(target, name, PMF_FLAGS_INT_GEN);
> - if (func == NULL) {
> - spin_unlock_irqrestore(&pmf_lock, flags);
> + if (func)
> + func = pmf_get_function(func);
> + spin_unlock_irqrestore(&pmf_lock, flags);
> + if (func == NULL)
> return -ENODEV;
> - }
> +
> + /* guard against manipulations of list */
> + mutex_lock(&pmf_irq_mutex);
> if (list_empty(&func->irq_clients))
> func->dev->handlers->irq_enable(func);
> +
> + /* guard against pmf_do_irq while changing list */
> + spin_lock_irqsave(&pmf_lock, flags);
> list_add(&client->link, &func->irq_clients);
> - client->func = func;
> spin_unlock_irqrestore(&pmf_lock, flags);
>
> + client->func = func;
> + mutex_unlock(&pmf_irq_mutex);
> +
> return 0;
> }
> EXPORT_SYMBOL_GPL(pmf_register_irq_client);
> @@ -885,12 +896,19 @@ void pmf_unregister_irq_client(struct pm
>
> BUG_ON(func == NULL);
>
> - spin_lock_irqsave(&pmf_lock, flags);
> + /* guard against manipulations of list */
> + mutex_lock(&pmf_irq_mutex);
> client->func = NULL;
> +
> + /* guard against pmf_do_irq while changing list */
> + spin_lock_irqsave(&pmf_lock, flags);
> list_del(&client->link);
> + spin_unlock_irqrestore(&pmf_lock, flags);
> +
> if (list_empty(&func->irq_clients))
> func->dev->handlers->irq_disable(func);
> - spin_unlock_irqrestore(&pmf_lock, flags);
> + mutex_unlock(&pmf_irq_mutex);
> + pmf_put_function(func);
> }
> EXPORT_SYMBOL_GPL(pmf_unregister_irq_client);
>
>
^ 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