* Re: [PATCH 46/61] mpc885ads: Rework initialization.
From: Scott Wood @ 2007-07-18 19:31 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070718222455.423ee0ba@localhost.localdomain>
Vitaly Bordug wrote:
>>The conflict is in register space, not pins -- why would the smc1
>>pins matter?
>
> ok, I may have confused this with something else.
Possibly the conflict between FEC2 and SMC2 (which is still done via
kconfig option)?
-Scott
^ permalink raw reply
* Re: PS3 Storage Driver O_DIRECT issue
From: Jens Axboe @ 2007-07-18 17:57 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: James E.J. Bottomley, Olaf Hering, linux-scsi, Alessandro Rubini,
Linux Kernel Development, Linux/PPC Development, Paul Mackerras
In-Reply-To: <Pine.LNX.4.62.0707181808030.15632@pademelon.sonytel.be>
On Wed, Jul 18 2007, Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Olaf Hering wrote:
> > This driver (or the generic PS3 code) has appearently problems with
> > O_DIRECT.
> > glibc aborts parted because the malloc metadata get corrupted. While it
> > is reproducible, the place where it crashes changes with every version
> > of the debug attempt.
> > I dont have a handle right now, all I know is that the metadata after a
> > malloc area get overwritten with zeros.
> >
> >
> > Can you have a look at this?
> > parted /dev/ps3da
> > print (a few times)
>
> I could reproduce it with parted 1.8.0 and later.
>
> The patch below fixes it (tested with 1.8.0, 1.8.2 (FC6), 1.9.0 (git)).
>
> Apparently sometimes bio_cur_sectors(bio)*KERNEL_SECTOR_SIZE != bvec->bv_len
> when using O_DIRECT. Is that true (or a bug?)?
>
> If it's OK, I'll fold this patch into the main ps3disk patch.
The bug is in your code - you iterate the bio segments, but always
reference the current one. Which of course makes no sense, you may as
well just kill the loop in that case, the code would be the same.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 52/61] cpm_uart: Issue STOP_TX command before initializing console.
From: Vitaly Bordug @ 2007-07-18 17:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <469E416E.8040709@freescale.com>
On Wed, 18 Jul 2007 11:35:58 -0500
Scott Wood wrote:
> Vitaly Bordug wrote:
> >>+ cpm_line_cr_cmd(pinfo, CPM_CR_STOP_TX);
> >>+
> >
> >
> > I am recalling exactly the contrary patch that removes stuff to get
> > the non-console UARTs work. Let's better revalidate this once other
> > pieces will be in before applying.
>
> I tried non-console UARTs and had no problem... How would this
> interfere with them? Especially as we're only doing it in the
> console init path...
Bah, what I am recalling has nothing to do with console path so nm.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Machine check exception. 2.6.20 powerpc tree.
From: Kumar Gala @ 2007-07-18 18:17 UTC (permalink / raw)
To: Ramirez-Ortiz, Jorge; +Cc: linuxppc-embedded
In-Reply-To: <35786B99AB3FDC45A8215724617919730136DC04@gbrwgceumf01.eu.xerox.net>
On Jul 18, 2007, at 4:27 AM, Ramirez-Ortiz, Jorge wrote:
> Hi Kumar
>
> The address we are trying to access corresponds to a mapped device in
> the PCI space
> Attached some additional debugging information (we have
> instrumented the
> kernel)
>
> Thanks
> jorge
>
>
> INFO [_probe]: Found Device [irq=58]
> INFO [_open]: device opened with irq 58
> INFO [_read]: waiting for interrupt
> INFO [_intr]: ISR 58
>
> PCI1: Error! ERR_DETECT=00000040, ATTR=00516001, addr=80020034,
> data=00050000
So you are getting a master abort from the target. I think you need
to look at your PCI device and see what's going on there.
> machine_check_exception: task my_process, MCSR=0x10008, NIP=0x10153530
> Machine check in user mode.
> Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx.
> Bus - Read Data Bus Error
>
> Call Trace:
> [C7355EF0] [C0006E64] show_stack+0x48/0x19c (unreliable)
> [C7355F20] [C000C04C] machine_check_exception+0x294/0x484
> [C7355F40] [C000E48C] ret_from_mcheck_exc+0x0/0xe0
>
> cat /proc/cpuinfo
> processor : 0
> cpu : e500v2
> clock : 799.500000MHz
> revision : 2.0 (pvr 8021 0020)
> bogomips : 99.84
> timebase : 49968750
> platform : MPC85xx CDS
> Vendor : Freescale Semiconductor
> Machine : MPC85xx CDS (0xff)
> PVR : 0x80210020
> SVR : 0x80390220
> PLL setting : 0x4
> Memory : 256 MB
> LAW 1 : 00000000, 20000000 -> DDR SDRAM
> LAW 2 : 80000000, 10000000 -> PCI1
> LAW 3 : 90000000, 10000000 -> PCI2
> LAW 4 : a0000000, 10000000 -> PCI Express
> LAW 5 : e1000000, 01000000 -> PCI1
> LAW 6 : e2000000, 01000000 -> PCI2
> LAW 7 : e3000000, 01000000 -> PCI Express
> LAW 8 : f0000000, 10000000 -> Local bus
> DDR 0 : 00000000, 20000000 -> 2/14/10 addr bits
> PCI1 Out_1 : 80000000, 10000000 -> Mem: 80000000
> PCI1 Out_2 : e1000000, 01000000 -> I/O: 00000000
> PCI2 Out_1 : 90000000, 10000000 -> Mem: 90000000
> PCI2 Out_2 : e2000000, 01000000 -> I/O: 00000000
> PCI3 Out_1 : a0000000, 10000000 -> Mem: a0000000
> PCI3 Out_2 : e3000000, 01000000 -> I/O: 00000000
> PCI1 In_1 : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
> 00000000 PF
> PCI2 In_1 : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
> 00000000 PF
> PCI3 In_1 : 00000000, 20000000 (Internal,R:snoop,W:snoop) <-
> 00000000 PF
>
>
> ______________________________
>
>
>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: 17 July 2007 17:29
> To: Ramirez-Ortiz, Jorge
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Machine check exception. 2.6.20 powerpc tree.
>
>
> On Jul 17, 2007, at 9:21 AM, Ramirez-Ortiz, Jorge wrote:
>
>> Running our multithreaded application on ppc8548 (E500 core)
>> generates a machine check exception when trying to access some
>> ASIC's registers mapped on the PCI space (This application maps a
>> PCI device to access its registers)
>>
>>
>>
>> machine_check_exception: task my_process, MCSR=0x10008,
>> NIP=0x10153530
>>
>> Machine check in user mode.
>>
>> Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx.
>>
>> Bus - Read Data Bus Error
>>
>>
>>
>> Here is the assembly dump of the region of code containing the
>> offending instruction in user-space, with SRR0 pointing us at
>> 0x10153530 when the exception is raised:
>>
>>
>>
>> 0x10153528 <_ZN2vk7in_le32EPVKj+16>: lwz r0,8(r31)
>>
>> 0x1015352c <_ZN2vk7in_le32EPVKj+20>: lwz r9,8(r31)
>>
>> 0x10153530 <_ZN2vk7in_le32EPVKj+24>: lwbrx r0,0,r0
>>
>> 0x10153534 <_ZN2vk7in_le32EPVKj+28>: twi 0,r0,0
>>
>> 0x10153538 <_ZN2vk7in_le32EPVKj+32>: isync
>
> Can you get the code to dump the value of r0. I'm wondering if
> you're really getting a read data bus error due to the fact that r0
> is pointing to a PCI address that doesn't have a device that will
> respond.
>
> - k
>
>
^ permalink raw reply
* Re: [PATCH 46/61] mpc885ads: Rework initialization.
From: Vitaly Bordug @ 2007-07-18 18:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <469E4267.2040001@freescale.com>
On Wed, 18 Jul 2007 11:40:07 -0500
Scott Wood wrote:
> Vitaly Bordug wrote:
> >>-#ifdef CONFIG_SERIAL_CPM_SMC1
> >>- clrbits32(bcsr_io, BCSR1_RS232EN_1);
> >>- clrbits32(&cp->cp_simode, 0xe0000000 >> 17); /* brg1
> >>*/
> >>- tmpval8 = in_8(&(cp->cp_smc[0].smc_smcm)) | (SMCM_RX |
> >>SMCM_TX);
> >>- out_8(&(cp->cp_smc[0].smc_smcm), tmpval8);
> >>- clrbits16(&cp->cp_smc[0].smc_smcmr, SMCMR_REN |
> >>SMCMR_TEN); /* brg1 */ -#else
> >>- setbits32(bcsr_io,BCSR1_RS232EN_1);
> >>- out_be16(&cp->cp_smc[0].smc_smcmr, 0);
> >>- out_8(&cp->cp_smc[0].smc_smce, 0);
> >>-#endif
> >
> >
> > these are not just for beauty: if corresponding not-used uart regs
> > are not cleared, second one has a good chances to be hosed.
>
> The CPM reset should take care of that.
>
IIRC we had CPM reset prior, and it didn't help, making all those stuff added.
> >>-void init_scc_ioports(struct fs_platform_info *fpi)
> >>-{
> >>- int scc_no = fs_get_scc_index(fpi->fs_no);
> >>+ /* The SCC3 enet registers overlap the SMC1 registers, so
> >>+ * one of the two must be removed from the device tree.
> >>+ */
> >
> > Unfortunately,
> > this approach has very little chances to work. IIRC, SCC3 eth and
> > SMC1 do have overlapping pins, and just removing it from the tree
> > is not going to save the world because now we have all-in-one early
> > condensed pins setup.
>
> It may not save the world, but it's needed to keep the driver from
> poking at the disabled device.
>
I am not against that, just about that it tends to be not enough.
> > Also, we have to be very careful with corresponding ports shutdown:
> > say turn off smc1 if scc3 is enabled: most prolly it was turned on
> > by the firmware/bootwrapper, and eth won't be alive.
>
> The conflict is in register space, not pins -- why would the smc1
> pins matter?
ok, I may have confused this with something else. Anyway, the only doubt point is
SMC2 console + SCC3 ENET functionality - it is easier to just test that.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 06/61] 8xx: Don't call non-existent Soft_emulate_8xx from SoftwareEmulation.
From: Kumar Gala @ 2007-07-18 18:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <469E3E3F.8050302@freescale.com>
On Jul 18, 2007, at 11:22 AM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Jul 17, 2007, at 8:33 PM, Scott Wood wrote:
>>> On arch/ppc, Soft_emulate_8xx was used when full math emulation was
>>> turned off to emulate a minimal subset of floating point load/store
>>> instructions, to avoid needing a soft-float toolchain. This
>>> function
>>> is called, but not present, on arch/powerpc, causing a build error
>>> if floating point emulation is turned off.
>>>
>>> As soft-float toolchains are now common, I'm deleting the call
>>> rather
>>> than moving Soft_emulate_8xx over to arch/powerpc.
>> We should move the Soft_emulate_8xx code over. I see no reason
>> to break a usage model that existed in arch/ppc.
>
> According to the comment in softemu8xx.c, the only reason for it
> was that "it was easier than trying to get the libraries compiled
> for software floating point." Given that soft-float toolchains are
> easily had now, and that full emulation could be used if one really
> needs to work with hard-float binaries, I don't really see the need
> for this...
>
> If you want to move it over and test it, though, be my guest. :-)
I don't see any reason to break people that might not have updated
their toolchains. There is no reason for us to drop a feature like
this w/o some additional warning.
I think its fine to just move the code over from arch/powerpc and
than in the future we can deal with removing it in a more "proper"
manor.
- k
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Kumar Gala @ 2007-07-18 18:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev@ozlabs.org list, Jon Loeliger
In-Reply-To: <46464F84-5040-4F37-B854-94378C9802AD@kernel.crashing.org>
On Jul 18, 2007, at 11:19 AM, Segher Boessenkool wrote:
>>>> + compatible = "storcenter";
>>>
>>> Needs a manufacturer name in there.
>>
>> Right. Will use:
>> compatible = "iomega,storcenter"
>
> Okido.
>
>>>> + PowerPC,603e { /* Really 8241 */
>>>
>>> So say "PowerPC,8241@0", or "PowerPC,e300@0" (or whatever
>>> the CPU core in there is), or simply "cpu@0", following
>>> the generic naming recommended practice.
>>
>> Well, its the 8241 SoC with a 603e core... (This is
>> the same phrase currently being used on the Kurobox.)
>> I'll use:
>>
>> PowerPC,8241@0 }
>
> That might be best yes.
>
>>>> + soc10x {
>>>
>>> Bad name. Where is the binding for this? I don't think
>>> I saw it before.
>>
>> It's what is being used, again, by the Kurobox. I understand
>> that doesn't make it "right", just precedented by now.
>
> Sure, just trying to trick you into documenting it ;-)
>
>> How about "soc8241@80000000" instead?
>
> soc@ like suggested by Scott seems just fine.
>
>>>> + compatible = "fsl-i2c";
>>>
>>> Needs to be more specific.
>>
>> Hmmm... Not sure what to use here then. There are many
>> existing examples using "fsl-i2c" already. Granted, we've
>> established that they could be wrong... Should this be
>> more like this?:
>>
>> compatible = "fsl,mpc8241-i2c", "fsl-i2c";
>
> That looks good yes. Or if the kernel side code for
> recognising fsl,mpc8241-i2c gets merged in time, you
> can leave out fsl-i2c from your device tree completely.
Hmm, there are really only two fsl,i2c controllers. The one we call
fsl-i2c, and the cpm-i2c controller.
So I'd prefer we don't use fsl,mpc8241-i2c. I'd suggest fsl,ppc-i2c
or something like that.
- k
^ permalink raw reply
* [PATCH] make powerpc pci compile again
From: Johannes Berg @ 2007-07-18 17:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Looks like we got a new declaration in the generic header... This fixes
compile but I don't know whether it's correct.
---
arch/powerpc/kernel/pci-common.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6-git.orig/arch/powerpc/kernel/pci-common.c 2007-07-17 19:11:57.519997066 +0200
+++ linux-2.6-git/arch/powerpc/kernel/pci-common.c 2007-07-17 19:12:14.820997066 +0200
@@ -156,10 +156,12 @@ static DEVICE_ATTR(devspec, S_IRUGO, pci
#endif /* CONFIG_PPC_OF */
/* Add sysfs properties */
-void pcibios_add_platform_entries(struct pci_dev *pdev)
+int pcibios_add_platform_entries(struct pci_dev *pdev)
{
#ifdef CONFIG_PPC_OF
- device_create_file(&pdev->dev, &dev_attr_devspec);
+ return device_create_file(&pdev->dev, &dev_attr_devspec);
+#else
+ return 0;
#endif /* CONFIG_PPC_OF */
}
^ permalink raw reply
* Re: Gdbserver syscall clobber
From: Daniel Jacobowitz @ 2007-07-18 18:31 UTC (permalink / raw)
To: Bill Gatliff; +Cc: gdb, linuxppc-embedded
In-Reply-To: <469E550E.5080905@billgatliff.com>
On Wed, Jul 18, 2007 at 12:59:42PM -0500, Bill Gatliff wrote:
> Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
> lately), but it looks to me like the kernel is setting bit 0 in CR0
> (oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
> (bnslr+) bit 3 a.k.a. SO. Or maybe the other way around, I'm not sure
> after reading Sections 1.2 and 2.1 of the Programming Environments manual.
It's not checking for restart here - userspace isn't supposed to have to.
It's probably checking for error. Check for the bit of kernel code
that's supposed to back you up two instructions.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply
* Re: [PATCH 10/61] bootwrapper: flatdevtree fixes
From: Scott Wood @ 2007-07-18 18:56 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev, Paul Mackerras, David Gibson
In-Reply-To: <9b26986bc99c74c5e17e08191eb07d67@bga.com>
Milton Miller wrote:
> In-Reply-To: <20070718013137.GA15217@ld0162-tx32.am.freescale.net>
>
> On Wed Jul 18 11:33:08 EST 2007, Scott Wood wrote:
>
>> 1. ft_create_node was returning the internal pointer rather than a
>> phandle.
>> 2. ft_find_device_rel was treating lookups relative to root as an error.
>
>
> No, it is treating lookups relative to NULL as an error.
>
> Your patch changes it to treat lookups relative to the NULL phandle as
> relative to root.
Other parts of the code (such as ft_create_node) already do that.
What's wrong with it?
> I've no objections to the other part, can you split these?
No, because change #1 won't work without change #2.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] Fix error checking in Vitesse IRQ config
From: Andy Fleming @ 2007-07-18 18:52 UTC (permalink / raw)
To: pradeep singh; +Cc: netdev, linuxppc-dev
In-Reply-To: <a901b49a0707180000g1c107323ub6c95a6ef3b5b2fe@mail.gmail.com>
On Jul 18, 2007, at 02:00, pradeep singh wrote:
> On 7/18/07, Andy Fleming <afleming@freescale.com> wrote:
>> - if (err)
>> + if (err < 0)
>> return err;
>
> but would that mean, if phy_read returns > 0 it is a success?
Yes. phy_read() returns a 32-bit value. If there's an error, it
returns a negative number. If not, it returns whatever was in the
register (which is only 16 bits)
phy_write() returns 0 on success, and non-zero, otherwise. In
hindsight, it would have been better to be consistent.
Andy
^ permalink raw reply
* Re: Gdbserver syscall clobber
From: Bill Gatliff @ 2007-07-18 17:59 UTC (permalink / raw)
To: gdb, linuxppc-embedded
In-Reply-To: <20070716155348.GA5281@caradoc.them.org>
Daniel Jacobowitz wrote:
> On Mon, Jul 16, 2007 at 10:43:41AM -0500, Bill Gatliff wrote:
>
>> recv(4, 0x7ffffd60, 1, 0) = ? ERESTARTSYS (To be restarted)
>> --- SIGIO (I/O possible) @ 0 (0) ---
>> syscall_4294966784(0xa, 0x7ffffd34, 0x1, 0, 0x1008a3c7, 0x1008b5a3, 0x1008b5a4,
>>
>
> That's -512, a.k.a. the errno value used by syscall restarting. I'd
> say your glibc does not obey the restartable syscall convention used
> by your kernel, and when it tries to restart the syscall the errno
> value is not being replaced by the syscall number. Check the assembly
> for recv.
>
>
Very good catch! Thanks soooo much. Here's the code, from my libc.a:
00000000 <__libc_recv>:
0: 94 21 ff d0 stwu r1,-48(r1)
4: 90 61 00 14 stw r3,20(r1)
8: 90 81 00 18 stw r4,24(r1)
c: 90 a1 00 1c stw r5,28(r1)
10: 90 c1 00 20 stw r6,32(r1)
14: 81 42 00 0c lwz r10,12(r2)
18: 2c 0a 00 00 cmpwi r10,0
1c: 40 82 00 20 bne- 3c <__libc_recv+0x3c>
20: 38 60 00 0a li r3,10
24: 38 81 00 14 addi r4,r1,20
28: 38 00 00 66 li r0,102
2c: 44 00 00 02 sc
30: 38 21 00 30 addi r1,r1,48
34: 4c a3 00 20 bnslr+
38: 48 00 00 00 b 38 <__libc_recv+0x38>
Again, this is 603e on linux-2.4.16 glibc-2.2.5 gcc-2.95.3. (Odd, I
can't seem to find this function in a statically-linked gdbserver, nor
any reference to it in the gdbserver-6.5 source code).
On the kernel side:
_GLOBAL(DoSyscall)
...
blrl /* Call handler */
.globl ret_from_syscall_1
ret_from_syscall_1:
20: stw r3,RESULT(r1) /* Save result */
li r10,-_LAST_ERRNO
cmpl 0,r3,r10
blt 30f
neg r3,r3
cmpi 0,r3,ERESTARTNOHAND
bne 22f
li r3,EINTR
22: lwz r10,_CCR(r1) /* Set SO bit in CR */
oris r10,r10,0x1000
stw r10,_CCR(r1)
30: stw r3,GPR3(r1) /* Update return value */
b ret_from_except
...
ret_from_except:
...
lwz r3,_CCR(r1)
...
mtcrf 0xFF,r3
...
RFI
Now, I'm a little rusty on PPC asm (I've been doing a lot of ARM
lately), but it looks to me like the kernel is setting bit 0 in CR0
(oris r10, r10, 0x1000) a.k.a LT, but the user side is looking at CR0
(bnslr+) bit 3 a.k.a. SO. Or maybe the other way around, I'm not sure
after reading Sections 1.2 and 2.1 of the Programming Environments manual.
Or am I misinterpreting something? I must be, this is well-trodden code
I'm thinking...
The readchar() in gdbserver's remote-utils.c just calls read() on the
file descriptor for the socket. Still trying to track that code down...
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [PATCH 46/61] mpc885ads: Rework initialization.
From: Scott Wood @ 2007-07-18 18:29 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070718222455.423ee0ba@localhost.localdomain>
Vitaly Bordug wrote:
> On Wed, 18 Jul 2007 11:40:07 -0500
> Scott Wood wrote:
>>The CPM reset should take care of that.
>>
>
> IIRC we had CPM reset prior, and it didn't help, making all those stuff added.
You previously only did the CPM reset when CONFIG_UCODE_PATH was
enabled. I saw the same behavior with the smcmr clearing as with the
CPM reset.
> ok, I may have confused this with something else. Anyway, the only doubt point is
> SMC2 console + SCC3 ENET functionality - it is easier to just test that.
I had some difficulty with SCC3, but I think it's unrelated -- the PHY
wasn't negotiating properly. The failure mode was completely different
when SMC1 was left on.
I tried to test it without my patches to see if it worked there, but it
wouldn't boot at all.
-Scott
^ permalink raw reply
* Re: [PATCH 28/61] Add cpm2_set_pin().
From: Scott Wood @ 2007-07-18 18:51 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <44F03DBB-C3D6-4AA1-9960-730F64829EC6@kernel.crashing.org>
Kumar Gala wrote:
> On Jul 17, 2007, at 8:35 PM, Scott Wood wrote:
>> +
>> +struct cpm2_ioports {
>> + u32 dir, par, sor, odr, dat;
>
> __be32?
OK.
>> + u32 res[3];
>> +};
>> +
>> +void cpm2_set_pin(int port, int pin, int flags)
>
>
> Can we make the function take a pointer to the port directly?
I'd rather not -- it'd require the caller to use the immr struct
directly, and either have no type checking, or different functions for
different types of ports (on 8xx).
>> +{
>> + struct cpm2_ioports __iomem *iop =
>> + (struct cpm_ioports __iomem *)&cpm2_immr->im_ioport;
>> +
>> + pin = 1 << (31 - pin);
>> +
>> + if (flags & CPM_PIN_OUTPUT)
>> + setbits32(&iop[port].dir, pin);
>> + else
>> + clrbits32(&iop[port].dir, pin);
>> +
>> + if (!(flags & CPM_PIN_GPIO))
>> + setbits32(&iop[port].par, pin);
>> + else
>> + clrbits32(&iop[port].par, pin);
>> +
>> + if (flags & CPM_PIN_SECONDARY)
>> + setbits32(&iop[port].sor, pin);
>> + else
>> + clrbits32(&iop[port].sor, pin);
>
>
> should we only do this if !(flags & CPM_PIN_GPIO)?
I don't think it matters.
> Any reason we don't also set odr here?
It wasn't clear to me when we need to set it. I can add a flag for it,
though.
-Scott
^ permalink raw reply
* Re: [patch 14/14] Bamboo zImage wrapper
From: Milton Miller @ 2007-07-18 17:21 UTC (permalink / raw)
To: Josh Boyer; +Cc: ppcdev
Sorry for the broken reply but the list is broken.
On Wed Jul 18 04:16:01 EST 2007, Josh Boyer wrote:
> Add a bootwrapper for Bamboo
bamboo is what, an evaluation board? for which processor?
> Signed-off-by: Josh Boyer <jwboyer at linux.vnet.ibm.com>
>
> ---
> arch/powerpc/boot/44x.h | 1
> arch/powerpc/boot/Makefile | 5 -
> arch/powerpc/boot/bamboo.c | 126
> ++++++++++++++++++++++++++++++++++++
> arch/powerpc/boot/dcr.h | 11 +++
> arch/powerpc/boot/treeboot-bamboo.c | 27 +++++++
> 5 files changed, 168 insertions(+), 2 deletions(-)
>
> --- linux-2.6.orig/arch/powerpc/boot/Makefile
> +++ linux-2.6/arch/powerpc/boot/Makefile
> @@ -143,6 +143,7 @@ image-$(CONFIG_PPC_83xx) += cuImage.83x
> image-$(CONFIG_PPC_85xx) += cuImage.85xx
> image-$(CONFIG_EBONY) += treeImage.ebony
> cuImage.ebony
> image-$(CONFIG_WALNUT) += treeImage.walnut
> +image-$(CONFIG_BAMBOO) += treeImage.bamboo
> endif
You are only making one target.
> +
> +static void bamboo_fixups(void)
> +{
> + unsigned long sysclk = 33333333;
> + ibm440ep_fixup_clocks(sysclk, 11059200);
> + ibm4xx_fixup_memsize();
> + ibm4xx_reset_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
> +}
This seems to have board specific information ..
> +
> +void bamboo_init(void)
> +{
> + platform_ops.fixups = bamboo_fixups;
> + platform_ops.exit = ibm44x_dbcr_reset;
> + ft_init(_dtb_start, 0, 32);
> + serial_console_init();
> +}
and so is this (by transitivity).
> --- /dev/null
> +++ linux-2.6/arch/powerpc/boot/treeboot-bamboo.c
> @@ -0,0 +1,27 @@
... [copyright header]
> +#include "ops.h"
> +#include "stdio.h"
> +#include "44x.h"
> +
> +extern char _end[];
> +
> +BSS_STACK(4096);
> +
> +void platform_init(void)
> +{
> + unsigned long end_of_ram = 0x8000000;
> + unsigned long avail_ram = end_of_ram - (unsigned long)_end;
> +
> + simple_alloc_init(_end, avail_ram, 32, 64);
> + bamboo_init();
> +}
Is there some reason they should not all be merged into this one
platform file?
I can understand wanting the dcr fixups as a library, but lets wait to
do the file splits until there are actually users. Its also easier to
see what's going to called when all the platform ops are filled in at
one spot, not spread over multiple files.
milton
^ permalink raw reply
* Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
From: Eugene Surovegin @ 2007-07-18 17:04 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, bart.vanassche, linux-mm,
bugme-daemon@kernel-bugs.osdl.org, linuxppc-embedded,
Christoph Lameter
In-Reply-To: <20070718095537.d344dc0a.akpm@linux-foundation.org>
On Wed, Jul 18, 2007 at 09:55:37AM -0700, Andrew Morton wrote:
> On Wed, 18 Jul 2007 08:59:40 -0700 Eugene Surovegin <ebs@ebshome.net> wrote:
>
> > On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote:
> > > On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote:
> > > > On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
> > > > > On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
> > > > >
> > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8778
> > > > > >
> > > > > > Summary: Ocotea board: kernel reports access of bad area during
> > > > > > boot with DEBUG_SLAB=y
> > > >
> > > > Slab debugging is probably the culprit here. I had similar problem
> > > > couple of years ago, not sure something has changed since then,
> > > > haven't checked.
> > > >
> > > > When slab debugging was enabled it made memory allocations non L1
> > > > cache line aligned. This is very bad for DMA on non-coherent cache
> > > > arches (PPC440 is one of those archs).
> > > >
> > > > I have a hack for EMAC which tries to "workaround" this problem:
> > > > http://kernel.ebshome.net/emac_slab_debug.diff
> > > > which might help.
> > >
> > > Would you be opposed to including that patch in mainline?
> >
> > Yes. I don't think it's the right way to fix this issue. IMO, the
> > right one is to fix slab allocator. You cannot change all drivers to
> > do this kind of cache flushing, and yes, I saw the same problem with
> > PCI based NIC I tried on Ocotea at the time.
> >
>
> hm. It should be the case that providing SLAB_HWCACHE_ALIGN at
> kmem_cache_create() time will override slab-debugging's offsetting
> of the returned addresses.
>
> Or is the problem occurring with memory which is returned from kmalloc(),
> rather than from kmem_cache_alloc()?
It's kmalloc, at least this is how I think skbs are allocated.
Andrew, I don't have access to PPC hw right now (doing MIPS
development these days), so I cannot quickly check that my theory is
still correct for the latest kernel. I'd wait for the reporter to try
my hack and then we can decide what to do. IIRC there was some
provision in slab allocator to enforce alignment, when I was debugging
this problem more then a year ago, that option didn't work.
BTW, I think slob allocator had the same issue with alignment as slab
with enabled debugging (at least at the time I looked at it).
--
Eugene
^ permalink raw reply
* Re: [patch 14/14] Bamboo zImage wrapper
From: Josh Boyer @ 2007-07-18 17:51 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <6e26faa3f30dddc5fcf6294a1ecb3a78@bga.com>
On Wed, 2007-07-18 at 12:21 -0500, Milton Miller wrote:
> Sorry for the broken reply but the list is broken.
>
> On Wed Jul 18 04:16:01 EST 2007, Josh Boyer wrote:
> > Add a bootwrapper for Bamboo
>
> bamboo is what, an evaluation board? for which processor?
Yes, 440EP.
> > --- linux-2.6.orig/arch/powerpc/boot/Makefile
> > +++ linux-2.6/arch/powerpc/boot/Makefile
> > @@ -143,6 +143,7 @@ image-$(CONFIG_PPC_83xx) += cuImage.83x
> > image-$(CONFIG_PPC_85xx) += cuImage.85xx
> > image-$(CONFIG_EBONY) += treeImage.ebony
> > cuImage.ebony
> > image-$(CONFIG_WALNUT) += treeImage.walnut
> > +image-$(CONFIG_BAMBOO) += treeImage.bamboo
> > endif
>
> You are only making one target.
Yes... why is that a problem?
> > +static void bamboo_fixups(void)
> > +{
> > + unsigned long sysclk = 33333333;
> > + ibm440ep_fixup_clocks(sysclk, 11059200);
> > + ibm4xx_fixup_memsize();
> > + ibm4xx_reset_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
> > +}
>
> This seems to have board specific information ..
I should hope so... it's a wrapper for the bamboo board.
> > --- /dev/null
> > +++ linux-2.6/arch/powerpc/boot/treeboot-bamboo.c
> > @@ -0,0 +1,27 @@
> ... [copyright header]
> > +#include "ops.h"
> > +#include "stdio.h"
> > +#include "44x.h"
> > +
> > +extern char _end[];
> > +
> > +BSS_STACK(4096);
> > +
> > +void platform_init(void)
> > +{
> > + unsigned long end_of_ram = 0x8000000;
> > + unsigned long avail_ram = end_of_ram - (unsigned long)_end;
> > +
> > + simple_alloc_init(_end, avail_ram, 32, 64);
> > + bamboo_init();
> > +}
>
> Is there some reason they should not all be merged into this one
> platform file?
"they" meaning what?
> I can understand wanting the dcr fixups as a library, but lets wait to
> do the file splits until there are actually users. Its also easier to
> see what's going to called when all the platform ops are filled in at
> one spot, not spread over multiple files.
I copied this from Ebony. There are multiple users already. You have
two parts. The truly common stuff in 4xx.c and the board specific
wrappers that do the things needed for the board.
You've thoroughly confused me.
josh
^ permalink raw reply
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Linas Vepstas @ 2007-07-18 18:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <E1IAvmA-00062M-F4@jdl.com>
On Tue, Jul 17, 2007 at 05:44:14PM -0500, Jon Loeliger wrote:
> <Top Posting Carnac>
>
> A: They haven't been posted yet.
>
> Q: How do we know Segher has new patches?
>
> </Top Posting Carnac>
rotfl -- rolling on the floor loeliger !
^ permalink raw reply
* Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
From: Bart Van Assche @ 2007-07-18 18:43 UTC (permalink / raw)
To: Eugene Surovegin
Cc: netdev, linux-mm, bugme-daemon@kernel-bugs.osdl.org,
linuxppc-embedded, Andrew Morton, Christoph Lameter
In-Reply-To: <20070718170433.GC29722@gate.ebshome.net>
[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]
On 7/18/07, Eugene Surovegin <ebs@ebshome.net> wrote:
>
>
> It's kmalloc, at least this is how I think skbs are allocated.
>
> Andrew, I don't have access to PPC hw right now (doing MIPS
> development these days), so I cannot quickly check that my theory is
> still correct for the latest kernel. I'd wait for the reporter to try
> my hack and then we can decide what to do. IIRC there was some
> provision in slab allocator to enforce alignment, when I was debugging
> this problem more then a year ago, that option didn't work.
>
> BTW, I think slob allocator had the same issue with alignment as slab
> with enabled debugging (at least at the time I looked at it).
Hello Eugene,
In case you didn't notice yet, I have added the following comment to the
kernel bugzilla item:
------- *Comment #5
<http://bugzilla.kernel.org/show_bug.cgi?id=8778#c5>From Bart
Van Assche <bart.vanassche@gmail.com> 2007-07-18 07:12:49 *
[reply<http://bugzilla.kernel.org/show_bug.cgi?id=8778#add_comment>]
-------
I have downloaded the patch from
http://kernel.ebshome.net/emac_slab_debug.diff, and I have tried it. Hereby I
confirm that this patch solves the reported kernel oops.
--
Regards,
Bart Van Assche.
[-- Attachment #2: Type: text/html, Size: 1884 bytes --]
^ permalink raw reply
* Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
From: Andrew Morton @ 2007-07-18 16:55 UTC (permalink / raw)
To: Eugene Surovegin, linux-mm, Christoph Lameter
Cc: bart.vanassche, netdev, bugme-daemon@kernel-bugs.osdl.org,
linuxppc-embedded
In-Reply-To: <20070718155940.GB29722@gate.ebshome.net>
On Wed, 18 Jul 2007 08:59:40 -0700 Eugene Surovegin <ebs@ebshome.net> wrote:
> On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote:
> > On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote:
> > > On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote:
> > > > On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
> > > >
> > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8778
> > > > >
> > > > > Summary: Ocotea board: kernel reports access of bad area during
> > > > > boot with DEBUG_SLAB=y
> > >
> > > Slab debugging is probably the culprit here. I had similar problem
> > > couple of years ago, not sure something has changed since then,
> > > haven't checked.
> > >
> > > When slab debugging was enabled it made memory allocations non L1
> > > cache line aligned. This is very bad for DMA on non-coherent cache
> > > arches (PPC440 is one of those archs).
> > >
> > > I have a hack for EMAC which tries to "workaround" this problem:
> > > http://kernel.ebshome.net/emac_slab_debug.diff
> > > which might help.
> >
> > Would you be opposed to including that patch in mainline?
>
> Yes. I don't think it's the right way to fix this issue. IMO, the
> right one is to fix slab allocator. You cannot change all drivers to
> do this kind of cache flushing, and yes, I saw the same problem with
> PCI based NIC I tried on Ocotea at the time.
>
hm. It should be the case that providing SLAB_HWCACHE_ALIGN at
kmem_cache_create() time will override slab-debugging's offsetting
of the returned addresses.
Or is the problem occurring with memory which is returned from kmalloc(),
rather than from kmem_cache_alloc()?
A complete description of the problem would help here, please.
^ permalink raw reply
* Re: [PATCH 09/61] bootwrapper: Add dt_is_compatible().
From: Scott Wood @ 2007-07-18 18:24 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev, Paul Mackerras, David Gibson
In-Reply-To: <c5856df6a88b8124fbb6a3cc6974314c@bga.com>
Milton Miller wrote:
>> + for (pos = 0; pos + compat_len < len; pos++) {
>> + if (!strcmp(buf + pos, compat))
>> + return 1;
>> +
>> + while (buf[pos] && pos + compat_len < len)
>> + pos++;
>
>
> This is buggy: if you are searching for "ns16550" and the compatable is
> "fsl,1234\0commons16550" this code will incorrectly says its compatable.
How so?
The first iteration will compare "ns16550" to "fsl,1234", find that they
don't match, and advance to the '\0'.
The second iteration will compare "ns16550" to "commons16550", find that
they don't match, and advance to the 'n'.
The third iteration will not happen, since the loop condition fails, and
not-compatible is returned.
> Comparing pos < len instead will do the right thing, at the cost of a
> few iterations of the loop.
I'll grant that the extra iterations aren't worth doing the strlen() --
I'm not sure why I did it that way.
-Scott
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Scott Wood @ 2007-07-18 16:47 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Yoder Stuart-B08248, linuxppc-dev
In-Reply-To: <A86AB8AE-E421-457B-ABE8-9AD93CCFCDC8@kernel.crashing.org>
Segher Boessenkool wrote:
> Yes indeed. The problem with your suggested "obvious way"
I said it was obvious, not obviously correct. :-)
> is that you wouldn't get a unit address included if your
> interrupt-map points (for some entry) at your device tree
> parent, either. Not all that hypothetical.
Ah, good point. My inclination would be to, rather than check how we
got to the node, check whether it's the device's parent. If not, then
the presence of #address-cells (other than zero for compatibility) is an
error. Otherwise, #address-cells is used, and defaults are handled the
same as with reg/ranges translation.
-Scott
^ permalink raw reply
* Re: [PATCH 38/61] cpm2: Update device trees.
From: Scott Wood @ 2007-07-18 16:42 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070718162240.557eea46@localhost.localdomain>
Vitaly Bordug wrote:
> On Tue, 17 Jul 2007 20:35:50 -0500
> Scott Wood wrote:
>
>
>>+ "fsl,cpm-uart";
>> reg = <11a00 20 8000 100>;
>>- current-speed = <1c200>;
>
> Hmm, how is it supposed to work without speed? I was testing my u-boot OF bindings for 82xx and spotted into it.
The same way all the other device trees without current-speed work --
one passes console=whatever on the command line.
Feel free to have u-boot add the actual current speed (rather than a
hardcoded default speed) if you want, though.
-Scott
^ permalink raw reply
* Re: [PATCH 46/61] mpc885ads: Rework initialization.
From: Scott Wood @ 2007-07-18 16:40 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070718124402.18197206@localhost.localdomain>
Vitaly Bordug wrote:
>>-#ifdef CONFIG_SERIAL_CPM_SMC1
>>- clrbits32(bcsr_io, BCSR1_RS232EN_1);
>>- clrbits32(&cp->cp_simode, 0xe0000000 >> 17); /* brg1
>>*/
>>- tmpval8 = in_8(&(cp->cp_smc[0].smc_smcm)) | (SMCM_RX |
>>SMCM_TX);
>>- out_8(&(cp->cp_smc[0].smc_smcm), tmpval8);
>>- clrbits16(&cp->cp_smc[0].smc_smcmr, SMCMR_REN |
>>SMCMR_TEN); /* brg1 */ -#else
>>- setbits32(bcsr_io,BCSR1_RS232EN_1);
>>- out_be16(&cp->cp_smc[0].smc_smcmr, 0);
>>- out_8(&cp->cp_smc[0].smc_smce, 0);
>>-#endif
>
>
> these are not just for beauty: if corresponding not-used uart regs are not cleared, second one has a
> good chances to be hosed.
The CPM reset should take care of that.
>>-void init_scc_ioports(struct fs_platform_info *fpi)
>>-{
>>- int scc_no = fs_get_scc_index(fpi->fs_no);
>>+ /* The SCC3 enet registers overlap the SMC1 registers, so
>>+ * one of the two must be removed from the device tree.
>>+ */
>
> Unfortunately,
> this approach has very little chances to work. IIRC, SCC3 eth and SMC1 do have overlapping pins,
> and just removing it from the tree is not going to save the world because now we have all-in-one early condensed
> pins setup.
It may not save the world, but it's needed to keep the driver from
poking at the disabled device.
> Also, we have to be very careful with corresponding ports shutdown: say turn off smc1 if scc3 is enabled: most prolly
> it was turned on by the firmware/bootwrapper, and eth won't be alive.
The conflict is in register space, not pins -- why would the smc1 pins
matter?
-Scott
^ permalink raw reply
* Re: [PATCH 52/61] cpm_uart: Issue STOP_TX command before initializing console.
From: Scott Wood @ 2007-07-18 16:35 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20070718120022.1b007937@localhost.localdomain>
Vitaly Bordug wrote:
>>+ cpm_line_cr_cmd(pinfo, CPM_CR_STOP_TX);
>>+
>
>
> I am recalling exactly the contrary patch that removes stuff to get the non-console UARTs work.
> Let's better revalidate this once other pieces will be in before applying.
I tried non-console UARTs and had no problem... How would this
interfere with them? Especially as we're only doing it in the console
init path...
-Scott
^ 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