* Re: [PATCH 2/9] bootwrapper: Add strtoull().
From: Milton Miller @ 2007-08-30 15:52 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev
In-Reply-To: <20070829164638.GA31640@ld0162-tx32.am.freescale.net>
On Thu Aug 30 02:46:38 EST 2007, Scott Wood wrote:
> + if (*ptr >= '0' && *ptr <= '9' && *ptr < '0' + base)
> + digit = *ptr - '0';
> + else if (*ptr >= 'A' && *ptr < 'A' + base - 10)
> + digit = *ptr - 'A' + 10;
> + else if (*ptr >= 'a' && *ptr < 'z' + base - 10)
> + digit = *ptr - 'a' + 10;
> + else
> + break;
'z' should also be 'a' like the 'A' case.
Should we add <= 'Z' like we do '9', or do we not care about bases >
36? (It really breaks above base 42).
milton
^ permalink raw reply
* Re: [PATCH 2/9] bootwrapper: Add strtoull().
From: Scott Wood @ 2007-08-30 16:16 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <ab107db1fd4d7e9bc3b461b7f4157100@bga.com>
On Thu, Aug 30, 2007 at 10:52:22AM -0500, Milton Miller wrote:
> On Thu Aug 30 02:46:38 EST 2007, Scott Wood wrote:
>
> >+ if (*ptr >= '0' && *ptr <= '9' && *ptr < '0' + base)
> >+ digit = *ptr - '0';
> >+ else if (*ptr >= 'A' && *ptr < 'A' + base - 10)
> >+ digit = *ptr - 'A' + 10;
> >+ else if (*ptr >= 'a' && *ptr < 'z' + base - 10)
> >+ digit = *ptr - 'a' + 10;
> >+ else
> >+ break;
>
> 'z' should also be 'a' like the 'A' case.
Oops.
> Should we add <= 'Z' like we do '9', or do we not care about bases >
> 36? (It really breaks above base 42).
I personally don't care about bases > 16; I only supported up to 36
because it was easy to do so.
-Scott
^ permalink raw reply
* RE: Xilinx Virtex boot (And MPMC)
From: Stephen Neuendorffer @ 2007-08-30 16:07 UTC (permalink / raw)
To: Robert Woodworth, Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <1188485072.8717.42.camel@PisteOff>
The MPMC would almost certainly be a better option here...
Steve
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
labs.org] On Behalf Of Robert Woodworth
> Sent: Thursday, August 30, 2007 7:45 AM
> To: Grant Likely
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Xilinx Virtex boot
>=20
> On Wed, 2007-08-29 at 18:29 -0600, Grant Likely wrote:
> > On 8/29/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> > > I'm trying to port Linux to a new Virtex Platform. The=20
> kernel will not
> > > uncompress, I get the following on the console:
> > >
> > > loaded at: 00400000 004FB19C
> > > board data at: 004F9120 004F919C
> > > relocated to: 00404054 004040D0
> > > zimage at: 00404E50 004F8409
> > > avail ram: 004FC000 04000000
> > >
> > > Linux/PPC load: console=3DttyUL root=3D/dev/xsa2
> > > Uncompressing Linux...
> > > zlib_inflateInit2 returned 00506530
> > > exit
> > >
> > > Any ideas what causes this error??
> > > Is something mis-configured on my EDK project?
> > >
> >=20
> > Possibly, do you know that EDK has your ram is configured correctly
> > (ie. have you run a memory test application)?
>=20
> Yes, I ran the sample memory test application that EDK builds
> automatically. It ran fine.
>=20
> The fact that the above prints on the console, tells me that the
> zImage.elf is getting loaded at the correct start location=20
> and that its
> partly executing.
>=20
> What is the return code that I'm seeing?? I have been unable=20
> to figure
> that out from the source yet.
>=20
>=20
> > >
> > > I have 64MB DDR on the OPB *not* the PLB.
> > > Is that a problem??
> >=20
> > It shouldn't be the problem, but why are you doing that?
>=20
> We are building an image-processing application inside the FPGA. The
> application is very memory intensive. I have been told that the PPC
> always has priority on the PLB and that if I want to have my=20
> FPGA module
> have priority on memory, that I should place the memory and my FPGA
> module on the OPB. Yes, this can significantly slow down the PPC, but
> in my case the PPC is only used for UI and networking.
>=20
> I will actually build in *two* OPBs one for the memory + my module and
> the second for the other peripherals.=20
>=20
>=20
> Woody.
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
^ permalink raw reply
* Re: signals handling in the kernel
From: David Hawkins @ 2007-08-30 15:57 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <12409543.post@talk.nabble.com>
Hi Mirek,
> I went throught the Rubini book about device drivers
> and I see that you are absolutly right about
> the way how to handle interrupts in the user space.
Great, glad to hear you are convinced :)
> When I find a bit of time I will try your first
> suggestion with read() which blocks in the user space
> and waits for ISR to write data to the buffer.
Look at the example drivers I wrote. Its all in
there, just copy whatever you want.
> Many thanks for all your suggestions
No problem! Its the open-source way ;)
Cheers,
Dave
^ permalink raw reply
* Re: spin_lock doesn't work?!?
From: Wolfgang Reissnegger @ 2007-08-30 15:36 UTC (permalink / raw)
To: melinda develey; +Cc: linuxppc-embedded
In-Reply-To: <762949.1267.qm@web63906.mail.re1.yahoo.com>
Hi Melinda,
I agree with Josh, you should use spin_lock_irqsave(), especially in
your ioctl() routine. spin_lock_irqsave will not compile into a no-op,
even on a single processor machine and will at least disable interrupts.
On SMP machines they will also spin.
Depending on the type of access of the variables in your ioctl()
routine, you might want to consider using read/write spin-locks.
It is not wrong to use spin_locks the way use want to use them.
spin_locks are the right tool to protect a short section in your code.
Cheers,
Wolfgang
melinda develey wrote:
>
> >You should still put the spin_lock calls into your code because >you
> >never know if someone else will compile it and for another >target. If
> >someone would, for example, compile the same code for a SMP
> >machine then
> >the spin_lock will actually lock.
> I used the spinlock both in an interrupt handler to protect a group
> of variables (because in an interrupt I can't use a semaphore) and
> the same spinlock in a ioctl handler where the same group of
> variables is accessed. Is this wrong? I have a 2.6.19.2 linux kernel.
>
> Thank you,
> Melinda.
>
>
>
>
> ------------------------------------------------------------------------
> Ready for the edge of your seat? Check out tonight's top picks
> <http://us.rd.yahoo.com/evt=48220/*http://tv.yahoo.com/> on Yahoo! TV.
^ permalink raw reply
* Re: signals handling in the kernel
From: Mirek23 @ 2007-08-30 15:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46B9FB23.8040903@ovro.caltech.edu>
Hi David,
I went throught the Rubini book about device drivers and I see that
you are absolutly right about
the way how to handle interrupts in the user space.
When I find a bit of time I will try your first suggestion with read() which
bolckes in the user space and
waits forr ISR to write data to the buffer.
Many thanks for all your suggestions
Best Regards
Mirek
David Hawkins-3 wrote:
>
> Hi Mirek,
>
>> I run embedded Linux on ppc405 (ml403 xilinx evaluation board).
>> I use the GPIO based device build on FPGA part of the xilinx
>> chip. My gpio device generates interrupts whenever it changes
>> its state.
>>
>> I use Montavista gpio driver with some modifications to react
>> on interrupts. Each time when interrupt occurs the interrupt
>> handler routine is called. This routine sends the signal to the
>> application in user space to trigger it. When the application
>> is triggered it reads the data from the GPIO device.
>>
>> I read that in this situation the best is to use signals. In my
>> case the ideal would be to use kill_proc_info which sends to the
>> application the Signal with info data were I intended to put just
>> one integer value. Such a value determines how to react for the
>> signal on the application level.
>
> Signals are not the appropriate solution.
>
> It sounds like your application is read-only, so how about
> the following use-cases for the driver:
>
> 1. In user-space, you only have one GPIO, and the code
> only needs to react in response to this one I/O port.
> The information required by user-space is the 1-byte
> (or 2, or 4) of GPIO
>
> Solution:
> The driver implements a buffer that a user-space read() call
> consumes. A user-space read() call blocks until there is
> data in the buffer.
>
> The driver ISR reads the GPIO port, and writes the
> contents to the buffer.
>
> 2. In user-space, you have multiple GPIO ports, and
> the code needs to respond to any one.
>
> Solution:
> The driver implements the poll() call back so that
> user-space can call select() on the multiple GPIO
> file descriptors.
>
> Again, the driver ISR reads the different GPIO ports,
> and writes the data to the GPIO specific buffer.
>
> I have plenty of driver code lying around, and can point
> you to an example that implements both of these options.
> The driver easily supports both (1) and (2) since
> (1) is just a blocking-read, and (2) is poll().
>
> Is the kernel 2.4 or 2.6? Here's some code I wrote for
> 2.6, and this code was ported from some 2.4 drivers
> (and I still have that code in CVS)
>
> http://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html
> http://www.ovro.caltech.edu/~dwh/correlator/software/driver_design.tar.gz
> http://www.ovro.caltech.edu/~dwh/correlator/pdf/LNX-762-Hawkins.pdf
>
> I can re-write say the parallel port example to demonstrate
> how the value of the GPIO port (the parallel port) can be
> sent to user space. There's a parallel port interrupt
> example in there somewhere. I know I wrote a GPIO driver
> for my Yosemite board (440EP example), but I don't see it
> in that zip ... it must be lying around here somewhere :)
>
> I wouldn't necessarily copy say a parallel port example
> verbatim, since there is only ever one of those devices
> in a system. There are more likely to be multiple GPIO ports,
> so the driver design would be generalized a little more.
> Look at the COBRA driver code. I have crates of cPCI equipment
> loaded with 10s of boards, with each board having multiple
> device nodes, transferring megabytes per second over
> multiple cPCI crates :)
>
> Anyway, stop thinking about signals, they'll just mess you up.
>
> Oh, the driver will also support sending SIGIO to the process,
> via the fasync() driver call, so you can try signals, and
> convince yourself that select() is much nicer.
>
> A GPIO driver seems like such an obvious thing to write. Are
> you sure the montavista driver doesn't already support these
> features? I have no idea of your experience with coding, so
> it could just be that you are unaware of what the driver
> implements. If you are allowed to post it, go ahead, and
> I'll comment on its features.
>
> Cheers
> Dave
>
>
>
>
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12409543
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 8/9] mpc82xx: Update mpc8272ads, and factor out PCI and reset.
From: Scott Wood @ 2007-08-30 15:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <573185B5-2B02-4D97-BAC8-D508C16D6093@kernel.crashing.org>
On Thu, Aug 30, 2007 at 09:56:16AM -0500, Kumar Gala wrote:
> It don't feel its a mishmash of crap its just how things are
> defined. Maybe the SOC node was a mistake, but I think we are past
> the point of return on that.
The node itself wasn't a mistake -- the IMMR is relocatable, so it should
be under a bus node. The mistake was assuming the PCI ranges went
straight to the CPU space, rather than getting translated through the
parent bus's ranges. We got away with that mistake because of a similar
bug in the 32-bit PCI code.
In the past few months, this issue began to be addressed in a handful of
device trees. In the device trees I prepared, I used separate bus and
control nodes. In the 8544, 8548, and 8641 device trees, extra ranges
were hacked into the soc node. All other PCI-bearing Freescale device
tree files are still broken.
I don't think a few months is an unrecoverable legacy.
> Having one platform's device tree be different just creates confusion
> to our customers.
The intent isn't for 82xx to be different from everything else -- it's
simply the first one to get fixed in this way. Incremental changes, and
what not.
Note that it would be quite easy to make the code accept either type of
device tree.
> While there isn't anything technically wrong with what your proposing
> it will cause support issues down the line which I want to avoid.
Such as?
-Scott
^ permalink raw reply
* Re: Xilinx Virtex boot
From: Grant Likely @ 2007-08-30 15:02 UTC (permalink / raw)
To: Robert Woodworth; +Cc: linuxppc-embedded
In-Reply-To: <1188485072.8717.42.camel@PisteOff>
On 8/30/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> On Wed, 2007-08-29 at 18:29 -0600, Grant Likely wrote:
> > On 8/29/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> > > I'm trying to port Linux to a new Virtex Platform. The kernel will not
> > > uncompress, I get the following on the console:
> > >
> > > loaded at: 00400000 004FB19C
> > > board data at: 004F9120 004F919C
> > > relocated to: 00404054 004040D0
> > > zimage at: 00404E50 004F8409
> > > avail ram: 004FC000 04000000
> > >
> > > Linux/PPC load: console=ttyUL root=/dev/xsa2
> > > Uncompressing Linux...
> > > zlib_inflateInit2 returned 00506530
> > > exit
> > >
> > > Any ideas what causes this error??
> > > Is something mis-configured on my EDK project?
> > >
> >
> > Possibly, do you know that EDK has your ram is configured correctly
> > (ie. have you run a memory test application)?
>
> Yes, I ran the sample memory test application that EDK builds
> automatically. It ran fine.
>
> The fact that the above prints on the console, tells me that the
> zImage.elf is getting loaded at the correct start location and that its
> partly executing.
>
> What is the return code that I'm seeing?? I have been unable to figure
> that out from the source yet.
IIRC, the return code is the result of the CRC calculation. If it is
non-zero, then the CRC was incorrect. That says to me that you've got
either memory or download issues.
I have seen corruption in the past when downloading zImages larger
than about 1.2MB over JTAG.
> > > I have 64MB DDR on the OPB *not* the PLB.
> > > Is that a problem??
> >
> > It shouldn't be the problem, but why are you doing that?
>
> We are building an image-processing application inside the FPGA. The
> application is very memory intensive. I have been told that the PPC
> always has priority on the PLB and that if I want to have my FPGA module
> have priority on memory, that I should place the memory and my FPGA
> module on the OPB. Yes, this can significantly slow down the PPC, but
> in my case the PPC is only used for UI and networking.
<offtopic> You might want to take a look at the MPMC ipcore. It
allows multiple PLBs to address a single memory region.</offtopic>
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 8/9] mpc82xx: Update mpc8272ads, and factor out PCI and reset.
From: Kumar Gala @ 2007-08-30 14:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070830055644.GA21604@ld0162-tx32.am.freescale.net>
On Aug 30, 2007, at 12:56 AM, Scott Wood wrote:
> On Wed, Aug 29, 2007 at 05:41:17PM -0500, Kumar Gala wrote:
>> NACK.
>>
>> I don't want pq2 to be the only platform that has the PCI bus
>> separate from the PCI controller.
>
> Could you articulate the reasons why you'd rather have a mishmash
> of crap
> in the soc node's ranges property?
It don't feel its a mishmash of crap its just how things are
defined. Maybe the SOC node was a mistake, but I think we are past
the point of return on that.
Having one platform's device tree be different just creates confusion
to our customers. While there isn't anything technically wrong with
what your proposing it will cause support issues down the line which
I want to avoid.
- k
^ permalink raw reply
* Re: Xilinx Virtex boot
From: Robert Woodworth @ 2007-08-30 14:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708291729j3f63a57dl32e5d4df647326b5@mail.gmail.com>
On Wed, 2007-08-29 at 18:29 -0600, Grant Likely wrote:
> On 8/29/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> > I'm trying to port Linux to a new Virtex Platform. The kernel will not
> > uncompress, I get the following on the console:
> >
> > loaded at: 00400000 004FB19C
> > board data at: 004F9120 004F919C
> > relocated to: 00404054 004040D0
> > zimage at: 00404E50 004F8409
> > avail ram: 004FC000 04000000
> >
> > Linux/PPC load: console=ttyUL root=/dev/xsa2
> > Uncompressing Linux...
> > zlib_inflateInit2 returned 00506530
> > exit
> >
> > Any ideas what causes this error??
> > Is something mis-configured on my EDK project?
> >
>
> Possibly, do you know that EDK has your ram is configured correctly
> (ie. have you run a memory test application)?
>
>
> >
> > I have 64MB DDR on the OPB *not* the PLB.
> > Is that a problem??
>
> It shouldn't be the problem, but why are you doing that?
I did notice in my configuration, that when the memory is on the PLB it
has an interrupt flag and when it's on the OPB it doesn't. What is the
interrupt for? DMA's?
Could Linux be doing a DMA in the uncompression where the lack of an
interrupt causes and error?
^ permalink raw reply
* Re: Xilinx Virtex boot
From: Robert Woodworth @ 2007-08-30 14:44 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708291729j3f63a57dl32e5d4df647326b5@mail.gmail.com>
On Wed, 2007-08-29 at 18:29 -0600, Grant Likely wrote:
> On 8/29/07, Robert Woodworth <rwoodworth@securics.com> wrote:
> > I'm trying to port Linux to a new Virtex Platform. The kernel will not
> > uncompress, I get the following on the console:
> >
> > loaded at: 00400000 004FB19C
> > board data at: 004F9120 004F919C
> > relocated to: 00404054 004040D0
> > zimage at: 00404E50 004F8409
> > avail ram: 004FC000 04000000
> >
> > Linux/PPC load: console=ttyUL root=/dev/xsa2
> > Uncompressing Linux...
> > zlib_inflateInit2 returned 00506530
> > exit
> >
> > Any ideas what causes this error??
> > Is something mis-configured on my EDK project?
> >
>
> Possibly, do you know that EDK has your ram is configured correctly
> (ie. have you run a memory test application)?
Yes, I ran the sample memory test application that EDK builds
automatically. It ran fine.
The fact that the above prints on the console, tells me that the
zImage.elf is getting loaded at the correct start location and that its
partly executing.
What is the return code that I'm seeing?? I have been unable to figure
that out from the source yet.
> >
> > I have 64MB DDR on the OPB *not* the PLB.
> > Is that a problem??
>
> It shouldn't be the problem, but why are you doing that?
We are building an image-processing application inside the FPGA. The
application is very memory intensive. I have been told that the PPC
always has priority on the PLB and that if I want to have my FPGA module
have priority on memory, that I should place the memory and my FPGA
module on the OPB. Yes, this can significantly slow down the PPC, but
in my case the PPC is only used for UI and networking.
I will actually build in *two* OPBs one for the memory + my module and
the second for the other peripherals.
Woody.
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Kumar Gala @ 2007-08-30 14:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, torvalds
In-Reply-To: <18134.44726.426680.221570@cargo.ozlabs.ibm.com>
On Aug 30, 2007, at 6:49 AM, Paul Mackerras wrote:
> Linus,
>
> Please do
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> There are a couple more bug fixes for Cell plus one from Kumar, and
> defconfig updates.
>
> Paul.
any reason you didn't pull this into your master branch as well, or
will just wait to do that after linus pulls?
- k
^ permalink raw reply
* Re: [PATCH 6/9] bootwrapper: Add a zImage.bin.<platform> target.
From: Scott Wood @ 2007-08-30 14:21 UTC (permalink / raw)
To: paulus, linuxppc-dev
In-Reply-To: <20070830003409.GE21072@localhost.localdomain>
On Thu, Aug 30, 2007 at 10:34:09AM +1000, David Gibson wrote:
> Hrm.. I think the --binary option at least should be removed, and
> subsumed into the platform id - all other binary formats are selected
> by the platform name at present.
>
> And I think it's probably best to do that for --fixed-entry as well,
> although it's a bit less clear there.
I'm not particularly fond of having huge platform switch blocks in the
wrapper script -- if it can be reasonably parameterized, why not do so?
-Scott
^ permalink raw reply
* Re: [PATCH 2/3] Introduce new CPM device bindings.
From: Scott Wood @ 2007-08-30 14:10 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20070830055812.GB32543@localhost.localdomain>
On Thu, Aug 30, 2007 at 03:58:12PM +1000, David Gibson wrote:
> On Thu, Aug 30, 2007 at 12:48:54AM -0500, Scott Wood wrote:
> > On Thu, Aug 30, 2007 at 10:55:59AM +1000, David Gibson wrote:
> > > Am I correct in thinking that it's basically an arch/ppc versus
> > > arch/powerpc thing. In which case couldn't you use CONFIG_PPC_MERGE
> > > instead?
> >
> > The idea was to allow boards to be converted incrementally, as I don't
> > have access to test 100% of the boards that use the CPM code.
>
> Hrm. Right. This is still problematical, because what happens if you
> have both old-binding and new-binding boards configured simultaneously?
Multiplatform will not be supported for old-binding boards.
-Scott
^ permalink raw reply
* Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions
From: Joachim Fenkes @ 2007-08-30 14:00 UTC (permalink / raw)
To: jschopp, Nathan Lynch
Cc: Thomas Q Klein, Paul Mackerras, Jan-Bernd Themann, LKML,
LinuxPPC-Dev, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <46D5BBFA.5060200@austin.ibm.com>
Nathan Lynch <ntl@pobox.com> wrote on 29.08.2007 20:12:32:
> > Previously, ibmebus derived a device's bus_id from its location code.
The
> > location code is not guaranteed to be unique, so we might get bus_id
> > collisions if two devices share the same location code. The OFDT
full_name,
> > however, is unique, so we use that instead.
>
> This is a userspace-visible change, but I guess it's unavoidable.
> Will anything break?
Nope. Userspace programs should not depend on ibmebus' way of naming the
devices; especially since some overly long loc_codes tended to be
truncated and thus rendered useless. I have tested IBM's DLPAR tools
against the changed kernel, and they didn't break.
> Also, I dislike this approach of duplicating the firmware device tree
> path in sysfs.
Why? Any specific reasons for your dislike?
> Are GX/ibmebus devices guaranteed to be children of
> the same node in the OF device tree? If so, their unit addresses will
> be unique, and therefore suitable values for bus_id. I believe this
> is what the powerpc vio bus code does.
While there's no such guarantee (as in "officially signed document"), yes,
I expect future GX devices to also appear beneath the OFDT root node. For
the existing devices, the unit addresses are already part of the device
name, so I save the need to use sprintf() again. Plus, I rather like using
the full_name since it also contains a descriptive name as opposed to
being just nondescript numbers, helping the layman (ie user) to make sense
out of a dev_id.
jschopp <jschopp@austin.ibm.com> wrote on 29.08.2007 20:33:30:
> > + len = strlen(dn->full_name + 1);
> > + bus_len = min(len, BUS_ID_SIZE - 1);
> > + memcpy(dev->ofdev.dev.bus_id, dn->full_name + 1
> > + + (len - bus_len), bus_len);
> > + for (i = 0; i < bus_len; i++)
> > + if (dev->ofdev.dev.bus_id[i] == '/')
> > + dev->ofdev.dev.bus_id[i] = '_';
> >
> > /* Register with generic device framework. */
> > if (ibmebus_register_device_common(dev, dn->name) != 0) {
>
> What happens when the full name is > 31 characters? It looks to me that
it
> will be truncated, which takes away the uniqueness guarantee.
There are currently two GX devices, eHCA and eHEA, which both reside
beneath the root node - this is required by architecture for those
devices. Unless they invent a device called
"supercalifragilisticexpialidocious", devices in the root note will have a
full_name of less than 31 chars. Even in that case, the truncation occurs
at the beginning, so the @xxx part that makes the nodes unique will stay
in place.
If any more GX devices appear on the scene, I expect them to appear in the
root node as well. The substitution of "/" by "_" is a safeguard so
possible weird OFDT setups don't break the kernel.
> There must be an individual property that is guaranteed to be unique and
> less than 32 characters. How about "ibm,my-drc-index"? That looks like
a
> good candidate.
On first glance, it does, however the attribute might not be present in
all cases. Architecture states it only needs to be present on systems with
dynamic reconfiguration enabled.
All things considered, I still like the idea of using the full_name most.
No offense.
Regards,
Joachim
^ permalink raw reply
* RE: Network is blocked till ping is issued
From: DI BACCO ANTONIO - technolabs @ 2007-08-30 13:59 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Florian A. Voegel, linuxppc-embedded
In-Reply-To: <bdfc5d6e0708300552g71a995c9x10f17322613ca9c1@mail.gmail.com>
>No. You are confusing Ethernet frames and IP packets a little bit.
>If a Linux machine receives a SYN from a remote host (not on the same
>network) then the Linux machine needs to ARP for the router that is
>listed as the default route in the routing table.
>If no such default route exists, you will not be able to reach the
>remote host. If the router doesn't reply to your ARP request, you
>will not be able to reach the remote host.
>Check to make sure you are not having either one of these problems.
I'm on the same network: NotLinux is 100.1.0.1 and Linux is 100.1.0.2
with netmask 255.255.255.0
Thank you,
Antonio.
^ permalink raw reply
* Re: libfdt: Several new functions
From: Jon Loeliger @ 2007-08-30 13:52 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070830045253.GA32543@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This series of patches adds several new functions to libfdt. These
> are all read-only functions related to determining a given nodes node
> and ancestry.
All three pplied.
Thanks,
jdl
^ permalink raw reply
* Re: libfdt: Fix handling of trailing / in fdt_path_offset()
From: Jon Loeliger @ 2007-08-30 13:52 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070829022250.GA25468@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Currently, fdt_path_offset() returns FDL_ERR_BADOFFSET if given a path
> with a trailing '/'. In particular this means that
> fdt_path_offset("/") returns FDT_ERR_BADOFFSET rather than 0 as one
> would expect.
>
> This patch fixes the function to accept and ignore trailing '/'
> characters. As well as allowing fdt_path_offset("/") this means that
> fdt_path_offset("/foo/") will return the same as
> fdt_path_offset("/foo") which seems in keeping with the principle of
> least surprise.
>
> This also adds a testcase to ensure that fdt_path_offset("/") returns
> 0 as it should.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: dtc: Fix summary calculation in testsuite
From: Jon Loeliger @ 2007-08-30 13:51 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070829021851.GA25233@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> The bookkeeping for producing the testsuite summary (total number of
> tests passed, failed and so forth) is broken. It uses $? across
> several tests, but for checks after the first, the value of $? will no
> longer contain the original return code, but just that from the
> previous test. This patch fixes the problem.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC 440EPx: Initial Sequoia support
From: Valentine Barshak @ 2007-08-30 13:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <1188433699.3515.15.camel@localhost.localdomain>
Josh Boyer wrote:
> On Wed, 2007-08-29 at 17:35 +0400, Valentine Barshak wrote:
>> The following patches add initial PowerPC 440EPx Sequoia board support.
>> The code is based mainly on the Bamboo board support by Josh Boyer.
>> These patches have been modified according the comments for the previous
>> 440EPx Sequoia patch series.
>
> I see David has beaten me to reviewing the individual patches, which of
> course is always welcome. I just wanted add that I also think these
> look good. Thanks!
>
> josh
>
Thanks guys :)
Valentine
^ permalink raw reply
* Re: Linux doesn not boot from u-boot on ML403
From: Grant Likely @ 2007-08-30 13:21 UTC (permalink / raw)
To: Miroslaw Dach; +Cc: Leonid, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0708300923140.12294-100000@slslc02.psi.ch>
On 8/30/07, Miroslaw Dach <miroslaw.dach@psi.ch> wrote:
>
> When I try to start zImage.elf with bootelf command the system hangs during
> uncompressing.
> When I try to start uImage with bootm command the image is uncompressed
> but it does not start properly.
Ugh, I'm stumped. Sorry. I'd spend some more quality time with your
debugger to trace the exact boot path.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Network is blocked till ping is issued
From: Andy Gospodarek @ 2007-08-30 12:52 UTC (permalink / raw)
To: DI BACCO ANTONIO - technolabs; +Cc: Florian A. Voegel, linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8EA1869B@aquib01a>
On 8/30/07, DI BACCO ANTONIO - technolabs <Antonio.DiBacco@technolabs.it> wrote:
> > sounds to me like it could be a classical ARP problem. Have you
> checked the ARP cache on the non-Linux
> > machine?
>
> But if Linux received the SYN packet of TCP connection, shouldn't the
> Linux machine reply to the source mac address of SYN packet with a
> SYN,ACK packet?
>
No. You are confusing Ethernet frames and IP packets a little bit.
If a Linux machine receives a SYN from a remote host (not on the same
network) then the Linux machine needs to ARP for the router that is
listed as the default route in the routing table.
If no such default route exists, you will not be able to reach the
remote host. If the router doesn't reply to your ARP request, you
will not be able to reach the remote host.
Check to make sure you are not having either one of these problems.
^ permalink raw reply
* Re: spin_lock doesn't work?!?
From: Josh Boyer @ 2007-08-30 11:50 UTC (permalink / raw)
To: melinda develey; +Cc: linuxppc-embedded
In-Reply-To: <762949.1267.qm@web63906.mail.re1.yahoo.com>
On Wed, 29 Aug 2007 23:30:22 -0700 (PDT)
melinda develey <melinda.develey70@yahoo.com> wrote:
> >You should still put the spin_lock calls into your code because >you
> >never know if someone else will compile it and for another >target. If
> >someone would, for example, compile the same code for a SMP >machine then
> >the spin_lock will actually lock.
>
> I used the spinlock both in an interrupt handler to protect a group of variables (because in an interrupt I can't use a semaphore) and the same spinlock in a ioctl handler where the same group of variables is accessed. Is this wrong? I have a 2.6.19.2 linux kernel.
You might want to use spin_lock_irq instead. That will disable
interrupts in the critical section in the ioctl. Seems more like what
you are trying to do.
josh
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-08-30 11:49 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
There are a couple more bug fixes for Cell plus one from Kumar, and
defconfig updates.
Paul.
arch/powerpc/configs/celleb_defconfig | 196 +----
arch/powerpc/configs/chrp32_defconfig | 220 ++----
arch/powerpc/configs/ebony_defconfig | 190 +----
arch/powerpc/configs/g5_defconfig | 208 ++---
arch/powerpc/configs/holly_defconfig | 203 ++---
arch/powerpc/configs/iseries_defconfig | 210 +----
arch/powerpc/configs/linkstation_defconfig | 219 ++----
arch/powerpc/configs/lite5200_defconfig | 191 +----
arch/powerpc/configs/maple_defconfig | 189 +----
arch/powerpc/configs/mpc7448_hpc2_defconfig | 202 +----
arch/powerpc/configs/mpc8272_ads_defconfig | 193 ++---
arch/powerpc/configs/mpc8313_rdb_defconfig | 224 ++----
arch/powerpc/configs/mpc832x_mds_defconfig | 209 ++---
arch/powerpc/configs/mpc832x_rdb_defconfig | 211 ++----
arch/powerpc/configs/mpc834x_itx_defconfig | 206 ++---
arch/powerpc/configs/mpc834x_itxgp_defconfig | 203 ++---
arch/powerpc/configs/mpc834x_mds_defconfig | 205 ++---
arch/powerpc/configs/mpc836x_mds_defconfig | 209 ++---
arch/powerpc/configs/mpc8540_ads_defconfig | 183 +----
arch/powerpc/configs/mpc8544_ds_defconfig | 459 +++++++++++-
arch/powerpc/configs/mpc8560_ads_defconfig | 196 +----
arch/powerpc/configs/mpc8568mds_defconfig | 43 -
arch/powerpc/configs/mpc85xx_cds_defconfig | 198 ++---
arch/powerpc/configs/mpc8641_hpcn_defconfig | 880 ++++++++++++++++++-----
arch/powerpc/configs/mpc866_ads_defconfig | 174 +----
arch/powerpc/configs/mpc885_ads_defconfig | 174 +----
arch/powerpc/configs/pasemi_defconfig | 225 ++----
arch/powerpc/configs/pmac32_defconfig | 237 ++----
arch/powerpc/configs/ppc64_defconfig | 220 ++----
arch/powerpc/configs/prpmc2800_defconfig | 213 ++----
arch/powerpc/configs/pseries_defconfig | 205 ++---
arch/powerpc/kernel/process.c | 6
arch/powerpc/platforms/cell/spu_manage.c | 8
arch/powerpc/platforms/cell/spufs/backing_ops.c | 3
arch/powerpc/platforms/cell/spufs/run.c | 6
arch/powerpc/platforms/ps3/setup.c | 3
36 files changed, 2846 insertions(+), 4275 deletions(-)
commit fc43dca9e75b87d24a16d5be7b497e83837d9d31
Author: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Date: Wed Aug 29 20:30:25 2007 +0900
[POWERPC] PS3: Fix bug where the major version part is not compared
Fix the bug that the major version part of the firmware version number
is ignored in the comparison done by ps3_compare_firmware_version
because the difference of two 64-bit quantities is returned as an int.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 13a6976afdb10d54ac5ad344aa0c588bc0bd8b0a
Author: Paul Mackerras <paulus@samba.org>
Date: Thu Aug 30 16:51:51 2007 +1000
[POWERPC] Update defconfigs
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit ada83daab31c3ec35845785482124373a62f430c
Author: Andre Detsch <adetsch@br.ibm.com>
Date: Tue Aug 21 10:06:22 2007 +0800
[POWERPC] spufs: Don't call spu_run_init from spu_reacquire_runnable
This fixes a major bug which was happening when a SPU thread advances
its execution right after being restored to a SPU. A potentially
outdated NPC value was being (re)written to the SPU.
So, spu_run_init, in this case, was either not doing anything relevant,
or breaking the execution of the SPU thread.
This fixes a common problem of losing a mailbox write when it was done
to a saved context.
Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 62ee68e3bcb0d056aae5b36dea0388ca25572cdf
Author: Arnd Bergmann <arnd@arndb.de>
Date: Tue Aug 21 10:06:22 2007 +0800
[POWERPC] spufs: Fix update of mailbox status register during backed wbox write
When a process writes into the inbound spu mailbox (wbox) while the
context is saved, we accidentally break the contents of the mb_stat_R
register by clearing other entries of the mailbox status register. This
can cause the user side to hang.
This change fixes the problem by only altering the appropriate bits
of the mailbox status register during a backing-store write.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit aac2e68481681a362ab6f44fc515034e2a4c7f2c
Author: Christian Krafft <krafft@de.ibm.com>
Date: Thu Aug 30 01:33:53 2007 +0200
[POWERPC] spu_manage: fix spu_unit_number for celleb device tree
This fixes a regression introduced with 2.6.23-rc4 after on some
confusion about the device tree interfaces.
IBM QS21 device trees provide "physical-id", so we changed the code to
run on that and remain compatible with all IBM machines.
However, the Toshiba Celleb device tree provides the "unit-id" property,
which was in the Linux code, but never used in this way on IBM hardware.
Legacy device tree used the reg property for the physical id of an spe.
This patch fixes find_spu_unit_number to look for the spu id in that order.
The length is checked to avoid misinterpretation in case the attributes
unit-id or reg do not contain the id.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Cc: Jeremy Kerr <jk@ozlabs.org>
commit 5cc44e086d7a4e20035997ec612678ca91f426e7
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Tue Aug 28 21:46:53 2007 -0500
[POWERPC] Update defconfigs
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 0ee6c15e7ba7b36a217cdadb292eeaf32a057a59
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Tue Aug 28 21:15:53 2007 -0500
[POWERPC] Flush registers to proper task context
When we flush register state for FP, Altivec, or SPE in flush_*_to_thread
we need to respect the task_struct that the caller has passed to us.
Most cases we are called with current, however sometimes (ptrace) we may
be passed a different task_struct.
This showed up when using gdbserver debugging a simple program that used
floating point. When gdb tried to show the FP regs they all showed up as
0, because the child's FP registers were never properly flushed to memory.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
^ permalink raw reply
* Re: how to debug the linux kernel with a BDI2000
From: Detlev Zundel @ 2007-08-30 9:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <479723497.472031188208291804.JavaMail.coremail@bj163app103.163.com>
Hi Denny,
> My kernel hanged in when passed the parameters to it, and I dump nothing from
> the log_buf, so I guss it is crashed at the very beginning.
>
> however I didn't know how to setup the KDB to load the kernel with the BDI2000
> ethernet? is there anyone has even loaded and debugged the kernel with the
> BDI2000 ethernet? if so pls show me how it goes?
You don't need KDB to use the BDI2000 to debug a linux kernel, in fact
you need nothing on the target side. Simply attach the BDI to your
hardware, and use a (cross-)gdb with the "target remote
<ipaddr>:<port>" command. Our DULG shows how to do that with
U-Boot[1]. Debugging (static) Linux is exactly the same...
Cheers
Detlev
[1] http://www.denx.de/wiki/view/DULG/DebuggingUBoot
--
debian is a prototype for a future version of emacs.
-- Thien-Thi Nguyen in <7eekubiffq.fsf@ada2.unipv.it>
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ 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