* .tc entries question
From: Jonathan Bartlett @ 2006-08-09 13:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060725140634.GH6872@bubble.grove.modra.org>
Another 64-bit Elf question, this one about the TOC. In many examples,
for defining toc entries, there is some syntax like this:
name_to_refer_to_this:
.tc seemingly_unused_name[TC], data_here
I haven't figured out what the purpose of the name immediately preceding
[TC] is. In fact, it seems that in most cases it can simply be left out.
Is this just a holdover from a previous binary format, or does
"seemingly_unused_name" actually get used in some fashion?
Thanks,
Jon
^ permalink raw reply
* Re: [PATCH 4/6] ehea: header files
From: Arnd Bergmann @ 2006-08-09 13:17 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, netdev, linux-kernel, Christoph Raisch, Marcus Eder
In-Reply-To: <44D99F56.7010201@de.ibm.com>
On Wednesday 09 August 2006 10:39, Jan-Bernd Themann wrote:
> +extern int ehea_trace_level;
> +
> +#ifdef EHEA_NO_EDEB
> +#define EDEB_P_GENERIC(level, idstring, format, args...) \
> +=A0=A0=A0=A0=A0=A0=A0while (0 =3D=3D 1) { \
> +=A0=A0=A0=A0=A0=A0=A0 =A0 =A0if(unlikely (level <=3D ehea_trace_level)) =
{ \
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0pri=
ntk("%s " idstring " "format "\n", \
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0__func__, ##args); \
> +=A0=A0=A0=A0=A0=A0=A0 =A0} \
> +=A0=A0=A0=A0=A0=A0=A0} \
> +
> +#else
> +
> +#define EDEB_P_GENERIC(level,idstring,format,args...) \
> +if (level < KEEP_EDEBS_BELOW) { \
> +=A0=A0=A0=A0=A0=A0=A0do { \
> +=A0=A0=A0=A0=A0=A0=A0 =A0 =A0if(unlikely (level <=3D ehea_trace_level)) =
{ \
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0pri=
ntk("%s " idstring " "format "\n", \
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0__func__, ##args); \
> +=A0=A0=A0=A0=A0=A0=A0 =A0} \
> +=A0=A0=A0=A0=A0=A0=A0} while (1 =3D=3D 0); \
> +}
> +#endif
> +
> +#define EDEB(level, format, args...) \
> + =A0 =A0 =A0 =A0EDEB_P_GENERIC(level, "", format, ##args)
> +
> +#define EDEB_ERR(level, format, args...) \
> + =A0 =A0 =A0 =A0EDEB_P_GENERIC(level, "EHEA_ERROR", format, ##args)
> +
> +#define EDEB_EN(level, format, args...) \
> + =A0 =A0 =A0 =A0EDEB_P_GENERIC(level, ">>>", format, ##args)
> +
> +#define EDEB_EX(level, format, args...) \
> + =A0 =A0 =A0 =A0EDEB_P_GENERIC(level, "<<<", format, ##args)
Please don't invent your own debugging macros. You can either use the
pr_debug/pr_info facility from <linux/kernel.h> or get rid of those
completely. The latter is probably preferred for most of your calls.
Arnd <><
^ permalink raw reply
* Re: .tc entries question
From: Alan Modra @ 2006-08-09 13:55 UTC (permalink / raw)
To: Jonathan Bartlett; +Cc: linuxppc-dev
In-Reply-To: <Pine.SUN.4.58.0608090611460.14141@eskimo.com>
On Wed, Aug 09, 2006 at 06:15:06AM -0700, Jonathan Bartlett wrote:
> Another 64-bit Elf question, this one about the TOC. In many examples,
> for defining toc entries, there is some syntax like this:
>
> name_to_refer_to_this:
> .tc seemingly_unused_name[TC], data_here
>
> I haven't figured out what the purpose of the name immediately preceding
> [TC] is. In fact, it seems that in most cases it can simply be left out.
> Is this just a holdover from a previous binary format, or does
> "seemingly_unused_name" actually get used in some fashion?
It is just a syntax we inherited from PowerPC64 XCOFF.
seemingly_unused_name and the bracketed class qualifier are completely
ingored.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Wolfgang Denk @ 2006-08-09 14:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1155122309.4040.94.camel@localhost.localdomain>
In message <1155122309.4040.94.camel@localhost.localdomain> you wrote:
>
> > Where should we place the sources for the OF Flat Device
> > Tree source files? They used to be in U-Boot, but that
> > isn't happening any more.
>
> Why ? While having device-tree's in zImages is good to handle firmwares
> that can't pass them, I still think that the proper thing to do is to
> have the firmware provide the DT to the kernel. Did Denk decide once for
> all against having DTs passed by uboot at all ? In which case, it's
> probably time to consider a fork...
Ben, you are mixing two things here.
I have nothing against U-Boot passing the DT to the kernel. On
contrary, if DT's are used, than I think this is how it should be
done.
It's just that I think that the DT *sources* should not be part of
the U-Boot soutrce tree, and that the DT should be in fact part of
the kernel images that gets booted by U-Boot.
This has been discussed before (see archives), and the agreement (?)
was to use U-Boot's multifile image format for this purpose, where
you can combine a Linux kenrel image with a DT image into one file
bootable by U-Boot.
Jon's question was where the source code of the DT should be placed.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is mind? No matter. What is matter? Never mind.
-- Thomas Hewitt Key, 1799-1875
^ permalink raw reply
* RE: Who cares about PReP?
From: Matt Sealey @ 2006-08-09 15:00 UTC (permalink / raw)
To: 'Paul Mackerras', linuxppc-dev
In-Reply-To: <17622.58559.879330.496619@cargo.ozlabs.ibm.com>
QEMU PPC implements a PReP system too.
Probably a good place to test without needing a real system.
However it's the kind of thing you'd want to throw a CHRP
ROM onto in the end, and forget PReP for emulation (after
all, nobody makes 'em anymore).
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
> -----Original Message-----
> From: linuxppc-dev-bounces+matt=genesi-usa.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+matt=genesi-usa.com@ozlabs.org]
> On Behalf Of Paul Mackerras
> Sent: Monday, August 07, 2006 8:59 AM
> To: linuxppc-dev@ozlabs.org
> Subject: Who cares about PReP?
>
> I started looking at moving the PReP code over to
> arch/powerpc. I am struck by how many ifdefs there are in
> there to set things up for particular individual PReP
> implementations. We can do better than that, I'm sure, but
> the issue becomes one of testing. The only PReP I have here
> is an RS/6000 43p-140.
>
> Who else has a PReP system and would be willing to do some
> testing and debugging? If so, what sort of PReP is it?
>
> Paul.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: SystemAce Driver.
From: sudheer @ 2006-08-09 15:06 UTC (permalink / raw)
To: Ameet Patil; +Cc: linuxppc-embedded
In-Reply-To: <44C4BE5B.3000002@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2431 bytes --]
Hello Ameet Patil
I am looking for linux kernel source 2.6.16 with system ace controller
support. I downloaded the linux-2.6.16 and linux-2.6.17-1 source from
kernel.org but could not find any files related to system ace
controller ( No xilinx_sysace directory in drivers/block/) . I have
checked penguinppc.org also but could not get it.
Can you please send to me the link where i could download the
linuxppc-2.6.16 source with system ace support.
Thanks & Regards
Sudheer
Ameet Patil wrote:
> Hi Raja,
> I have ported the Xilinx System ACE driver to 2.6 kernel. Find the
> latest one here:
> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>
> NOTE: this patch wouldn't work if you are using the TEMAC driver. In
> which case use the -after-TEMAC patch found in the patches folder above.
>
> Check the following discussions (threads) for more details:
> 1. "Xilinx SystemACE driver for 2.6"
> 2. "Xilinx BSP for linux 2.6"
> 3. "Kernel hangs after "Now booting the kernel"."
>
> cheers,
> -Ameet
>
> Raja Chidambaram wrote:
>
>> Hi all,
>> We are working on customized board with amcc 440SPe
>> processor & xilinx System Ace controller. The System
>> Ace controller is connected to compact flash driver.
>>
>> We use u-boot 1.2 as bootloader & linux kernel
>> 2.6.16-2.
>>
>> On the process the u-boot is able to detect compact
>> flash through Xilinx SystemAce controller & able to
>> load the kernel image into compact flash.But when the
>> linux boot's up it not able to detect the System Ace
>> controller or compact flash.
>>
>> Note:we need to have the root file system in compact
>> flash.
>>
>> Is their any drivers available for SystemAce
>> controller on linux 2.6,if their how to get it.please
>> help me in this
>> with regards
>> raja
>>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
[-- Attachment #2: Type: text/html, Size: 3351 bytes --]
^ permalink raw reply
* [PATCH] Offer PCI as a CONFIG choice for PPC_86xx.
From: Jon Loeliger @ 2006-08-09 15:37 UTC (permalink / raw)
To: linuxppc-dev
Also fix 80-column run-over.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
I misspoke myself on the earlier, ill-formed version of this patch. :-)
arch/powerpc/Kconfig | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 13e583f..abb325e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -836,9 +836,10 @@ config MCA
bool
config PCI
- bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_MPC52xx || (EMBEDDED && PPC_ISERIES) \
- || MPC7448HPC2
- default y if !40x && !CPM2 && !8xx && !APUS && !PPC_83xx && !PPC_85xx && !PPC_86xx
+ bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
+ || PPC_MPC52xx || (EMBEDDED && PPC_ISERIES) || MPC7448HPC2
+ default y if !40x && !CPM2 && !8xx && !APUS && !PPC_83xx \
+ && !PPC_85xx && !PPC_86xx
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx && APUS
default PCI_QSPAN if !4xx && !CPM2 && 8xx
help
^ permalink raw reply related
* Re: [PATCH] update {g5,iseries,pseries}_defconfigs
From: Benjamin Herrenschmidt @ 2006-08-09 15:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <44D8A33D.6070000@sipsolutions.net>
On Tue, 2006-08-08 at 16:44 +0200, Johannes Berg wrote:
> Will Schmidt wrote:
> > For G5, I've enabled SND_AOA and friends as
> > modules; this includes the FABRIC_LAYOUT, ONYX, TAS, TOONIE and
> > SOUNDBUS* config options.
> >
> Great, thanks.
>
> Another thing I didn't think about earlier: does Apple ship any G5s that
> are old enough to not have a layout_id in their device tree? I'm not
> aware of any. If not, you might want to disable CONFIG_SND_POWERMAC for g5.
None.
Ben.
^ permalink raw reply
* Re: boot problems on pseries
From: Benjamin Herrenschmidt @ 2006-08-09 15:37 UTC (permalink / raw)
To: Mark Fasheh; +Cc: linuxppc-dev
In-Reply-To: <20060809013609.GA10876@ca-server1.us.oracle.com>
On Tue, 2006-08-08 at 18:36 -0700, Mark Fasheh wrote:
> Hello,
> So I do most of my work on some IBM JS20 powerpc blades. They
> usually run a git kernel on a stock RHEL4 distribution. The contents of
> /proc/cpuinfo is:
>
> processor : 0
> cpu : PPC970, altivec supported
> clock : 1600.000000MHz
> revision : 2.2 (pvr 0039 0202)
>
> processor : 1
> cpu : PPC970, altivec supported
> clock : 1600.000000MHz
> revision : 2.2 (pvr 0039 0202)
>
> timebase : 199837651
> platform : pSeries
> machine : CHRP IBM,8842-21X
>
>
> Recently, I discovered that newer kernels would no longer fully boot.
> There's no oops or panic message and they get through most of the kernel
> initialization before simply hanging. I spent some quality time today with
> git-bisect, and traced the badness down to this commit:
I'm just back from vacation and looking into this.
Ben.
^ permalink raw reply
* Re: [PATCH][0/2] RTAS MSI
From: Benjamin Herrenschmidt @ 2006-08-09 15:38 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1155090210.7087.4.camel@localhost.localdomain>
> So this might lead to the state where the card has been configured to
> use x MSIs, but we only tell the driver about 1 of them. I don't know
> enough PCI to grok if that's going to be a problem.
It probably will
Ben.
^ permalink raw reply
* Re: [PATCH][0/2] RTAS MSI
From: Benjamin Herrenschmidt @ 2006-08-09 15:41 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1155119228.6949.24.camel@localhost.localdomain>
> So I think we could have pci_enable_msi(dev), which would enable a
> single MSI _or_ MSI-X vector, depending on what's available. That'd be
> used by drivers that just want a simple replacement for LSI. And then
> pci_enable_multi_msi(dev, num_irqs) which would give the driver num_irqs
> MSI or MSI-X vectors.
You cannot lie and have pci_enable_msi() enable an MSI-X vector. Some
cards need additional tweaking when enabling MSI or MSI-X and if the
system enables MSI-X while the driver thinks it's MSI, bad things might
happen.
pci_enable_msi() should call the firmware to reconfigure for only one
MSI and enable just that. MSI-X is the only really sexy thing anyway
(that and a way to spread MSI-X accross CPUs from the kernel but that's
another topic)
Ben.
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Benjamin Herrenschmidt @ 2006-08-09 16:05 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060809140336.9E3C93535D4@atlas.denx.de>
> It's just that I think that the DT *sources* should not be part of
> the U-Boot soutrce tree, and that the DT should be in fact part of
> the kernel images that gets booted by U-Boot.
Fair enough, I misunderstood.
> This has been discussed before (see archives), and the agreement (?)
> was to use U-Boot's multifile image format for this purpose, where
> you can combine a Linux kenrel image with a DT image into one file
> bootable by U-Boot.
Well, I would still like something else. For example, I'm vendor NetFoo
selling network appliances (ADSL modems, routers, wireless APs, ...).
A certain amount of my products are based on a very similar chipset
provided by vendor NarrowCom, same core, same ethernet cell, though my
devices have subtle differences in the various varieties of those chips
used and what other chips are put around on the board.
I want my devices to have a firmware that pass a DT to the kernel. That
DT is bolted into the firmware. In fact, it could be separate flash
blocks (especially if the flash has some small blocks) from the actual
firmware code but that does not really matter.
That way, I can distribute and maintain a single kernel image update
package as part of my software update/maintainance solution.
Now you might argue that the way to work around that is to distribute a
vmlinux + DT files and have the "installer" merge them together at flash
time. I don't disagree... that works... if the kernel is in flash. It's
a bit more annoying once you start having it on a removable support
though...
It's not _the_ only solution but it's something that I think should be
considered.
Now as far as having an official repository for the .dts files of boards
supported by the kernel, I suppose indeed that the kenrel tree is an as
good location as anything else.
Cheers,
Ben.
^ permalink raw reply
* U-Boot on Xilinx ML403
From: Ming Liu @ 2006-08-09 16:07 UTC (permalink / raw)
To: linuxppc-embedded
Dear all,
Now I am trying to use u-boot to boot my Linux kernel image(2.6.16) using
tftp and then mount the file system using NFS in ML403 board. I am new to
u-boot. So can anyone suggest me some documents or reference designs about
u-boot on ML403? I know there is a reference from Xilinx called "getting
started with u-boot on the ml300". But I cannot configure the board as
ml403. Are there any patches needed? Any document about this topic is
appreciated. Thanks a lot for your help.
Regards
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: [PATCH 6/6] ehea: Kernel build (Kconfig / Makefile)
From: Olof Johansson @ 2006-08-09 16:33 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99F92.60407@de.ibm.com>
On Wed, Aug 09, 2006 at 10:40:50AM +0200, Jan-Bernd Themann wrote:
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>
>
> drivers/net/Kconfig | 6 ++++++
> drivers/net/Makefile | 1 +
> 2 files changed, 7 insertions(+)
>
>
>
> diff -Nurp -X dontdiff linux-2.6.18-rc4/drivers/net/Kconfig patched_kernel/drivers/net/Kconfig
> --- linux-2.6.18-rc4/drivers/net/Kconfig 2006-08-06 11:20:11.000000000 -0700
> +++ patched_kernel/drivers/net/Kconfig 2006-08-08 03:00:49.526421944 -0700
> @@ -2277,6 +2277,12 @@ config CHELSIO_T1
> To compile this driver as a module, choose M here: the module
> will be called cxgb.
>
> +config EHEA
> + tristate "eHEA Ethernet support"
> + depends on IBMEBUS
> + ---help---
> + This driver supports the IBM pSeries ethernet adapter
Does this adapter really not have a better name for the option
description? That's a very vague description given that IBM pSeries
machines have had all sorts of ethernet adapters through the years.
-Olof
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-09 16:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1155128205.3944.1.camel@zod.rchland.ibm.com>
On Wed, Aug 09, 2006 at 07:56:45AM -0500, Josh Boyer wrote:
> On Wed, 2006-08-09 at 13:18 +0200, Benjamin Herrenschmidt wrote:
> > On Tue, 2006-08-01 at 15:32 -0500, Jon Loeliger wrote:
> > > Folks,
> > >
> > > Where should we place the sources for the OF Flat Device
> > > Tree source files? They used to be in U-Boot, but that
> > > isn't happening any more.
> >
> > Why ? While having device-tree's in zImages is good to handle firmwares
> > that can't pass them, I still think that the proper thing to do is to
> > have the firmware provide the DT to the kernel. Did Denk decide once for
> > all against having DTs passed by uboot at all ? In which case, it's
> > probably time to consider a fork...
>
> We're only talking about the _source_ files. The .dts files. Not the
> binary trees themselves.
>
> The basic summary is that having a .dts in the kernel for every
> defconfig would be good. (I think that was the summary anyway.)
That's my understanding too. A 1-1 matching of default config files
and dts files kept in the kernel src trees. Any extra dts files would
be kept whereever dtc src is stored (i.e., jdl.com). I haven't heard
jdl agree to this, though. :)
Mark
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Jon Loeliger @ 2006-08-09 16:48 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
In-Reply-To: <20060809163839.GB17759@mag.az.mvista.com>
So, like, the other day "Mark A. Greer" mumbled:
> > We're only talking about the _source_ files. The .dts files. Not the
> > binary trees themselves.
> >
> > The basic summary is that having a .dts in the kernel for every
> > defconfig would be good. (I think that was the summary anyway.)
>
> That's my understanding too. A 1-1 matching of default config files
> and dts files kept in the kernel src trees.
And the keen observer who watches Paul's tree will have
noticed that the first DTS file, mpc8641_hpcn.dts, has already
been added to arch/powerpc/boot/dts!
> Any extra dts files
... of which there are none...
> ...would be kept whereever dtc src is stored (i.e., jdl.com).
> I haven't heard jdl agree to this, though. :)
Sure. No problem by me.
Though I do have a question WRT the notion of the libdt...
So, if I understand this proposal correctly, making libdt.a
would mean that we will now have to link the kernel against
this new, external dependency library. It would also mean
that we'd have to link U-Boot against this new, external
library as well.
Did I misunderstand or is everyone hip, jiggie and down with that?
jdl
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Mark A. Greer @ 2006-08-09 17:03 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E1GArEQ-0006OP-7H@jdl.com>
On Wed, Aug 09, 2006 at 11:48:34AM -0500, Jon Loeliger wrote:
> So, like, the other day "Mark A. Greer" mumbled:
> > > We're only talking about the _source_ files. The .dts files. Not the
> > > binary trees themselves.
> > >
> > > The basic summary is that having a .dts in the kernel for every
> > > defconfig would be good. (I think that was the summary anyway.)
> >
> > That's my understanding too. A 1-1 matching of default config files
> > and dts files kept in the kernel src trees.
>
> And the keen observer who watches Paul's tree will have
> noticed that the first DTS file, mpc8641_hpcn.dts, has already
> been added to arch/powerpc/boot/dts!
>
> > Any extra dts files
>
> ... of which there are none...
Yet...
> > ...would be kept whereever dtc src is stored (i.e., jdl.com).
> > I haven't heard jdl agree to this, though. :)
>
> Sure. No problem by me.
>
> Though I do have a question WRT the notion of the libdt...
>
> So, if I understand this proposal correctly, making libdt.a
> would mean that we will now have to link the kernel against
> this new, external dependency library. It would also mean
> that we'd have to link U-Boot against this new, external
> library as well.
>
> Did I misunderstand or is everyone hip, jiggie and down with that?
I thought the proposal was a master copy kept by you and then the
various users would copy it over when they wanted.
>From Hollis' email
(http://ozlabs.org/pipermail/linuxppc-embedded/2006-August/023882.htm):
"I think we should turn it into a library in the dtc source
tree. The various projects using it could then include snapshots
(to avoid dependencies)."
I think that means we copy.
Mark
^ permalink raw reply
* XUPV2P, which kernel 2.6. device drivers are available?
From: stevea-mdi @ 2006-08-09 18:02 UTC (permalink / raw)
To: linuxppc-embedded, benjamin.heyne
Thanks Benjamin,
I'd like to have your 10/100 MB xenet patch as well. I happen to be
working on this same driver this week.
-SteveA
^ permalink raw reply
* U-Boot on Xilinx ML403/patch for ml403&ml300 UBoot
From: stevea-mdi @ 2006-08-09 17:53 UTC (permalink / raw)
To: linuxppc-embedded
Ming Lui asks
>Are there any patches needed? Any document about this topic is
>appreciated. Thanks a lot for your help.
Yes. I'd recommend applying Ameet's patches at
http://www.linux.get2knowmore.com/
however you will still need to change a few macro lines for the
COMPACTFLASH addresses.
There is also a major error in the board_info structure. Someone
changed this data structure for the ml403 & ml300 so that it
no longer matches the UBoot form. The one in asm/ppcboot.h is
correct. Someone else asked about this back in June. So ....
diff -Naur linux-2.6.17-4.patch1/arch/ppc/platforms/4xx/xilinx_ml300.h linux-2.6.17-4.working/arch/ppc/platforms/4xx/xilinx_ml300.h
--- linux-2.6.17-4.patch1/arch/ppc/platforms/4xx/xilinx_ml300.h 2006-07-25 16:42:50.000000000 -0400
+++ linux-2.6.17-4.working/arch/ppc/platforms/4xx/xilinx_ml300.h 2006-08-02 19:47:00.000000000 -0400
@@ -19,14 +19,7 @@
#ifndef __ASSEMBLY__
#include <linux/types.h>
-
-typedef struct board_info {
- unsigned int bi_memsize; /* DRAM installed, in bytes */
- unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
- unsigned int bi_intfreq; /* Processor speed, in Hz */
- unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
- unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
-} bd_t;
+#include <asm/ppcboot.h>
/* Some 4xx parts use a different timebase frequency from the internal clock.
*/
diff -Naur linux-2.6.17-4.patch1/arch/ppc/platforms/4xx/xilinx_ml403.h linux-2.6.17-4.working/arch/ppc/platforms/4xx/xilinx_ml403.h
--- linux-2.6.17-4.patch1/arch/ppc/platforms/4xx/xilinx_ml403.h 2006-07-25 16:42:50.000000000 -0400
+++ linux-2.6.17-4.working/arch/ppc/platforms/4xx/xilinx_ml403.h 2006-08-02 19:46:46.000000000 -0400
@@ -23,14 +23,7 @@
#ifndef __ASSEMBLY__
#include <linux/types.h>
-
-typedef struct board_info {
- unsigned int bi_memsize; /* DRAM installed, in bytes */
- unsigned char bi_enetaddr[6]; /* Local Ethernet MAC address */
- unsigned int bi_intfreq; /* Processor speed, in Hz */
- unsigned int bi_busfreq; /* PLB Bus speed, in Hz */
- unsigned int bi_pci_busfreq; /* PCI Bus speed, in Hz */
-} bd_t;
+#include <asm/ppcboot.h>
/* Some 4xx parts use a different timebase frequency from the internal clock.
*/
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Andy Fleming @ 2006-08-09 18:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1155139501.17187.76.camel@localhost.localdomain>
On Aug 9, 2006, at 11:05, Benjamin Herrenschmidt wrote:
>> It's just that I think that the DT *sources* should not be part of
>> the U-Boot soutrce tree, and that the DT should be in fact part of
>> the kernel images that gets booted by U-Boot.
>
> Fair enough, I misunderstood.
>
>> This has been discussed before (see archives), and the agreement (?)
>> was to use U-Boot's multifile image format for this purpose, where
>> you can combine a Linux kenrel image with a DT image into one file
>> bootable by U-Boot.
>
> Well, I would still like something else. For example, I'm vendor
> NetFoo
> selling network appliances (ADSL modems, routers, wireless APs, ...).
>
> A certain amount of my products are based on a very similar chipset
> provided by vendor NarrowCom, same core, same ethernet cell, though my
> devices have subtle differences in the various varieties of those
> chips
> used and what other chips are put around on the board.
>
> I want my devices to have a firmware that pass a DT to the kernel.
> That
> DT is bolted into the firmware. In fact, it could be separate flash
> blocks (especially if the flash has some small blocks) from the actual
> firmware code but that does not really matter.
>
> That way, I can distribute and maintain a single kernel image update
> package as part of my software update/maintainance solution.
I think you'll find that the changes Matt McClintock made to u-boot
make this quite possible. The dtb is kept separate, and passed in by
u-boot. If those patches are acceptable, they provide what you
want. If they aren't acceptable, we'd be happy to make changes. We
just need to know, one way or another.
Andy
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Wolfgang Denk @ 2006-08-09 19:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1155139501.17187.76.camel@localhost.localdomain>
In message <1155139501.17187.76.camel@localhost.localdomain> you wrote:
>
> Well, I would still like something else. For example, I'm vendor NetFoo
> selling network appliances (ADSL modems, routers, wireless APs, ...).
...
> I want my devices to have a firmware that pass a DT to the kernel. That
> DT is bolted into the firmware. In fact, it could be separate flash
> blocks (especially if the flash has some small blocks) from the actual
> firmware code but that does not really matter.
>
> That way, I can distribute and maintain a single kernel image update
> package as part of my software update/maintainance solution.
Understood. Why not? Such a szeario has been discussed before, too.
Of course a split set of kernel and DT images has to be supported,
too. The proposed solution was to extend the "bootm" command to
accept a 3rd parameter, the DT address:
bootm <kernel_addr> <ramdisk_addr> <dt_addr>
<dt_addr> is optional, and '-' can be used when no ramdisk is used.
Something like that ...
> It's not _the_ only solution but it's something that I think should be
> considered.
Of course.
> Now as far as having an official repository for the .dts files of boards
> supported by the kernel, I suppose indeed that the kenrel tree is an as
> good location as anything else.
Fine. Thanks.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Microsoft Multimedia:
You have nice graphics, sound and animations when the system crashes.
^ permalink raw reply
* Re: SystemAce Driver.
From: Frank D Lombardo @ 2006-08-09 20:09 UTC (permalink / raw)
To: sudheer; +Cc: linuxppc-embedded
In-Reply-To: <44D9F9DF.5020100@gmail.com>
sudheer wrote:
> Hello Ameet Patil
>
> I am looking for linux kernel source 2.6.16 with system ace controller
> support. I downloaded the linux-2.6.16 and linux-2.6.17-1 source from
> kernel.org but could not find any files related to system ace
> controller ( No xilinx_sysace directory in drivers/block/) . I have
> checked penguinppc.org also but could not get it.
>
> Can you please send to me the link where i could download the
> linuxppc-2.6.16 source with system ace support.
>
> Thanks & Regards
> Sudheer
>
> Ameet Patil wrote:
>> Hi Raja,
>> I have ported the Xilinx System ACE driver to 2.6 kernel. Find the
>> latest one here:
>> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>>
>> NOTE: this patch wouldn't work if you are using the TEMAC driver. In
>> which case use the -after-TEMAC patch found in the patches folder above.
>>
>> Check the following discussions (threads) for more details:
>> 1. "Xilinx SystemACE driver for 2.6"
>> 2. "Xilinx BSP for linux 2.6"
>> 3. "Kernel hangs after "Now booting the kernel"."
>>
>> cheers,
>> -Ameet
>>
>> Raja Chidambaram wrote:
>>
>>> Hi all,
>>> We are working on customized board with amcc 440SPe
>>> processor & xilinx System Ace controller. The System
>>> Ace controller is connected to compact flash driver.
>>>
>>> We use u-boot 1.2 as bootloader & linux kernel
>>> 2.6.16-2.
>>>
>>> On the process the u-boot is able to detect compact
>>> flash through Xilinx SystemAce controller & able to
>>> load the kernel image into compact flash.But when the
>>> linux boot's up it not able to detect the System Ace
>>> controller or compact flash.
>>>
>>> Note:we need to have the root file system in compact
>>> flash.
>>>
>>> Is their any drivers available for SystemAce
>>> controller on linux 2.6,if their how to get it.please
>>> help me in this
>>> with regards
>>> raja
>>>
>>>
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam? Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>> _______________________________________________
>>> Linuxppc-embedded mailing list
>>> Linuxppc-embedded@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Sudheer,
You need to download the SystemAce patch and apply it to the 2.6.17.1
Kernel. The patch can be downloaded from:
http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
Save the patch to the root of the Kernel sources and run the following
command:
patch -p1 < linuxppc-2.6.17.1-sysace-1.2.patch
Frank
<http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch>
//
//
^ permalink raw reply
* Debugger suggestions
From: Jeff.Fellin @ 2006-08-09 20:33 UTC (permalink / raw)
To: linuxppc-embedded
Folks,
I have a coworker who is having a problem debugging a user-level program
on the power-pc. The program works correctly on a Redhat Linux i386
platform, but fails when writing to a socket on the power-pc, using Linux
2.4.18 (ancient, but unfortunately management doesn't agree with updating
the product). Have any of you been able to use a debugger naitively or
remotely with an embedded power-pc application?
Pointers to possible debuggers are greatly appreciated.
Jeff Fellin
RFL Electronics
Jeff.Fellin@rflelect.com
973 334-3100, x 327
^ permalink raw reply
* Re: Debugger suggestions
From: Andy Gospodarek @ 2006-08-09 20:51 UTC (permalink / raw)
To: Jeff.Fellin@rflelect.com; +Cc: linuxppc-embedded
In-Reply-To: <OF434A2D5E.5C955B36-ON852571C5.00707735@rflelect.com>
On 8/9/06, Jeff.Fellin@rflelect.com <Jeff.Fellin@rflelect.com> wrote:
>
> Folks,
> I have a coworker who is having a problem debugging a user-level program
> on the power-pc. The program works correctly on a Redhat Linux i386
> platform, but fails when writing to a socket on the power-pc, using Linux
> 2.4.18 (ancient, but unfortunately management doesn't agree with updating
> the product). Have any of you been able to use a debugger naitively or
> remotely with an embedded power-pc application?
I have used gdb natively and remotely on ppc without too much trouble.
You may need to temporarily load some extra shared-libraries on the
box to get gdb or gdbserver going, but it should be doable without too
much trouble.
>
> Pointers to possible debuggers are greatly appreciated.
>
> Jeff Fellin
> RFL Electronics
> Jeff.Fellin@rflelect.com
> 973 334-3100, x 327
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: regarding pci vga card output with powerpc
From: Andrey Volkov @ 2006-08-09 23:06 UTC (permalink / raw)
To: urwithsudheer; +Cc: linuxppc-embedded
In-Reply-To: <44D7097C.7040907@gmail.com>
urwithsudheer wrote:
> Hello All,
> I am working with a pci based vga card. I have connected the vga card
> next to the pci slot of my target processor on the baseboard.
> I have connected a monitor to the vga card.
> When i boot linux from minicom, i could see all the kernel log messages
> on both the minicom and vga card monitor. But on the vga monitor, i
> could not see any messages after asking for login as below:
> .
> .
>
> Mounting filesystems
> Running depmod
> Setting up networking on loopback device:
> Setting up networking on eth0:
> eth0: PHY is Marvell 88E11x1 (1410cc2)
> Adding static route for default gateway to 192.168.3.1:
> Setting nameserver to 192.168.0.1 in /etc/resolv.conf:
> Starting inetd:
>
> login:
>
>
> Though i am entering my login and passwd at the minicom, nothing comes
> on to the vga monitor. But i am able to write to vga monitor using the
> following commands from minicom:
>
> # echo "Hello" > /dev/tty1
> # echo "Hi " > /dev/tty1
> My requirement is to get on the vga monitor whatever i am typing on the
> minicom after logging into the linux like .
> ls or pwd commands.
>
> Anyone pl help me.
>
> Thanks & Regards
> Sudheer
>
See Documentation/kernel-parameters.txt.
If be short, add:
console=/dev/ttySxx console=/dev/tty1
(both) to a kernel parameters string.
--
Regards
Andrey
^ 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