* Re: [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
From: Jochen Friedrich @ 2008-07-18 15:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Scott Wood
In-Reply-To: <C98DF5D7-0E3D-4FDA-A831-55CFD5F4590C@kernel.crashing.org>
Hi Kumar,
> but ports a-d are different on cpm1? I guess I'd like to see both
> patches to understand the commonality and differences.
Yes. Both patches are still in patchwork:
http://patchwork.ozlabs.org/linuxppc/patch?id=19045
http://patchwork.ozlabs.org/linuxppc/patch?id=19386
Thanks,
Jochen
^ permalink raw reply
* Re: [alsa-devel] [PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Grant Likely @ 2008-07-18 16:14 UTC (permalink / raw)
To: Liam Girdwood, linuxppc-dev, alsa-devel, timur
In-Reply-To: <20080718095823.GA14416@sirena.org.uk>
On Fri, Jul 18, 2008 at 10:58:25AM +0100, Mark Brown wrote:
> Sparse (or sparsely used) register maps are pretty common - in practice
> it's not been a problem to just have a cache that covers everything and
> only gets read, the amount of data involved is rarely that large in the
> context of what you need to store the audio you're working with.
okay.
g.
^ permalink raw reply
* Re: ml403_emb_ref_ppc_81.zip problem
From: Grant Likely @ 2008-07-18 16:18 UTC (permalink / raw)
To: Naresh Bhat; +Cc: linuxppc-embedded
In-Reply-To: <cf9b3c760807180413w447535a7h35d8ce15c2c8e4e@mail.gmail.com>
Please don't ask EDK-specific question on this mailing list. This list
is for Linux on PowerPC. Your question is strictly about using Xilinx's
proprietary toolchain. You should go to Xilinx's website to look for
help.
g.
On Fri, Jul 18, 2008 at 04:43:14PM +0530, Naresh Bhat wrote:
> My problem is explained here...
>
> While creating the new XPS project using Base system Builder:
>
>
> Step 1.
>
>
>
> New Project->Base System builder Project-> Create a new XPS project using
> Base system Builder->Browse system.xps project from "ml403_emb_ref_ppc_81"
> directory and overite it.
>
>
>
> Step 2.
>
> I am selecting "I would like to create the new design"
>
> and then
>
> Board Vendor "Xilinx"
>
> Board name "ML403"
>
> Board version "1"
>
>
>
> Step 3:
>
> I just click "Next"
>
>
>
> Step 4:
>
> I am selecting the Processor Cloclk Frequency as "300Mhz"
>
>
>
> Step 5: Configuring the IO interfaces
>
>
>
> Here is my problem.
>
>
>
> In RS232 UART I am having the only 2 option
>
> 1. XPS_UARTLITE
>
> 2. XPS_UART16550
>
>
>
> If I use the same base system builder (ml403_emb_ref_ppc_81) with other
> version of the EDK tools (like 8.1iSP2, 9.2iSP2). and repeat the same steps
> I am able to see the options like
>
> 1. OPB_UARTLITE
>
> 2. OPB_UART16550
>
> 3. PLB_UART16550
>
>
>
> Do you have any idea on this Why it is not getting displayed on the
> EDK10.1iSP2 version?
>
>
> Thanks
>
> Naresh Bhat
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: going to OLS?
From: Wolfgang Denk @ 2008-07-18 16:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <4313E14A-C3FB-4996-B188-767704F380C3@kernel.crashing.org>
In message <4313E14A-C3FB-4996-B188-767704F380C3@kernel.crashing.org> you wrote:
> Since OLS is next week I figured I see who around here is going.
>From DENX: Stefan Roese and me.
> I'm always interested in putting faces to names and having a lively
> discussions over beer.
Hear! Hear! That was an invitation, wasn't it ?
> So if your headed to OLS respond to this thread and maybe we'll have
> an inform PPC BoF @ a pub.
ACK.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A day without sunshine is like night.
^ permalink raw reply
* Re: going to OLS?
From: Grant Likely @ 2008-07-18 16:24 UTC (permalink / raw)
To: Stefan Roese; +Cc: Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <200807181620.21498.sr@denx.de>
On Fri, Jul 18, 2008 at 04:20:21PM +0200, Stefan Roese wrote:
> On Friday 18 July 2008, Geert Uytterhoeven wrote:
> > On Fri, 18 Jul 2008, Kumar Gala wrote:
> > > Since OLS is next week I figured I see who around here is going.
> > >
> > > I'm always interested in putting faces to names and having a lively
> > > discussions over beer.
> > >
> > > So if your headed to OLS respond to this thread and maybe we'll have an
> > > inform PPC BoF @ a pub.
> >
> > Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> >
> > So I'll be there.
>
> Me too. :)
Me three
^ permalink raw reply
* Re: going to OLS?
From: Grant Likely @ 2008-07-18 16:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <4313E14A-C3FB-4996-B188-767704F380C3@kernel.crashing.org>
On Fri, Jul 18, 2008 at 08:35:36AM -0500, Kumar Gala wrote:
> Since OLS is next week I figured I see who around here is going.
>
> I'm always interested in putting faces to names and having a lively
> discussions over beer.
>
> So if your headed to OLS respond to this thread and maybe we'll have an
> inform PPC BoF @ a pub.
If anybody wants to email me their cell phone # privately then I'll
collect a list and send it out to all the repliers to this thread.
That way you don't need to post your cell # to the mailing list for the
world to see.
g.
^ permalink raw reply
* Re: going to OLS?
From: Wolfgang Denk @ 2008-07-18 16:33 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev list
In-Reply-To: <20080718162731.GD10317@secretlab.ca>
In message <20080718162731.GD10317@secretlab.ca> you wrote:
>
> If anybody wants to email me their cell phone # privately then I'll
> collect a list and send it out to all the repliers to this thread.
> That way you don't need to post your cell # to the mailing list for the
> world to see.
BTW: will there a pre-OLS beer evening on Tuesday, or will Stefan and
me have to sit alone in some bar?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Pull the wool over your own eyes!" - J.R. "Bob" Dobbs
^ permalink raw reply
* Re: [RFC v3 PATCH 1/4] Extract list of relocation offsets
From: Milton Miller @ 2008-07-18 17:00 UTC (permalink / raw)
To: Mohan Kumar M; +Cc: paulus, ppcdev
In-Reply-To: <48802AE0.30105@in.ibm.com>
On Jul 18, 2008, at 12:32 AM, Mohan Kumar M wrote:
> Benjamin Herrenschmidt wrote:
>> On Fri, 2008-07-18 at 00:10 +0530, Mohan Kumar M wrote:
>>> Extract list of relocation offsets
>>>
>> Please, provide an indication of what changed since the previous
>> version of the patch to make the reviewer's life easier !
>>
> Hi,
>
> Oops, I missed out the detailed change description. Thanks Ben for
> pointing this.
>
> Here is a change summary from v2 to v3:
Last night I was trying the patches on the current upstream git, but
was not able to get the dump kernel to user space. Part of the
problem was my own making (my default kernel is patched to crash dump
to 16M instead of 32M among other patches, so I needed to go to a
normal kernel first, but couldn't use the reloc kernel because the
slaves would stick and then the code would wait in the IPI).
I now understand why the remaining cpus do not make it into the crash
kernel. In fact they don't make it from kexec of a good kernel into a
reloc kernel. I'm ignoring that for now because, as I told you via
chat, I realize from looking at the patches that the reloc_apply code
needs to move from the external wrapper to inside the kernel init
section or maybe the head, even if the reloc data is applied after the
link of vmlinux. While I still need to work out the details to supply
it with the data, I'm convinced its the best way to eliminate the extra
move of the kernel image. (My current guess is to count the
relocations on the first vmlinux and supply a dummy section of the
correct size that can be replaced with objcopy once the link is
complete).
If I don't get this done, we should change the build to just use the
slave hold loop from the kernel directly,
similar to what I put in kexec-tools with purgatory.
> PATCH 1:
> The difference is relocs.c is moved to arch/powerpc/boot from
> arch/powerpc/
>
> PATCH 2:
> Relocation build support is now 90% integrated with kernel build
> process. Earlier one has to run separately different make to build
> vmlinux.reloc image. Required linker scripts are moved to
> arch/powerpc/boot from arch/powerpc
vmlinux-reloc.scr was missing. I found it in v2. Also, I had to find
it in $(srctree)/$(src) since it is not generated like lds files.
>
> PATCH 3:
> The difference is reloc_apply.S is moved to arch/powerpc/boot from
> arch/powerpc/
>
> PATCH 4:
> Enough care is taken when creating bolted mapping for kdump kernel.
> Now it creates bolted mapping from 32MB to of size "crash kernel size"
> in case of crash kernel.
The patch does not apply anymore because create_trampoline has changed.
There seem to be way too many places we have RELOC and the relocation
offset applied. While I expected the uses of PHYSICAL_OFFSET and
existing uses of CONFIG_CRASH_DUMP, there seem to be lots of other
changes, and to me it feels like trying to make up for missing
relocation processing with code. That is precisely what we were trying
to avoid when we selected the emit_relocs and process them approach.
I might give another go at using the existing patches, but if you
rediff, can you sepearte patch 4 into two parts, one that does stuff
around PHYSICAL_START or CRASH_DUMP, and one that does the rest?
Thanks,
milton
^ permalink raw reply
* Re: going to OLS?
From: Robin H. Johnson @ 2008-07-18 16:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4313E14A-C3FB-4996-B188-767704F380C3@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
On Fri, Jul 18, 2008 at 08:35:36AM -0500, Kumar Gala wrote:
> Since OLS is next week I figured I see who around here is going.
>
> I'm always interested in putting faces to names and having a lively
> discussions over beer.
>
> So if your headed to OLS respond to this thread and maybe we'll have an
> inform PPC BoF @ a pub.
I'll be there, arriving on Monday evening.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] fs_enet: MDIO on GPIO support
From: Jeff Garzik @ 2008-07-18 17:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, netdev, Vitaly Bordug, Scott Wood
In-Reply-To: <E7FD62BF-C2BB-4803-87AB-91DD7AB8FD0C@kernel.crashing.org>
Kumar Gala wrote:
>
> On Jul 18, 2008, at 4:26 AM, Laurent Pinchart wrote:
>
>> On Thursday 26 June 2008, Vitaly Bordug wrote:
>>> On Thu, 26 Jun 2008 13:21:23 +0200
>>> Laurent Pinchart <laurentp@cse-semaphore.com> wrote:
>>>
>>>>> There should be no dependencies. When the OF GPIO support is not
>>>>> selected linux/of_gpio.h will define of_get_gpio() as a stub, so the
>>>>> fs_enet driver will fall back to the legacy binding.
>>>>
>>>> Have we reached a consensus on which tree the patch should go to ?
>>> I think it should go through powerpc tree, not seeing too much
>>> netdev-generic stuff in here. If noone will object, Kumar will pick
>>> it up I
>>> guess...
>>
>> Kumar, could you pick it up ? I'd like to see this in 2.6.27.
>>
>> Best regards,
>
> Jeff said he applied both to his tree already.
Yep, it's already in davem's net-next...
Jeff
^ permalink raw reply
* Re: Calling the kernel from a mini-bootloader
From: Milton Miller @ 2008-07-18 17:47 UTC (permalink / raw)
To: David Gibson; +Cc: ppcdev, Guillaume Dargaud
In-Reply-To: <20080718034727.GF18748@yookeroo.seuss>
On Jul 17, 2008, at 10:47 PM, David Gibson wrote:
> On Thu, Jul 17, 2008 at 11:14:11AM -0500, Milton Miller wrote:
>> On Thu Jul 17 at 23:22:28 EST in 2008, Guillaume Dargaud wrote:
> [snip]
[more snip]
>> We call this the flattened device tree.
>
> Your firmware doesn't have to deal with this though, although it can.
> It's perfectly acceptable - in fact I'd mildly recommend it over doing
> this in the firmware - to instead have the kernel's zImage wrapper
> supply the flattened device tree, folding information it needs to get
> from the firmware into it.
I thought about adding a section on which to recommend or talk about
the tradeoffs, but got hungry and hit send before going to lunch.
Yes, I the zImage choice is definitely the least amount of code to
write, and is a good tradeoff to get future upgradability. It may not
be the absolute fastest split of the work to start the kernel but it is
reasonably good, especially as it will decompress the kernel to its
run-time destination.
milton
^ permalink raw reply
* Re: [RFC v3 PATCH 4/4] Relocation support
From: Segher Boessenkool @ 2008-07-18 17:48 UTC (permalink / raw)
To: mohan; +Cc: ppcdev, paulus, miltonm
In-Reply-To: <20080717184843.GE25070@in.ibm.com>
> This patch changes all LOAD_REG_ADDR macro calls to LOAD_REG_IMMEDIATE
> to make sure that we load the correct address.
Did you figure out _why_ LOAD_REG_ADDR doesn't work? Using
LOAD_REG_IMMEDIATE is actually a step back, it makes the kernel
binary non-PIC. And LOAD_REG_ADDR _should_ work just fine with
your scheme.
Segher
^ permalink raw reply
* Re: [PATCH v3] elf loader support for auxvec base platform string
From: Nathan Lynch @ 2008-07-18 18:28 UTC (permalink / raw)
To: John Reiser; +Cc: linux-kernel, linuxppc-dev, Andrew Morton, torvalds, roland
In-Reply-To: <487FD74C.4080603@BitWagon.com>
John Reiser wrote:
> Andrew Morton wrote:
> > On Thu, 17 Jul 2008 17:19:32 -0500
> > Nathan Lynch <ntl@pobox.com> wrote:
> >
> >
> >> [snip]
> >> A new aux vector entry, AT_BASE_PLATFORM, will denote the actual hardware.
> [snip]
>
> > OK.
> >
> > But it conflicts directly with the already-queued
> > execve-filename-document-and-export-via-auxiliary-vector.patch
Okay, I can rebase on -mm.
> It seems to me that most of the patch conflicts are mechanical
> and could be merged mechanically.
>
> However I believe that the documentation change to this comment is important:
> -----
> > #ifdef __KERNEL__
> > -#define AT_VECTOR_SIZE_BASE (14 + 2) /* NEW_AUX_ENT entries in auxiliary table */
> > +#define AT_VECTOR_SIZE_BASE 17 /* NEW_AUX_ENT entries in auxiliary table */
> > + /* number of "#define AT_.*" above, minus {AT_NULL, AT_IGNORE, AT_NOTELF} */
> > #endif
> -----
> I scratched my head for a while to figure out that AT_NOTELF also was
> a subtraction as far as AT_VECTOR_SIZE_BASE was concerned.
John, from your patch:
+#define AT_EXECFN 31 /* filename of program */
How did you arrive at 31 for the value of AT_EXECFN? I haven't been
able to find out how AT_* values are "allocated", or what the reason
is for the gap between AT_SECURE and AT_SYSINFO.
^ permalink raw reply
* Re: how to allocate 9MB of memory in kernel ?
From: Arnd Bergmann @ 2008-07-18 15:39 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Misbah khan
In-Reply-To: <18525063.post@talk.nabble.com>
On Friday 18 July 2008, Misbah khan wrote:
> Now my concern is How can i map SDRAM one to one to circular buffer of such
> a huge size ????
As I mentioned, use vmalloc to get the memory, and provide an mmap function
that uses remap_vmalloc_range to put it into the user address space.
> My idea is that i will ioreamp SDRAM and do memcpy_toio() when ever i am
> writing to the the circular buffer which is dma allocated and pages are set
> reserved . and read the frame from user space .
ioremap and memcpy_toio style accesses only make sense for stuff that is
*not* your main memory. Memory is alrady directly accessible in the kernel
after allocating with get_free_pages, kmalloc or vmalloc. No need to
play with __iomem pointers for this.
Arnd <><
^ permalink raw reply
* Re: Calling the kernel from a mini-bootloader
From: Milton Miller @ 2008-07-18 18:38 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: ppcdev, John Linn, David Gibson
In-Reply-To: <02ec01c8e8b2$52717890$ad289e86@LPSC0173W>
On Fri Jul 18 18:43:11 EST 2008, Guillaume Dargaud wrote:
> Hello Milton and David, thanks for the answers.
>> This is a very reasonable approach, and is quite similar to what
>> I do.
> Makes me feel better !!!
>
>> You actually have a few choices. You can put just the loaded
>> data, or you can put the elf file and parse the header in your
>> boot loader.
> I cannot do that for memory constrains. I have 4Mb in the flash for the
> kernel and only a few Kb for the eprom of the bootloader. Also the
> idea is
> to sometimes update the kernel but basically never the bootloader.
Then the zImage approach is definitly the way to go. Actually, dtbImage
now, because you want the device tree to be compiled and linked into it.
(It only took me 33 lines of assembly, and 6 were labels or blank, to
skip over the elf header -- the vmlinux and zImage don't require they be
moved into a specific place - but keeping it just a binary blob is
fine).
>> After seeing the advantages, I would keep the elf
>> header. One big advantage of keeping the elf header is you can
>> see how much data will be zeroed for bss when the kernel starts.
>> Another choice is rather than loading the kernel, build a zImage
>> of some kind (see the code in arch/powerpc/boot). This way the
>> kernel code and static data is compressed. I often see a 3-fold
>> reduction in size. You can also attach an initrd, should you
>> decide to use initramfs later. More o this below.
>
> I'm not too familiar with the sequence of events that unfolds when the
> kernel start.
> The JTAG debugger copies the kernel at a given address. A program
> dumps a
> copy of that address range in flash. A bootloader does the reverse and
> launches it, so it shouldn't really matter what form the kernel takes,
> as
> long as the original _did_ work.
Ok, should not be a problem. You will want the wrapper code to create a
flat binary image, so have your platform set the binary variable like
cuboot. Whatever you specify for your platform file will be linked at
the beginning of the image.
When choosing where to laod the zImage into memory, you should consider
that the linked kernel size (including its bss) needs to fit below the
load address, and the extracted device tree and random malloc heap
normally
reside the wrapper.
>
>> Ahh ... you are still on ppc. Please note that we just merged
>> the removal of arch/ppc, everyone needs to use powerpc now. The
> Yes, my code works on the ML405, now I'm just trying to get it to work
> on
> our custom board... I haven't been able to follow closely the
> PPC/PowerPC
> change but it got me worried so I stopped updating at 2.6.15. I'm
> using the
> Xilinx git tree because I rely on a lot of their drivers, so I don't
> know if
> the change will be seemless. From the change of xparameters.h to and
> entirely different device description method, I'd say I'm not ready to
> take
> the jump.
>
> Any Xilinx user care to comment on that ?
I'm not a user, but from reading the list, they have integrated creating
the dts file into their build system.
>
> And I'm supposed to release the alpha version of our code today !!!
>
>> good news is: its easier to state the requirements, and its
> Hmmm...
>
>> easier to share the code in vmlinux. The bad news is you have to
>> follow the rules for passing data to the kernel. Its not hard.
>> We have defined a data structure that is parsed to become a tree
>> of data describing the machine, and based the contents on open
>> firmware. We call this the flattened device tree.
> Our firmware is custom VHDL code. I'll go ask the 'tronics guy if it
> fits
> open firmware requirements, but I'd be surprised.
I'm sure your firmware does not presently create this tree, but
the dtbImage format is designed to be a delivery vehicle for it.
>
>> Please read Documentation/powerpc/booting-without-of for more
> Will do. Last update is 2005. Is this still relevant ?
That's might be the last time we changed the structure of the tree,
but we have been updating the definition of what goes into the tree
structure pretty much every month since then. In the 2.6.27 kernel,
I think we started breaking out these descriptions into the
dts-bindings directory tree.
>
>> I will point out the minimal rom image I did for qemu where the
>> device tree is linked into the assembly, the kernel elf file is
>> already loaded, but I had to copy the nvram data serially into
>> ram and then poke the memory size and initrd location into the
>> device tree.
>
> Maybe I can just use an elementary approach like that: have the
> bootloader
> write a single byte with the jumper positions somewhere in RAM, and
> then
> have the kernel read it to use for the Mac address. With the flat
> addressing
> it could work if there aren't built-in securities.
We are happy for you to read such information in the zImage (or
dtbImage).
In fact we have a hook "fixups" that is the designated place for this to
happen. If the location to read the jumper is well defined, I would
suggest doing all of it from your fixup function, you don't need to save
the jumper position in ram (less code for your bootloader, and probably
a simpler handoff). (Needing the mac address does mean you can't use
the
simpleboot.c).
Hope you find these comments helpful,
milton
^ permalink raw reply
* 32-bit kernel on PPC64 supported?
From: Marvin @ 2008-07-18 18:43 UTC (permalink / raw)
To: linuxppc-dev
Hi,
while trying to cleanup some configs/makefiles for ppc64 I noticed, that
CONFIG_POWER4 implies CONFIG_PPC64 and vice versa in all defconfigs.
So I want to boldly replace CONFIG_POWER4 by CONFIG_PPC64 - ugh.
However, there are some constructs like:
#ifndef CONFIG_PPC64
...
#ifdef CONFIG_POWER4
...
#endif
...
#endif /* CONFIG_PPC64 */
in which POWER4 is always undefined, e.g. in
include/asm-powerpc/mmu_context.h. Maybe this is a leftover from times, where
64-bit kernels where not supported on Powermacs. Is this 32-bit support still
necessary?
Greetings
Marvin
^ permalink raw reply
* Re: going to OLS?
From: Sean MacLennan @ 2008-07-18 19:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4313E14A-C3FB-4996-B188-767704F380C3@kernel.crashing.org>
On Fri, 18 Jul 2008 08:35:36 -0500
"Kumar Gala" <galak@kernel.crashing.org> wrote:
> Since OLS is next week I figured I see who around here is going.
>
> I'm always interested in putting faces to names and having a lively
> discussions over beer.
>
> So if your headed to OLS respond to this thread and maybe we'll have
> an inform PPC BoF @ a pub.
I won't be going to OLS :( I couldn't get the time off, but I live in
Ottawa and would be very interested in an a PPC BoF :D
I generally telecommute, so lunchtime or evening would be fine.
Cheers,
Sean
^ permalink raw reply
* Re: going to OLS?
From: Sean MacLennan @ 2008-07-18 19:32 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev list
In-Reply-To: <20080718163338.D87BF2488A@gemini.denx.de>
On Fri, 18 Jul 2008 18:33:38 +0200
"Wolfgang Denk" <wd@denx.de> wrote:
> BTW: will there a pre-OLS beer evening on Tuesday, or will Stefan and
> me have to sit alone in some bar?
I'm up for a pre-OLS beer evening!
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches DTS
From: Victor Gallardo @ 2008-07-18 19:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20080716073913.100d259a@zod.rchland.ibm.com>
> Could you convert this to a dts-v1 file please? All the in-tree DTS
> files are dts-v1 and I'd very much like to keep it that way.
OK. Will look into this. I used the glacier.dts file as a base line. Is the
glacier.dts file in dts-v1 format?
> <snip>
> If this is a dual-460GT, why is there only one CPU node listed? Is it
> simply because Linux will only see one CPU as it is an AMP
> configuration?
Yes, the board is a dual processor board with each processor providing
independent resources. Each CPU will boots up with its own Linux image.
Victor Gallardo
--
View this message in context: http://www.nabble.com/-PATCH--Add-AMCC-Arches-DTS-tp18480767p18536319.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Add AMCC Arches DTS
From: Jon Loeliger @ 2008-07-18 19:42 UTC (permalink / raw)
To: Victor Gallardo; +Cc: linuxppc-embedded
In-Reply-To: <18536319.post@talk.nabble.com>
Victor Gallardo wrote:
> I used the glacier.dts file as a base line. Is the
> glacier.dts file in dts-v1 format?
Does it start with a /dts-v1/ declaration?
jdl
^ permalink raw reply
* Re: going to OLS?
From: Geoff Levand @ 2008-07-18 19:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <4313E14A-C3FB-4996-B188-767704F380C3@kernel.crashing.org>
Kumar Gala wrote:
> So if your headed to OLS respond to this thread and maybe we'll have
> an inform PPC BoF @ a pub.
I will go.
-Geoff
^ permalink raw reply
* Re: going to OLS?
From: Nick @ 2008-07-18 20:09 UTC (permalink / raw)
To: linuxppc-dev list
I too live in Ottawa and would be interested in sharing a beer with an a
PPC developers. If you have a rough idea of numbers, maybe I can help
in recommend a place for the gathering.
Nick
^ permalink raw reply
* Re: [PATCH v3] elf loader support for auxvec base platform string
From: John Reiser @ 2008-07-18 20:31 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linux-kernel, linuxppc-dev, Andrew Morton, torvalds, roland
In-Reply-To: <20080718182850.GO9594@localdomain>
Nathan Lynch wrote:
> +#define AT_EXECFN 31 /* filename of program */
>
> How did you arrive at 31 for the value of AT_EXECFN? I haven't been
> able to find out how AT_* values are "allocated", or what the reason
> is for the gap between AT_SECURE and AT_SYSINFO.
The numbers are chosen by experience, taste, and fiat.
Hopefully new choices do not conflict with existing ones,
but there is no formal "issuing authority."
In history the auxiliary vector has been not well standardized
and many times has been hidden from view of applications, although some
SysV-based systems have made it visible as a fourth argument to main().
Linux has /proc/pid/auxv, although the implementation suffers
from being exposed to overwriting by the user. From long experience
at virtualization in user mode, I favor better access, more use,
and better understanding of what the auxiliary vector provides.
AT_SYSINFO at 32 was chosen to avoid conflicts with [0,31]
partly on the theory that the first 32 might be considered
to be reserved for use across all UNIX-like systems,
while AT_SYSINFO definitely was Linux-specific.
I chose AT_EXECFN at 31 because I considered the concept
to be applicable to any system having execve(), even if AT_EXECFN
is not universally implemented. I had not seen any new tags
below 32 in a long time. The concept of AT_EXECFN allows
a nice interface for a virtualizer. The somewhat-related
AT_EXECFD already exists below 32.
Elsewhere, I've staked out use of a new AT_WINE_PRELOAD_INFO
at 30. Avoid that one, please. :-)
--
John Reiser, jreiser@BitWagon.com
^ permalink raw reply
* Re: [PATCH v3] elf loader support for auxvec base platform string
From: Andrew Morton @ 2008-07-18 20:52 UTC (permalink / raw)
To: John Reiser; +Cc: linux-kernel, linuxppc-dev, ntl, torvalds, roland
In-Reply-To: <4880FDA1.9070307@BitWagon.com>
On Fri, 18 Jul 2008 13:31:29 -0700
John Reiser <jreiser@BitWagon.com> wrote:
> Elsewhere, I've staked out use of a new AT_WINE_PRELOAD_INFO
> at 30. Avoid that one, please. :-)
The reliable way in which to reserve these numbers is to patch the
header file.
^ permalink raw reply
* Re: going to OLS?
From: Becky Bruce @ 2008-07-18 21:10 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev list, Gala Kumar
In-Reply-To: <20080718163338.D87BF2488A@gemini.denx.de>
On Jul 18, 2008, at 11:33 AM, Wolfgang Denk wrote:
> In message <20080718162731.GD10317@secretlab.ca> you wrote:
>>
>> If anybody wants to email me their cell phone # privately then I'll
>> collect a list and send it out to all the repliers to this thread.
>> That way you don't need to post your cell # to the mailing list for
>> the
>> world to see.
>
> BTW: will there a pre-OLS beer evening on Tuesday, or will Stefan and
> me have to sit alone in some bar?
Gosh, that would be so sad :)
I'll probably be available - have to go to FSL's Ottawa site during
the day, and might get pulled into dinner, but I hope to be free after
that. Kumar's in the same boat AFAIK.
If someone can pick a place and time, and just announce it, maybe we
can all hook up. I'd give it a go, but I've only been to Ottawa once,
and I'm afraid my drinking habits during said trip left me with
unreliable memories of drinking establishments :)
Cheers,
B
^ 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