* Re: AC Power handling broken for desktops
From: Benjamin Herrenschmidt @ 2005-08-25 5:08 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20050825045108.GA19792@suse.de>
On Thu, 2005-08-25 at 06:51 +0200, Olaf Hering wrote:
> On Thu, Aug 25, Benjamin Herrenschmidt wrote:
>
> > On Wed, 2005-08-24 at 13:54 +0200, Olaf Hering wrote:
> > > My G4/450 runs without AC Power, according to /proc/pmu/info:
> > >
> > > PMU driver version : 2
> > > PMU firmware version : 0c
> > > AC Power : 0
> > > Battery count : 0
> > >
> > > It should report 1. Where is the best place to get the
> > > PMU_PWR_AC_PRESENT into ac_line_status?
> >
> > Do we get the bit set from the PMU ? If not, maybe we should hard code
> > that value on non-laptops
>
> Appearently not, how do I check it?
Not sure :) I don't fully know how to decode those power things in the
device-tree... There are bits in darwin tho.
Ben
^ permalink raw reply
* Re: AC Power handling broken for desktops
From: Olaf Hering @ 2005-08-25 5:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1124946481.7906.8.camel@gaston>
On Thu, Aug 25, Benjamin Herrenschmidt wrote:
> Not sure :) I don't fully know how to decode those power things in the
> device-tree... There are bits in darwin tho.
Maybe just check for !PowerBook and force PMU_PWR_AC_PRESENT in this case.
^ permalink raw reply
* Re: AC Power handling broken for desktops
From: Benjamin Herrenschmidt @ 2005-08-25 5:34 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20050825051528.GB19792@suse.de>
On Thu, 2005-08-25 at 07:15 +0200, Olaf Hering wrote:
> On Thu, Aug 25, Benjamin Herrenschmidt wrote:
>
> > Not sure :) I don't fully know how to decode those power things in the
> > device-tree... There are bits in darwin tho.
>
> Maybe just check for !PowerBook and force PMU_PWR_AC_PRESENT in this case.
Yah, you can check that with pmac_feature, there is a "mobile" flag.
Ben
^ permalink raw reply
* Re: Source of xparameter_ml300.h
From: Grant Likely @ 2005-08-25 6:24 UTC (permalink / raw)
To: T Ziomek, linuxppc-embedded
In-Reply-To: <EDFB2B1ED0A1D7118A0A00065BF2490D1E3A601B@il06exm13>
On Wed, Aug 24, 2005 at 08:20:48PM -0500, T Ziomek wrote:
> On Wed, 24 Aug 2005 akonovalov@ru.mvista.com wrote:
> >
> >Grant Likely wrote:
> >But if you are speaking about the xparameters_ml300.h in the community
> >trees (linuxppc-2.4 and the 2.6 one from kernel.org), this file
> >is for the reference design by Xilinx:
> >
> >http://www.xilinx.com/ise/embedded/edk6_2docs/ml300_edk3.zip
>
> Also, be aware that the differences between 'xparameters.h' and
> 'xparameters_ml300.h' are not all you need to worry about.
>
>
> MontaVista's port to the ML300 also modified various Xilinx driver source
> files (the code that appears under .../ppc405_0/include and
> .../ppc405_0/libsrc, at least for me).
> Starting with MV's port to the ML300, you need to figure out which IP
> versions it was created for (for example, "emac_v1_00_b"). Then you need
> to compare that with the IP version used in your system [NOTE 1]. They'll
> probably be different, so then you need to either merge MV's changes into
> the newer Xilinx code or Xilinx's changes into the MV-modified drivers.
> This leaves you with software drivers that match the IP and have the chang-
> es needed to work in Linux.
Ah, yes. I was wondering how much grief I would be dealing with in that
regard. One of my goals is to get somewhat flexable drivers for basic
cores into mainline, so I'm sure I'll be fighting with this.
>
> It also looks like the Xilinx software driver bugs that MV found were
> not reported to Xilinx but just worked around, so those bugs are probably
> still present in your design. They were in ours...
Thank's for the heads up. Your email addr's getting a permanent place
in my address book. :)
>
>
> NOTE 1: And don't depend on Xilinx's rev numbers changing when their dri-
> ver code does. I regularly run across situations where consecu-
> tive FPGA designs both use, say, the "gpio_v2_00_a" IP and driver
> yet the driver code has changed. It is important that you 'diff'
> or whatever all of the driver code for changes each time you re-
> ceive a new FPGA design generated from an XPS with *any* changes
> at all (new version, patches, etc.), even if it appears that the
> patch should not affect any driver code.
Hmm, lovely.
>
>
> In the end, MV's port of Linux is to an ML300 with an old reference design
> (even though the ML300 *board* hasn't changed, if that's true). You're
> presumably using more current Xilinx tools and IP, so you'll have to update
> the port. And you'll probably have to do so repeatedly.
Ai, I expect so.
IMHO the mainline code should be as simple as possible to adapt to new
boards and their associated xparameters.h. I've created an xparameters
'abstraction layer' that keeps changes to the board more or less
isolated to the platform bus initialization data structures. It also
prevents having to recompile the world everytime I use a different
bitstream. However, that doesn't solve the changes to logic cores (as
you so eloquently pointed out). At the very least I'd like to get a set
of core drivers ported/written that use #defs to adapt to the
appropriate core version. I'll never be able to support every core
version, but I should be able to support a number of the more recent
cores.
The difficulty that I have with the current port is that there is still
a fair bit of work to adapt from one xparameters to another.
There is a very real possibilty that I'll be taking on
lots of v2pro work in the near future and I'd like to have a comfortable
foundation to start from.
>
>
> It's analagous to MV porting to the [non-FPGA] Acme RealCool rev A board
> while you're starting with the RealCool rev C and moving to revs D, E,
> etc. every few weeks or months.
> This -- the relatively rapid change of FPGA 'hardware' compared to the
> typically much slower changes to a board -- is a fundamental difference be-
> tween FPGA and non-FPGA-based systems that you have to deal with. I'm not
> sure MV fully comprehends the consequences of that; if they did I would ex-
> pect their port to document what specific IP versions it works with (not to
> mention what functionality wasn't ported, but that applies to non-FPGA
> hardware as well).
indeed
>
> Of course, even if they did that we'd still have to suffer Xilinx's tenden-
> cy to release multiple versions of things without changing their rev num-
> bers :-(
Yes, but we keep coming back because we love it.
s/love it/gluttons for punishment/
>
>
> I've been where you're going...
I feel a great sense of foreboding in that remark... Thanks for the
long response; good info.
Did you use a 2.4 or 2.6 kernel in your work? Are your driver changes
available for download anywhere?
Thanks,
g.
^ permalink raw reply
* Re: How to build an image for whole flash
From: Wolfgang Denk @ 2005-08-25 7:28 UTC (permalink / raw)
To: JohnsonCheng; +Cc: linuxppc-embedded
In-Reply-To: <20050825032128.D90A368110@ozlabs.org>
In message <20050825032128.D90A368110@ozlabs.org> you wrote:
>
> My flash is 16M that is mapping on 0xFF000000-0xFFFFFFFF.
> mtd0: 0xFF000000-0xFF1FFFFF Kernel
> mtd1: 0xFF200000-0xFF9FFFFF RootFS
> mtd2: 0xFFA00000-0xFFAFFFFF Config
> mtd3: 0xFFF00000-0xFFFFFFFF U-Boot
>
> Now I can build an image for mtd device, for example, dd if=/dev/mtd0
> of=kernel.img.
If you want to copy the image to flash, you got the parameters wrong,
i. e. you must use
dd if=kernel.img of=/dev/mtd0
(after erasing /dev/mtd0, of course); and using some bs= option may
speed up the prcedure a bit, too.
> But I don't know how to build a image for whole flash ?
What do you mean "for the whole flash"? If you cant to combine the 4
images into one big blob you can do so by (1) padding the images to
the full size of each partition; this can be done using appropriate
"bs=", "count=" and "conv=sync" parameters to dd; and (2)
concatenating the images using "cat".
But this is a prtty inefficient way, and you will also have to change
your MTD partitioning to provide a big partition which covers the
whole flash.
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
Some people march to the beat of a different drummer. And some people
tango!
^ permalink raw reply
* I2C STOP condition on MPC8245
From: Daniel Ann @ 2005-08-25 7:38 UTC (permalink / raw)
To: linuxppc-embedded
Hi folks,
Just wondering, if anyone tried i2c multi-master using mpc8245 with
kernel 2.6.x.
Thing is, version of kernel doesnt really matter, since I only have
problem getting mpc8245 to detect STOP condition sent by the
atmega64(the other i2c device).
Not knowing I2C that much, Im curious to know if mpc8245 should raise
an interrupt if it detects STOP condition sent by the master device.
I have no problem with i2c communication if mpc8245 is master, but
only when mpc8245 acts as slave, I cant detect the end of transfer.
If mpc8245 doesnt raise an interrupt when it detect STOP condition,
then how should program running on mpc8245 to know when to stop
reading ?
--=20
Daniel
^ permalink raw reply
* [PATCH] ppc32: disable IBM405_ERR77 and IBM405_ERR51 workarounds for 405EP
From: Eugene Surovegin @ 2005-08-25 7:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
Disable IBM405_ERR77 and IBM405_ERR51 errata workarounds for 405EP.
This chip has these problems fixed.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -152,13 +152,13 @@ config IBM440EP_ERR42
# All 405-based cores up until the 405GPR and 405EP have this errata.
config IBM405_ERR77
bool
- depends on 40x && !403GCX && !405GPR
+ depends on 40x && !403GCX && !405GPR && !405EP
default y
# All 40x-based cores, up until the 405GPR and 405EP have this errata.
config IBM405_ERR51
bool
- depends on 40x && !405GPR
+ depends on 40x && !405GPR && !405EP
default y
config BOOKE
^ permalink raw reply
* RE: How to build an image for whole flash
From: JohnsonCheng @ 2005-08-25 10:00 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
In-Reply-To: <20050825072853.99657352674@atlas.denx.de>
Yes. I add a MTD partition which include whole flash as following:
mtd0: 0xFF000000-0xFF1FFFFF Kernel
mtd1: 0xFF200000-0xFF9FFFFF RootFS
mtd2: 0xFFA00000-0xFFAFFFFF Config
mtd3: 0xFFF00000-0xFFFFFFFF U-Boot
mtd4: 0xFF000000-0xFFFFFFFF Flash
then "dd if=/dev/mtd4 of=flash.img".
Bu t I think it's not a good idea.
Thanks,
Johnson Cheng
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: Thursday, August 25, 2005 3:29 PM
To: JohnsonCheng
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: How to build an image for whole flash
In message <20050825032128.D90A368110@ozlabs.org> you wrote:
>
> My flash is 16M that is mapping on 0xFF000000-0xFFFFFFFF.
> mtd0: 0xFF000000-0xFF1FFFFF Kernel
> mtd1: 0xFF200000-0xFF9FFFFF RootFS
> mtd2: 0xFFA00000-0xFFAFFFFF Config
> mtd3: 0xFFF00000-0xFFFFFFFF U-Boot
>
> Now I can build an image for mtd device, for example, dd if=/dev/mtd0
> of=kernel.img.
If you want to copy the image to flash, you got the parameters wrong,
i. e. you must use
dd if=kernel.img of=/dev/mtd0
(after erasing /dev/mtd0, of course); and using some bs= option may
speed up the prcedure a bit, too.
> But I don't know how to build a image for whole flash ?
What do you mean "for the whole flash"? If you cant to combine the 4
images into one big blob you can do so by (1) padding the images to
the full size of each partition; this can be done using appropriate
"bs=", "count=" and "conv=sync" parameters to dd; and (2)
concatenating the images using "cat".
But this is a prtty inefficient way, and you will also have to change
your MTD partitioning to provide a big partition which covers the
whole flash.
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
Some people march to the beat of a different drummer. And some people
tango!
^ permalink raw reply
* COP Status 0x21
From: Andrew Williams @ 2005-08-25 14:38 UTC (permalink / raw)
To: linuxppc-embedded
Hello List..
(hope this is considered "on" topic)
Situation: New hardware (mcp8347)
BDI connected, but unable to read PVR
Prior to the READ I see a "COP status is 0x21"
=20
Q. What does a status of 0x21 mean?=20
Q. I've searched online for some type of a reference to the=20
COP interface to no avail. Can anyone direct me to=20
a technical reference?=20
Thanks,
Andrew
-- BDI Config [TARGET] section --
[TARGET]
CPUTYPE 8349 ;the CPU type
JTAGCLOCK 0 ;use 16 MHz JTAG clock
BOOTADDR 0xfff00100 ;boot address used for start-up
break
POWERUP 2000 ;start delay after power-up
detected in ms
WAKEUP 800 ;give reset time to complete
STARTUP RESET ;halt immediatelly at the boot
vector
BREAKMODE HARD ;SOFT or HARD, HARD uses PPC
hardware breakpoint
STEPMODE HWBP ;TRACE or HWBP, HWBP uses a
hardware breakpoint
-- BDI Debug Output --
- TARGET: waiting for target Vcc
- TARGET: processing power-up delay
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x00000001 =3D> 0x00000001
- Bypass check: 0x00000001 =3D> 0x00000001
- JTAG exists check passed
- COP status is 0x21
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- Target PVR is 0x00000000
- This PVR is not supported
- TARGET: Target PVR is 0x00000000
*** TARGET: resetting target failed
# PPC: This target is not supported
- TARGET: target will be restarted in 10 sec
^ permalink raw reply
* Re: AC Power handling broken for desktops
From: Segher Boessenkool @ 2005-08-25 15:10 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20050825051528.GB19792@suse.de>
>> Not sure :) I don't fully know how to decode those power things in the
>> device-tree... There are bits in darwin tho.
>
> Maybe just check for !PowerBook and force PMU_PWR_AC_PRESENT in this
> case.
Or just if battery count is 0, assume AC power ;-)
Segher
^ permalink raw reply
* RE: COP Status 0x21
From: Andrew Williams @ 2005-08-25 15:19 UTC (permalink / raw)
To: linuxppc-embedded
<insert favorite curses here>
Spend 6 hours searching, draft an email to the list, and solve=20
problem 20 minutes later. Compared my BDI to a co-workers and=20
and discovered that although we had the same firmware, we didn't have=20
the same "Logic" version in the device. Reflashed and I can=20
now read the PVR correctly.
Sorry to waste everyone's time on this.
Andrew
=20
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> Williams, Andrew [CAR:9D30:EXCH]
> Sent: August 25, 2005 10:38 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: COP Status 0x21
>=20
>=20
> Hello List..
> (hope this is considered "on" topic)
>=20
> Situation: New hardware (mcp8347)
> BDI connected, but unable to read PVR
> Prior to the READ I see a "COP status is 0x21"
> =20
> Q. What does a status of 0x21 mean?=20
>=20
> Q. I've searched online for some type of a reference to the=20
> COP interface to no avail. Can anyone direct me to=20
> a technical reference?=20
>=20
>=20
> Thanks,
> Andrew
>=20
> -- BDI Config [TARGET] section --
> [TARGET]
> CPUTYPE 8349 ;the CPU type
> JTAGCLOCK 0 ;use 16 MHz JTAG clock
> BOOTADDR 0xfff00100 ;boot address used=20
> for start-up
> break
> POWERUP 2000 ;start delay after power-up
> detected in ms
> WAKEUP 800 ;give reset time to complete
> STARTUP RESET ;halt immediatelly at the boot
> vector
> BREAKMODE HARD ;SOFT or HARD, HARD uses PPC
> hardware breakpoint
> STEPMODE HWBP ;TRACE or HWBP, HWBP uses a
> hardware breakpoint
>=20
>=20
> -- BDI Debug Output --
> - TARGET: waiting for target Vcc
> - TARGET: processing power-up delay
> - TARGET: processing user reset request
> - BDI asserts HRESET
> - Reset JTAG controller passed
> - Bypass check: 0x00000001 =3D> 0x00000001
> - Bypass check: 0x00000001 =3D> 0x00000001
> - JTAG exists check passed
> - COP status is 0x21
> - Check running state passed
> - BDI scans COP freeze command
> - BDI removes HRESET
> - Target PVR is 0x00000000
> - This PVR is not supported
> - TARGET: Target PVR is 0x00000000
> *** TARGET: resetting target failed
> # PPC: This target is not supported
> - TARGET: target will be restarted in 10 sec=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org=20
> https://ozlabs.org/mailman/listinfo/linuxppc-> embedded
>=20
>=20
^ permalink raw reply
* Re: COP Status 0x21
From: Grant Likely @ 2005-08-25 16:18 UTC (permalink / raw)
To: Andrew Williams, linuxppc-embedded
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B4049162C5@zcarhxm2.corp.nortel.com>
On Thu, Aug 25, 2005 at 11:19:31AM -0400, Andrew Williams wrote:
> <insert favorite curses here>
>
> Spend 6 hours searching, draft an email to the list, and solve
> problem 20 minutes later. Compared my BDI to a co-workers and
> and discovered that although we had the same firmware, we didn't have
> the same "Logic" version in the device. Reflashed and I can
> now read the PVR correctly.
>
> Sorry to waste everyone's time on this.
Ah, but the next person to have this problem (should) find your post
when they search. :)
^ permalink raw reply
* Re: Source of xparameter_ml300.h
From: T Ziomek @ 2005-08-25 22:17 UTC (permalink / raw)
To: Grant Likely; +Cc: T Ziomek, linuxppc-embedded
In-Reply-To: <20050825062425.GA5607@siegfried.thelikelysolution.ca>
On Thu, 25 Aug 2005, Grant Likely wrote:
> On Wed, Aug 24, 2005 at 08:20:48PM -0500, T Ziomek wrote:
>>
>> Also, be aware that the differences between 'xparameters.h' and
>> 'xparameters_ml300.h' are not all you need to worry about.
BTW, I took a approach different from MV's for 'xparameters.h'. Seeing no
reason why that file *had* to be changed for Linux (and because the folks
doing the Xilinx hardware releases I use only use the 'standalone' BSP and
hence never run that Tcl script), I instead added a 'linux.xparameters.h'
file. This file first includes 'xparameters.h' and then #defs all of the
Linux-specific stuff.
Then I changed all Linux #includes of 'xparameters.h' to pull in my new
file instead.
My 'linux.xparameters.h' hasn't changed since I created it Feb. 2, though
I've worked with a dozen or more 'xparameters.h' files in that time.
IMO, this two files approach is better all-around, with better separation
of concerns and no Tcl script.
>> Starting with MV's port to the ML300, you need to figure out which IP
>> versions it was created for (for example, "emac_v1_00_b"). Then you need
>> to compare that with the IP version used in your system [NOTE 1]. They'll
>> probably be different, so then you need to either merge MV's changes into
>> the newer Xilinx code or Xilinx's changes into the MV-modified drivers.
>> This leaves you with software drivers that match the IP and have the chang-
>> es needed to work in Linux.
>
> Ah, yes. I was wondering how much grief I would be dealing with in that
> regard. One of my goals is to get somewhat flexable drivers for basic
> cores into mainline, so I'm sure I'll be fighting with this.
I keep wanting to implement a "2 files" approach like that above for the
driver files. It's not as simple to do, and so far I keep enduring the
periodic hack session rather than investing time looking for a better solu-
tion.
Oh yeah, another minor type of change I had to deal with -- in cases where
a peripheral is on a different bus between the ML300 and our board I had to
make changes such as "OPB" -> "PLB". No big deal there, though I wonder if
it should really be necessary. Does Xilinx IP have significant bus-specific
differences (e.g. OPB EMAC vs. PLB EMAC)? I wouldn't expect so...
>> It also looks like the Xilinx software driver bugs that MV found were
>> not reported to Xilinx but just worked around, so those bugs are probably
>> still present in your design. They were in ours...
> Thank's for the heads up. Your email addr's getting a permanent place
> in my address book. :)
:-(
Just kidding; I've been meaning for months now to put this stuff out on the
maillist (partly because I'm way overdue on "giving back" and partly to see
if I was missing some obvious Easy Way).
>> NOTE 1: And don't depend on Xilinx's rev numbers changing when their dri-
>> ver code does. I regularly run across situations where consecu-
>> tive FPGA designs both use, say, the "gpio_v2_00_a" IP and driver
>> yet the driver code has changed. It is important that you 'diff'
>> or whatever all of the driver code for changes each time you re-
>> ceive a new FPGA design generated from an XPS with *any* changes
>> at all (new version, patches, etc.), even if it appears that the
>> patch should not affect any driver code.
> Hmm, lovely.
Don't get me started...
> IMHO the mainline code should be as simple as possible to adapt to new
> boards and their associated xparameters.h. I've created an xparameters
> 'abstraction layer' that keeps changes to the board more or less
> isolated to the platform bus initialization data structures. It also
> prevents having to recompile the world everytime I use a different
> bitstream. However, that doesn't solve the changes to logic cores (as
> you so eloquently pointed out). At the very least I'd like to get a set
> of core drivers ported/written that use #defs to adapt to the
> appropriate core version. I'll never be able to support every core
> version, but I should be able to support a number of the more recent
> cores.
>
> The difficulty that I have with the current port is that there is still
> a fair bit of work to adapt from one xparameters to another.
>
> There is a very real possibilty that I'll be taking on
> lots of v2pro work in the near future and I'd like to have a comfortable
> foundation to start from.
Exactly what I keep wanting to do. I expect you'll be glad you have it.
One thing I *did* do was completely remove Xilinx-sourced files (or files
based on Xilinx-supplied code) from the kernel tree. So things like
.../arch/ppc/platforms/xilinx_ocp and .../drivers/net/xilinx_enet/x* are not
used at all. In my thinking that stuff doesn't belong in the kernel tree
because it changes so often (again, the board vs. FPGA issue) (and I fully
expect to get re-educated, because I really don't know enough to spout off
about what should or shouldn't be in the kernel tree).
I did of course have to change Makefiles and the like to pull the neces-
sary headers and C from my (external to the kernel tree) 'ppc405_0' dir.
And it's not a complete solution; my ppc405_0 tree isn't accounted for when
Linux builds all of its dependencies so I have to remember when to delete
a certain subtree's *.[oa] files to force rebuilds.
Being a one-man band in a research group it works okay for me, but with-
out more work it certainly isn't scalable to a large team and wouldn't be
appropriate for product development.
>> I've been where you're going...
> I feel a great sense of foreboding in that remark... Thanks for the
> long response; good info.
>
> Did you use a 2.4 or 2.6 kernel in your work? Are your driver changes
> available for download anywhere?
So far we're using MV Pro 3.1, which is based on a 2.4 kernel. Pro 4.0 is
2.6 based and starting to become available; I haven't yet checked on the
PPC405 / ML300 port.
Working for A Big Corporation, I can't easily get my changes onto an FTP
site. I'll provide them on request instead, but note that I'll be out of
the office this Friday. Plus I'll have to doublecheck them for the proper
copyright & licensing notices. But still, next week should be no problem.
The files I've been modifying are
.../include/xbasic_types.h
.../include/xdma_channel.h [1]
.../include/xemac.h [1]
.../libsrc/dma_v*/src/xdma_channel_sg.c
.../libsrc/emac_v*/src/xemac.c
.../libsrc/emac_v*/src/xemac_g.c
.../libsrc/emac_v*/src/xemac_intr_dma.c
[1] : Since these two are duplicated within the driver tree (another peeve
of mine), I also delete .../libsrc/dma_v*/src/xdma_channel.h and
.../libsrc/emac_v*/src/xemac.h to avoid having to make the same
changes twice.
Descriptions of the specific changes made follow. I believe all but the
first are just re-applying changes MV made in their port to Linux.
.../include/xbasic_types.h
Make 'Xuint32' and 'Xint32' 'int's rather than 'long's.
.../include/xdma_channel.h
Add 'VirtPtr' and 'PhyPtr' elements to 'XDmaChannel' struct.
Add 'PhyPtr' arg to XDmaChannel_CreateSgList()'s signature.
.../include/xemac.h
Add 'PhysAddress' element to 'XEmac_Config' and 'XEmac' structs.
Add 'PhyPtr' arg to XEmac_SetSgRecvSpace()'s and XEmac_SetSgSendSpace()'s
signatures.
.../libsrc/dma_v*/src/xdma_channel_sg.c
Add P_TO_V() and V_TO_P() macros.
Add 'PhyPtr' arg to XDmaChannel_CreateSgList() and add setting of
'InstancePtr's 'VirtPtr' and 'PhyPtr' fields.
.../libsrc/emac_v*/src/xemac.c
Add setting of 'InstancePtr's 'PhysAddress' field in XEmac_Initialize().
.../libsrc/emac_v*/src/xemac_g.c
Init 'XYZ' struct's new 'PhysAddress' element.
.../libsrc/emac_v*/src/xemac_intr_dma.c
Pass 'PhysAddress' rather than 'BaseAddress' to XBufDescriptor_SetDestAd-
dress() in XEmac_SgSend()
Pass 'PhysAddress' rather than 'BaseAddress' to XBufDescriptor_SetSrcAd-
dress() in XEmac_SgRecv().
Add 'PhyPtr' arg to XEmac_SetSgRecvSpace() and pass it to XDmaChannel_Cre-
ateSgList().
Add 'PhyPtr' arg to XEmac_SetSgSendSpace() and pass it to XDmaChannel_Cre-
ateSgList().
Looking at my archived of hacked ppc405_0 trees it looks like I have the
following hacked driver directories: dma_v1_00_a, emac_v1_00_e, emac_v1_00_f
and emac_v2_00_c . Of course there's no certainty one 'dma_v1_00_a' is the
same as another...
That's it, for now.
Tom
--
/"\ ASCII Ribbon Campaign | Email to user 'CTZ001'
\ / | at 'email.mot.com'
X Against HTML |
/ \ in e-mail & news |
^ permalink raw reply
* Re: Source of xparameter_ml300.h
From: Grant Likely @ 2005-08-25 23:02 UTC (permalink / raw)
To: T Ziomek; +Cc: T Ziomek, linuxppc-embedded
In-Reply-To: <Pine.WNT.4.61.0508251610280.2688@holyoke.labs.mot.com>
On Thu, Aug 25, 2005 at 05:17:16PM -0500, T Ziomek wrote:
> On Thu, 25 Aug 2005, Grant Likely wrote:
> >On Wed, Aug 24, 2005 at 08:20:48PM -0500, T Ziomek wrote:
> >>
> >>Also, be aware that the differences between 'xparameters.h' and
> >>'xparameters_ml300.h' are not all you need to worry about.
>
> BTW, I took a approach different from MV's for 'xparameters.h'. Seeing no
> reason why that file *had* to be changed for Linux (and because the folks
> doing the Xilinx hardware releases I use only use the 'standalone' BSP and
> hence never run that Tcl script), I instead added a 'linux.xparameters.h'
> file. This file first includes 'xparameters.h' and then #defs all of the
> Linux-specific stuff.
> Then I changed all Linux #includes of 'xparameters.h' to pull in my new
> file instead.
>
> My 'linux.xparameters.h' hasn't changed since I created it Feb. 2, though
> I've worked with a dozen or more 'xparameters.h' files in that time.
>
> IMO, this two files approach is better all-around, with better separation
> of concerns and no Tcl script.
Yes! My opinion exactly. I'm doing pretty close to the same thing.
>
> [Lots of really great info snipped]
>
> >Thank's for the heads up. Your email addr's getting a permanent place
> >in my address book. :)
>
> :-(
:P
>
> Just kidding; I've been meaning for months now to put this stuff out on the
> maillist (partly because I'm way overdue on "giving back" and partly to see
> if I was missing some obvious Easy Way).
I'm going to be off work for the next 13 weeks (hooray!) on parental
leave. In that time I plan to get a bunch of this stuff cleaned up and
submitted to mainline. If you send me your patches then I'll get them
included in my tree. If it's too big to email then I'll setup a
location that you can scp it to.
That way we can both get credit
s/credit/blaimed/
:)
> [Lots more really great stuff snipped]
>
> That's it, for now.
> Tom
You rock! Thanks for the help. I'm particularly interested in seeing
you linux.xparameters.h.
Cheers,
g.
^ permalink raw reply
* rebuild net-snmp 5.0.6 from eldk 3.1.1
From: 徐小威的EMAIL @ 2005-08-26 0:48 UTC (permalink / raw)
To: linuxppc-embedded
Hi All:
Anybody know how to setting fedora linux 3 environment to cross
compile netsnmp 5.0.6
contain in the eldk 3.1.1.
I'v try to modify net-snmp.spec for using pcc_8xx-gcc, but still got
probems.
[root@banana SPECS]# ppc_8xx-rpmbuild -ba --with ee net-snmp.spec
Executing(%prep): /bin/sh -e /opt/eldk/var/tmp/rpm-tmp.4936
+ umask 022
+ cd /opt/eldk/usr/src/denx/BUILD
+ cd /opt/eldk/usr/src/denx/BUILD
+ rm -rf net-snmp-5.0.6
+ /bin/gzip -dc /opt/eldk/usr/src/denx/SOURCES/net-snmp-5.0.6.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd net-snmp-5.0.6
+ echo 'Patch #9 (net-snmp-5.0.1-initializer.patch):'
Patch #9 (net-snmp-5.0.1-initializer.patch):
+ patch -p1 -b --suffix .initializer -s
+ echo 'Patch #10 (net-snmp-5.0.1-nolibelf.patch):'
Patch #10 (net-snmp-5.0.1-nolibelf.patch):
+ patch -p1 -b --suffix .nolibelf -s
+ echo 'Patch #11 (net-snmp-5.0.6-syslog.patch):'
Patch #11 (net-snmp-5.0.6-syslog.patch):
+ patch -p1 -b --suffix .syslog -s
+ echo 'Patch #12 (net-snmp-5.0.6-nodb.patch):'
Patch #12 (net-snmp-5.0.6-nodb.patch):
+ patch -p1 -b --suffix .nodb -s
+ echo 'Patch #13 (net-snmp-5.0.6-compat.patch):'
Patch #13 (net-snmp-5.0.6-compat.patch):
+ patch -p1 -b --suffix .compat -s
+ echo 'Patch #14 (net-snmp-5.0.6-smux.patch):'
Patch #14 (net-snmp-5.0.6-smux.patch):
+ patch -p1 -b --suffix .smux -s
+ echo 'Patch #15 (net-snmp-5.0.6-libtool.patch):'
Patch #15 (net-snmp-5.0.6-libtool.patch):
+ patch -p1 -b --suffix .libtool -s
+ echo 'Patch #16 (net-snmp-5.0.6-smux_pktsz_err_rpt.patch):'
Patch #16 (net-snmp-5.0.6-smux_pktsz_err_rpt.patch):
+ patch -p1 -b --suffix .smux_pktsz_err_rpt -s
+ perl -pi -e 's|'\''\$install_libdir'\''|'\''/usr/lib'\''|' ltmain.sh
+ exit 0
Executing(%build): /bin/sh -e /opt/eldk/var/tmp/rpm-tmp.96354
+ umask 022
+ cd /opt/eldk/usr/src/denx/BUILD
+ cd net-snmp-5.0.6
+ endianess=little
+ endianess=big
+ CFLAGS='-O2 -g -fsigned-char'
+ export CFLAGS
+ CXXFLAGS='-O2 -g -fsigned-char'
+ export CXXFLAGS
+ FFLAGS='-O2 -g -fsigned-char'
+ export FFLAGS
+ ./configure --host=i386-pc-linux-gnu --build=i386-pc-linux-gnu --
target=ppc-denx-linux --program-prefix= --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --
datadir=/usr/share --includedir=/usr/include/net-snmp --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info --host=ee --enable-
static --enable-shared --with-cc=/opt/eldk/usr/bin/ppc_8xx-gcc --with-
ar=/opt/eldk/usr/bin/ppc_8xx-ar '--with-cflags=-O2 -g -fsigned-char' --
with-sys-location=Unknown --with-logfile=/var/log/snmpd.log --with-
persistent-directory=/var/net-snmp '--with-mib-modules=host agentx smux'
--with-libwrap=/usr/lib --sysconfdir=/etc --enable-ipv6 --enable-ucd-
snmp-compatibility --with-endianness=big --disable-debugging --enable-
mini-agent --with-default-snmp-version=2 --with-sys-
contact=root@localhost
creating cache ./config.cache
using default enterprise.net-snmp
using default enterprise sysOID NET-SNMP-MIB::netSnmpAgentOIDs...
using default notifications NET-SNMP-MIB::netSnmpNotifications
checking if I need to feed myself to ksh... no
checking for gcc... /opt/eldk/usr/bin/ppc_8xx-gcc
checking whether the C compiler (/opt/eldk/usr/bin/ppc_8xx-gcc -O2 -g -
fsigned-char ) works... yes
checking whether the C compiler (/opt/eldk/usr/bin/ppc_8xx-gcc -O2 -g -
fsigned-char ) is a cross-compiler... yes
checking whether we are using GNU C... yes
checking whether /opt/eldk/usr/bin/ppc_8xx-gcc accepts -g... yes
checking how to run the C preprocessor... /opt/eldk/usr/bin/ppc_8xx-gcc
-E
checking for AIX... no
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for executable suffix... no
checking host system type... Invalid configuration `ee': machine `ee'
not recognized
checking build system type... i386-pc-linux-gnu
checking for ld used by GCC... /opt/eldk/usr/ppc-linux/bin/ld
checking if the linker (/opt/eldk/usr/ppc-linux/bin/ld) is GNU ld... yes
checking for /opt/eldk/usr/ppc-linux/bin/ld option to reload object
files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependant libraries... unknown
checking for object suffix... o
./configure: line 2477: test: !=: unary operator expected
checking command to parse /usr/bin/nm -B output... ok
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for /opt/eldk/usr/bin/ppc_8xx-gcc option to produce PIC... -
fPIC
checking if /opt/eldk/usr/bin/ppc_8xx-gcc PIC flag -fPIC works... yes
checking if /opt/eldk/usr/bin/ppc_8xx-gcc static flag -static works...
yes
checking if /opt/eldk/usr/bin/ppc_8xx-gcc supports -c -o file.o... yes
checking if /opt/eldk/usr/bin/ppc_8xx-gcc supports -c -o file.lo...
checking if /opt/eldk/usr/bin/ppc_8xx-gcc supports -fno-rtti -fno-
exceptions... yes
checking whether the linker (/opt/eldk/usr/ppc-linux/bin/ld) supports
shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... no
checking if libtool supports shared libraries... no
checking for dlopen in -ldl... yes
checking whether a program can dlopen itself... cross
checking whether -lc should be explicitly linked in... no
creating libtool
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... (cached) yes
checking whether make sets ${MAKE}... yes
checking for ps... /bin/ps
checking for perl... /usr/bin/perl
checking for whoami... whoami
checking for sed... sed
checking for autoconf... no
checking for autoheader... no
checking for uname... /bin/uname
checking for working const... yes
checking for inline... inline
checking for net-snmp version number... 5.0.6
checking for developer gcc flags... none
checking host system type... config.sub: missing argument
Try `config.sub --help' for more information.
checking target system type... powerpc-denx-linux-gnu
checking build system type... i386-pc-linux-gnu
checking for system include file... net-snmp/system/linux.h
checking for machine-type include file... net-snmp/machine/generic.h
checking for /opt/eldk/usr/bin/ppc_8xx-gcc... no
checking for additional cpp flags... -x c
checking ipv6 stack type... linux-glibc, yes, using libc
checking whether we have to build PIC code... no
checking for and configuring transport modules to use... Callback Unix
TCP UDP TCPIPv6 UDPIPv6.
checking for security modules to use... usm
checking for and configuring mib modules to use... snmpv3mibs
mibII/snmp_mib mibII/system_mib mibII/sysORTable examples/ucdDemoPublic
mibII/vacm_vars host agentx smux mibII/ipv6.
checking for and configuring mib modules pieces to use... snmpv3mibs
mibII/snmp_mib mibII/system_mib mibII/sysORTable examples/ucdDemoPublic
mibII/vacm_vars host agentx smux mibII/ipv6 snmpv3/snmpEngine
snmpv3/snmpMPDStats snmpv3/usmStats snmpv3/usmUser util_funcs
mibII/vacm_context host/hr_system host/hr_storage host/hr_device
host/hr_other host/hr_proc host/hr_network host/hr_print host/hr_disk
host/hr_partition host/hr_filesys host/hr_swrun host/hr_swinst
agentx/master agentx/subagent smux/smux mibII/interfaces mibII/at
mibII/var_route mibII/route_write ucd-snmp/loadave agentx/protocol
agentx/client agentx/master_admin agentx/agentx_config mibII/ip
mibII/kernel_linux mibII/ipAddr.
checking if directories need to be created... .
checking default mib files to read... SNMPv2-MIB:RFC1213-MIB:SNMP-VIEW-
BASED-ACM-MIB:SNMP-COMMUNITY-MIB:HOST-RESOURCES-MIB:HOST-RESOURCES-
TYPES:IPV6-ICMP-MIB:IPV6-MIB:IPV6-TCP-MIB:IPV6-UDP-MIB:SNMP-FRAMEWORK-
MIB:SNMP-MPD-MIB:SNMP-USER-BASED-SM-MIB
checking for location of system kernel... unknown
checking for mount table location... /etc/mtab
checking for location of swap device... none
checking for asin in -lm... yes
checking for gethostbyname... yes
checking for getservbyname... yes
checking for kstat_lookup in -lkstat... no
checking for nlist in -lmld... no
checking for EVP_md5 in -lcrypto... yes
checking for AES_cfb128_encrypt... yes
checking for tcpd.h... yes
checking for TCP wrappers library -lwrap... no
checking for yp_get_default_domain... no
checking for yp_get_default_domain in -lnsl... yes
checking for TCP wrappers library -lwrap linked with -lnsl... yes
checking for zlib.h... yes
checking for gzread in -lz... yes
checking for bzread in -lbz2... no
checking for BZ2_bzread in -lbz2... yes
checking for poptParseArgvString in -lpopt... yes
checking for Fopen in -lrpmio... yes
checking for rpmGetFilesystemList in -lrpm... no
checking for rpmdbOpen in -lrpmdb... no
checking for kvm_read in -lkvm... no
checking for dlopen in -ldl... (cached) yes
checking for kvm_openfiles... no
checking for nlist... no
checking for knlist... no
checking for kvm_getprocs... no
checking whether we need -ldevstat for diskio MIB... no
checking for ANSI C header files... yes
checking for dirent.h that defines DIR... yes
checking for opendir in -ldir... no
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for stdarg.h... yes
checking for string.h... yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for sys/file.h... yes
checking for sys/ioctl.h... yes
checking for syslog.h... yes
checking for unistd.h... yes
checking for netinet/tcpip.h... no
checking for netinet/in.h... yes
checking for netinet/ip.h... yes
checking for netinet/ip_icmp.h... yes
checking for net/if.h... yes
checking for netdb.h... yes
checking for sys/dmap.h... no
checking for machine/pte.h... no
checking for xti.h... no
checking for sys/sockio.h... no
checking for sys/socket.h... yes
checking for sys/un.h... yes
checking for fstab.h... yes
checking for sys/fs.h... no
checking for mtab.h... no
checking for ufs/fs.h... no
checking for ufs/ffs/fs.h... no
checking for sys/fixpoint.h... no
checking for machine/param.h... no
checking for sys/vm.h... no
checking for vm/vm.h... no
checking for sys/vmmeter.h... no
checking for sys/vmparam.h... no
checking for sys/vmmac.h... no
checking for sys/vmsystm.h... no
checking for sys/mbuf.h... no
checking for sys/time.h... yes
checking for sys/swap.h... yes
checking for inet/mib2.h... no
checking for sys/statvfs.h... yes
checking for sys/vfs.h... yes
checking for sys/mnttab.h... no
checking for sys/user.h... yes
checking for sys/proc.h... no
checking for sys/select.h... yes
checking for mntent.h... yes
checking for sys/mntent.h... no
checking for kstat.h... no
checking for utsname.h... no
checking for sys/utsname.h... yes
checking for sys/cdefs.h... yes
checking for getopt.h... yes
checking for locale.h... yes
checking for pthread.h... yes
checking for sys/loadavg.h... no
checking for regex.h... yes
checking for linux/tasks.h... no
checking for pwd.h... yes
checking for grp.h... yes
checking for utmpx.h... yes
checking for malloc.h... yes
checking for sys/param.h... yes
checking for net/if_dl.h... no
checking for sys/sysctl.h... yes
checking for stdlib.h... yes
checking for net/if_mib.h... no
checking for net/if_types.h... no
checking for net/if_var.h... no
checking for sys/queue.h... yes
checking for osreldate.h... no
checking for machine/types.h... no
checking for sys/socketvar.h... yes
checking for sys/conf.h... no
checking for netinet/in_systm.h... yes
checking for netinet/tcp.h... yes
checking for netinet/udp.h... yes
checking for netinet/in_var.h... no
checking for netinet/if_ether.h... yes
checking for netinet/ip_var.h... no
checking for netinet/tcp_timer.h... no
checking for netinet/tcp_var.h... no
checking for netinet/tcp_fsm.h... no
checking for netinet/udp_var.h... no
checking for netinet/icmp_var.h... no
checking for sys/protosw.h... no
checking for nlist.h... no
checking for ioctls.h... no
checking for asm/page.h... yes
checking for netipx/ipx.h... yes
checking for arpa/inet.h... yes
checking for kvm.h... no
checking for sys/pool.h... no
checking for uvm/uvm_param.h... no
checking for uvm/uvm_extern.h... no
checking for vm/vm_param.h... no
checking for vm/vm_extern.h... no
checking for sys/mount.h... yes
checking for vm/swap_pager.h... no
checking for ufs/ufs/dinode.h... no
checking for sys/stat.h... yes
checking for sys/vnode.h... no
checking for ufs/ufs/quota.h... no
checking for ufs/ufs/inode.h... no
checking for sys/hashing.h... no
checking for sys/tcpipstats.h... no
checking for sys/sysmp.h... no
checking for err.h... yes
checking for sys/filio.h... no
checking for sgtty.h... yes
checking for sys/statfs.h... yes
checking for net/route.h... yes
checking for sys/dkio.h... no
checking for sys/diskio.h... no
checking for sys/pstat.h... no
checking for linux/hdreg.h... yes
checking for pkglocs.h... no
checking for pkginfo.h... no
checking for winsock.h... no
checking for io.h... no
checking for sys/stream.h... no
checking for netinet/ip6.h... yes
checking for netinet6/in6_var.h... no
checking for netinet6/in6_pcb.h... no
checking for netinet6/ip6_var.h... no
checking for netinet6/tcp6.h... no
checking for netinet6/tcp6_fsm.h... no
checking for netinet6/nd6.h... no
checking for netinet6/tcp6_timer.h... no
checking for netinet6/tcp6_var.h... no
checking for dlfcn.h... (cached) yes
checking for search.h... yes
checking for rpmio.h... no
checking for rpm/rpmio.h... yes
checking for netinet/in_pcb.h... no
checking for sys/disklabel.h... no
checking for openssl/hmac.h... yes
checking for openssl/evp.h... yes
checking for openssl/aes.h... yes
checking for openssl/des.h... yes
checking for lpstat... /usr/bin/lpstat
checking for cgetnext... no
checking for authentication support... OpenSSL Support
checking for off_t... yes
checking for pid_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for socklen_t... yes
checking for in_addr_t... yes
checking for correct flags to ps...
checking for working alloca.h... yes
checking for alloca... yes
checking whether /opt/eldk/usr/bin/ppc_8xx-gcc needs -traditional... no
checking for 8-bit clean memcmp... no
checking return type of signal handlers... void
checking for getmntent in -lsun... no
checking for getmntent in -lseq... no
checking for getmntent in -lgen... no
checking for getmntent... yes
checking for setmntent... yes
checking for gethostname... yes
checking for uname... yes
checking for gettimeofday... yes
checking for select... yes
checking for socket... yes
checking for strtol... yes
checking for strtoul... yes
checking for strchr... yes
checking for strdup... yes
checking for memcpy... yes
checking for memmove... yes
checking for index... yes
checking for bcopy... yes
checking for strcasestr... yes
checking for regcomp... yes
checking for signal... yes
checking for setsid... yes
checking for sigset... yes
checking for sigblock... yes
checking for sighold... yes
checking for strerror... yes
checking for setenv... yes
checking for vsnprintf... yes
checking for snprintf... yes
checking for sigaction... yes
checking for snprintf... (cached) yes
checking for strtoul... (cached) yes
checking for random... yes
checking for lrand48... yes
checking for rand... yes
checking for execv... yes
checking for system... yes
checking for fork... yes
checking for getpid... yes
checking for strncasecmp... yes
checking for sigalrm... no
checking for rpmGetPath... no
checking for getloadavg... yes
checking for getaddrinfo... yes
checking for getipnodebyname... no
checking for statvfs... yes
checking for statfs... yes
checking for getdtablesize... yes
checking for getfsstat... no
checking for usleep... yes
checking for setlocale... yes
checking for tcgetattr... yes
checking for if_nameindex... yes
checking for if_freenameindex... yes
checking for getpagesize... yes
checking for dlopen... yes
checking for mkstemp... yes
checking for getpwnam... yes
checking for getgrnam... yes
checking for setgid... yes
checking for setuid... yes
checking for setgroups... yes
checking for setitimer... yes
checking for SIOCGIFADDR in sys/ioctl.h... yes
checking for two-argument statfs with struct fs_data (Ultrix)... no
checking if __FUNCTION__ is defined... yes
checking for sigaction.sa_sigaction... yes
checking for sockaddr.sa_len... no
checking for sockaddr.sa_union.sa_generic.sa_family2... no
checking for rtentry.rt_dst... yes
checking type of rtentry structure... Unknown
unknown
checking for struct rtentry... rtentry
checking for rtentry.rt_unit... no
checking for rtentry.rt_refcnt... no
checking for rtentry.rt_hash... no
checking for rtentry.rt_use... no
checking for tcpstat.tcp_rcvmemdrop... no
checking for ifnet.if_mtu... no
checking if _KERNEL needs to be defined for if_mtu... no
checking for ifaddr.ifa_next... yes
checking for ifnet.if_baudrate... no
checking for ifnet.if_baudrate.ifs_value... no
checking for ifnet.if_speed... yes
checking for ifnet.if_type... yes
checking for ifnet.if_imcasts... no
checking for ifnet.if_iqdrops... yes
checking for ifnet.if_noproto... no
checking for ifnet.if_omcasts... no
checking for ifnet.if_xname... no
checking for ifnet.if_lastchange.tv_sec... no
checking for ifnet.if_obytes... yes
checking for ifnet.if_ibytes... yes
checking for ifnet.if_addrlist... no
checking for ifnet.if_addrhead.tqh_first... no
checking for udpstat.udps_discard... no
checking for udpstat.udps_noport... no
checking for udpstat.udps_noportbcast... no
checking for udpstat.udps_fullsock... no
checking for arphd.at_next... no
checking for swdevt.sw_nblksenabled... no
checking for statvfs.f_frsize... yes
checking for statvfs.f_files... yes
checking for nlist.n_value... no
checking for ipstat.ips_cantforward... no
checking for ipstat.ips_cantfrag... no
checking for ipstat.ips_delivered... no
checking for ipstat.ips_fragdropped... no
checking for ipstat.ips_fragtimeout... no
checking for ipstat.ips_localout... no
checking for ipstat.ips_noproto... no
checking for ipstat.ips_noroute... no
checking for ipstat.ips_odropped... no
checking for ipstat.ips_ofragments... no
checking for ipstat.ips_reassembled... no
checking for des_ks_struct.weak_key... no
configure: warning: Can't check sysctl, manually define CAN_USE_SYSCTL
if platform support available
checking whether TCP timers depend on `hz'... no
checking Default version of SNMP to use... (cached) 2
checking System Contact Information... (cached) root@localhost
checking System Location... (cached) Unknown
checking Location to write logfile... (cached) /var/log/snmpd.log
checking Location to write persistent information... (cached) /var/net-
snmp
updating cache ./config.cache
creating ./config.status
creating Makefile
creating snmplib/Makefile
creating apps/Makefile
creating apps/snmpnetstat/Makefile
creating agent/Makefile
creating agent/helpers/Makefile
creating agent/mibgroup/Makefile
creating local/Makefile
creating testing/Makefile
creating man/Makefile
creating mibs/Makefile
creating net-snmp-config
creating include/net-snmp/net-snmp-config.h
+ make
/opt/eldk/usr/bin/../lib/gcc-lib/ppc-linux/3.3.3/../../../../ppc-
linux/bin/ld: cannot open output file .libs/: Is a directorycollect2: ld
returned 1 exit status
make[1]: *** [libnetsnmp.la] Error 1
make: *** [subdirs] Error 1
error: Bad exit status from /opt/eldk/var/tmp/rpm-tmp.96354 (%build)
RPM build errors:
Bad exit status from /opt/eldk/var/tmp/rpm-tmp.96354 (%build)
^ permalink raw reply
* Address mapping PPC 405
From: P. Sadik @ 2005-08-26 1:31 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have a question on how PPC addressing works. I am familiar with
the MIPS architecture and new to PPC.
On MIPS, there are KUSEG (0x0000_0000 to 0x07FF_FFFF)
which is always translated using TLB. Then there are two
un-translated areas KSEG0 (0x8000_0000 which is cached)
and KSEG1 (0xA000_0000).
Hence, the kernel is compiled with .text at 0x8000_0000. For kernel
itself, the TLB is never consulted. All the local peripherals will be mappe=
d to=20
0xA000_0000. That means, from kernel, if I have to access a register of any=
=20
peripheral, I can use the un-mapped address and everything will work.
On PPC I see that, the kernel .text is at 0xC000_0000. Is it a=20
translated address? If it is, for running kernel code, the CPU has to
consult the TLB always?
Another question is regarding addressing local peripherals. I am using
an ML310 board from Xilinx and it has DDR mapped to 0x0000_0000
to 0x0FFF_FFFF (256 MB). Now, I need to add an IP to the PLB.
For that, I am thinking of using 0x2000_0000 to 0x2000_0FFF.
Now, my driver need to access the registers within the above region.
How will I do that? It is an I/O, hence should I use ioremap, or can
I access it directly? What role cache will play in this case?
The third question is, can I use de-referencing of address. Is it O.K
to use pointers to access the registers, or do I have to use read/write
variants?=20
I would appreciate a lot if you could give some insight into this. Any
pointers or reading materials will be very helpful.
Thanks and regards,
Sadik.
^ permalink raw reply
* Re: Address mapping PPC 405
From: Grant Likely @ 2005-08-26 3:10 UTC (permalink / raw)
To: P. Sadik; +Cc: linuxppc-embedded
In-Reply-To: <ea43f4f9050825183121655ba2@mail.gmail.com>
On Thu, Aug 25, 2005 at 06:31:22PM -0700, P. Sadik wrote:
> Hello,
>
> On PPC I see that, the kernel .text is at 0xC000_0000. Is it a
> translated address? If it is, for running kernel code, the CPU has to
> consult the TLB always?
Typically, PPC systems have RAM based at physical address 0 which is
mapped up to 0xc0000000. Once the MMU is turned on the TLB is consulted
for every memory access.
>
> Another question is regarding addressing local peripherals. I am using
> an ML310 board from Xilinx and it has DDR mapped to 0x0000_0000
> to 0x0FFF_FFFF (256 MB). Now, I need to add an IP to the PLB.
> For that, I am thinking of using 0x2000_0000 to 0x2000_0FFF.
> Now, my driver need to access the registers within the above region.
> How will I do that? It is an I/O, hence should I use ioremap, or can
> I access it directly? What role cache will play in this case?
You can put your peripherals anywhere within the address space as long
as they don't conflict with each other. You must add a page mapping for
each peripheral because once the MMU is turned on you can no longer
access physical addresses directly. I believe ioremap is the correct
facility to do this.
>
> The third question is, can I use de-referencing of address. Is it O.K
> to use pointers to access the registers, or do I have to use read/write
> variants?
Since there is no seperate IO memory space you can access the registers
with simple pointers.
Whether or not it is a good idea (based on coding conventions) I'll
leave for someone else to answer. :)
>
> I would appreciate a lot if you could give some insight into this. Any
> pointers or reading materials will be very helpful.
Keep me updated on your progress. I'm working on the ML300 and a couple
of the MEMEC boards to make v2pro support more flexible in 2.6.x, and
I'd like to hear about your experiences.
Cheers,
g.
>
> Thanks and regards,
>
> Sadik.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* problem mounting ROOT-NFS
From: Nuguru Susheel @ 2005-08-26 10:37 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I lately upgraded to Bestcomm API v2.2 from v2.1 , but root-nfs doesnt
mount while booting from ram, but when booting from FLASH (Compact Flash
and also NOR) it does well. This problem could be seen when I try to
boot on MPC5200 RevA.=20
Then I switched to MPC5200 RevB to see it is the same here, but with
same u.boot.bin and kernel image everything boot well on Rev B. I have
compared the Environment perameters passed from u-boot to the kernel and
everything seems to be the same. I also looked into the Errata to check
if anything else regarding bestcomm or fec has changed, but couldnt
figure out anything.
console messages while booting on MPC5200 RevA from ram goes this
way ...
=20
U-Boot 1.1.1 (Aug 24 2005 - 09:56:03)
CPU: MPC5200 (JTAG ID 0001101d) at 396 MHz
Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
Board: Mitron, Type is not set
DRAM: 64 MB
FLASH: 4 MB
FPGA: OK
SPI: MPC5200_spi,mki_ad initialised
BL: (channel 2, dutycycle 50, freq 500) initialised
Video: SMI720 @ 640x480x8 28kHz 53Hz
In: serial
Out: serial
Err: serial
NAND: 128 MB at 0x28001000
Net: FEC ETHERNET
IDE: no card
0
=3D> tftpboot 800000 u-boot.bin
Using FEC ETHERNET device
TFTP from server 192.168.1.61; our IP address is 192.168.30.130
Filename 'u-boot.bin'.
Load address: 0x800000
Loading: T invalid RARP header
TFTP error: 'File not found' (1)
Starting again
Abort
=3D> tftpboot 800000 pImage
Using FEC ETHERNET device
TFTP from server 192.168.1.61; our IP address is 192.168.30.130
Filename 'pImage'.
Load address: 0x800000
Loading:
#################################################################
#################################################################
#################################################################
#
done
Bytes transferred =3D 1001433 (f47d9 hex)
=3D> bootm 800000
## Booting image at 00800000 ...
Image Name: Linux-2.4.21-rc1
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1001369 Bytes =3D 977.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Mitron CVS tag: mct3_moto1_update
Memory BAT mapping: BAT2=3D64Mb, BAT3=3D0Mb, residual: 0Mb
Linux version 2.4.21-rc1 (nuguru@SW-server) (gcc version 2.95.4 20010319
(prerelease/franzo/20011204)) #5 Fri Aug 26 09:51:30 EEST 2005
Mitron SGVT port (C) 2003 Mitron Oy (mitron@mitron.fi)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: nfsroot=3D192.168.1.61:/tftpboot/rootfs
ip=3D192.168.30.130:192.168.1.61:192.168.1.1:255.255.0.0:SGVT_180::off
root=3D/dev/nfs video=3Dscarlet:dev:0,no_pal console=3DttyS0;init=3D/bin/sh=
;
mgt5100_pic.c/mgt5100_init_irq: using configuration from FPGA binary
file
mgt5100_init_irq: external FPGA interrupt controller (by Mitron Oy)
initialized
Calibrating delay loop... 263.78 BogoMIPS
Memory: 61828k available (1768k kernel code, 576k data, 76k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
Memory resource not set for host bridge 0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
hwblock: Identification failure!
hwblock: Checksum failure!
hwblock: Forcing fallback
hwblock: Configuring for MC=EF=BF=BDerial.c->init_chipsels: mfdev->count !=
=3D
SGVT_RS_TABLE_SIZE
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
uart00 at 0xc5076000 (irq =3D 92) is a TI16750
uart01 at 0xc5078008 (irq =3D 92) is a TI16750
uart02 at 0xc507a010 (irq =3D 92) is a TI16750
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=3Dxx
SCSI subsystem driver Revision: 1.00
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-ohci-embedded.c: USB OHCI at membase 0xf0001000, IRQ 44
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver hiddev
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
usb.c: registered new driver usblp
printer.c: v0.11: USB Printer Device Class driver
pegasus.c: v0.4.26 (2002/03/21):Pegasus/Pegasus II USB Ethernet driver
usb.c: registered new driver pegasus
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
eth0: Phy @ 0x0, type LXT971 (0x001378e2)
Mitron multi chip CAN driver 0.4 inited
Mitron SPI core functionality initialized
spi-core.o: adapter SGVT SPI host registered as adapter 0.
spi_add_driver: driver MKI driver registered.
kb_probe_func: MKI keyboard 0 found. Versions: hw:3.1 sw:2.2
spi_attach_client: client [SGVT SPI keyboard] registered to adapter
[SGVT SPI host](pos. 0).
MKI initialized succesfully
SGVT_WDT: Software Watchdog Timer version 0.1, timeout 60 sec.
SGVT Bank 0: Found 1 x16 devices at 0x0 in 8-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
SGVT Bank 0: Swapping erase regions for broken CFI table.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 3 MTD partitions on "SGVT Bank 0":
0x00000000-0x00200000 : "kernel"
0x00200000-0x00280000 : "logo1"
0x00280000-0x00300000 : "logo2"
Initialised PWM buzzer, v. 0.2
Nov. I/O 0.1 succesfully initialized
spi_add_driver: driver A/D driver registered.
spi_attach_client: client [SGVT SPI A/D converter] registered to adapter
[SGVT SPI host](pos. 5).
SPI A/D initialized succesfully
ppcpmw 0.8 initialized
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
eth0: config: auto-negotiation off, 100FDX, 100HDX, 10FDX, 10HDX.
IP-Config: Complete:
device=3Deth0, addr=3D192.168.30.130, mask=3D255.255.0.0,
gw=3D192.168.1.1,
host=3DSGVT_180, domain=3D, nis-domain=3D(none),
bootserver=3D192.168.1.61, rootserver=3D192.168.1.61, rootpath=3D
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 192.168.1.61
eth0: status: link up, 100 Mbps Full Duplex, auto-negotiation complete.
portmap: server 192.168.1.61 not responding, timed out
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.1.61
then it stays until I reset the core :-(
any hints ???
^ permalink raw reply
* Re: problem mounting ROOT-NFS
From: Bidong Yan @ 2005-08-26 8:13 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
Hi,
Your nfs server did not startup, or with a wrong port.
Best regards,
Yan
======= At 2005-08-26 18:37:28 you wrote =======
>Hi,
>
> I lately upgraded to Bestcomm API v2.2 from v2.1 , but root-nfs doesnt
>mount while booting from ram, but when booting from FLASH (Compact Flash
>and also NOR) it does well. This problem could be seen when I try to
>boot on MPC5200 RevA.
>
> Then I switched to MPC5200 RevB to see it is the same here, but with
>same u.boot.bin and kernel image everything boot well on Rev B. I have
>compared the Environment perameters passed from u-boot to the kernel and
>everything seems to be the same. I also looked into the Errata to check
>if anything else regarding bestcomm or fec has changed, but couldnt
>figure out anything.
>
>console messages while booting on MPC5200 RevA from ram goes this
>way ...
>
>
>
>
>U-Boot 1.1.1 (Aug 24 2005 - 09:56:03)
>
>CPU: MPC5200 (JTAG ID 0001101d) at 396 MHz
> Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
>Board: Mitron, Type is not set
>DRAM: 64 MB
>FLASH: 4 MB
>FPGA: OK
>SPI: MPC5200_spi,mki_ad initialised
>BL: (channel 2, dutycycle 50, freq 500) initialised
>Video: SMI720 @ 640x480x8 28kHz 53Hz
>In: serial
>Out: serial
>Err: serial
>NAND: 128 MB at 0x28001000
>Net: FEC ETHERNET
>IDE: no card
> 0
>=> tftpboot 800000 u-boot.bin
>Using FEC ETHERNET device
>TFTP from server 192.168.1.61; our IP address is 192.168.30.130
>Filename 'u-boot.bin'.
>Load address: 0x800000
>Loading: T invalid RARP header
>
>TFTP error: 'File not found' (1)
>Starting again
>
>
>Abort
>=> tftpboot 800000 pImage
>Using FEC ETHERNET device
>TFTP from server 192.168.1.61; our IP address is 192.168.30.130
>Filename 'pImage'.
>Load address: 0x800000
>Loading:
>#################################################################
>
>#################################################################
>
>#################################################################
> #
>done
>Bytes transferred = 1001433 (f47d9 hex)
>=> bootm 800000
>## Booting image at 00800000 ...
> Image Name: Linux-2.4.21-rc1
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1001369 Bytes = 977.9 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
>Mitron CVS tag: mct3_moto1_update
>Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb
>Linux version 2.4.21-rc1 (nuguru@SW-server) (gcc version 2.95.4 20010319
>(prerelease/franzo/20011204)) #5 Fri Aug 26 09:51:30 EEST 2005
>Mitron SGVT port (C) 2003 Mitron Oy (mitron@mitron.fi)
>On node 0 totalpages: 16384
>zone(0): 16384 pages.
>zone(1): 0 pages.
>zone(2): 0 pages.
>Kernel command line: nfsroot=192.168.1.61:/tftpboot/rootfs
>ip=192.168.30.130:192.168.1.61:192.168.1.1:255.255.0.0:SGVT_180::off
>root=/dev/nfs video=scarlet:dev:0,no_pal console=ttyS0;init=/bin/sh;
>mgt5100_pic.c/mgt5100_init_irq: using configuration from FPGA binary
>file
>mgt5100_init_irq: external FPGA interrupt controller (by Mitron Oy)
>initialized
>Calibrating delay loop... 263.78 BogoMIPS
>Memory: 61828k available (1768k kernel code, 576k data, 76k init, 0k
>highmem)
>Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
>Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
>Mount cache hash table entries: 512 (order: 0, 4096 bytes)
>Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
>Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
>POSIX conformance testing by UNIFIX
>PCI: Probing PCI hardware
>Memory resource not set for host bridge 0
>Linux NET4.0 for Linux 2.4
>Based upon Swansea University Computer Society NET3.039
>Initializing RT netlink socket
>Starting kswapd
>JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
>hwblock: Identification failure!
>hwblock: Checksum failure!
>hwblock: Forcing fallback
>hwblock: Configuring for MC?erial.c->init_chipsels: mfdev->count !=
>SGVT_RS_TABLE_SIZE
>Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
>SERIAL_PCI enabled
>uart00 at 0xc5076000 (irq = 92) is a TI16750
>uart01 at 0xc5078008 (irq = 92) is a TI16750
>uart02 at 0xc507a010 (irq = 92) is a TI16750
>RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
>PPP generic driver version 2.4.2
>PPP Deflate Compression module registered
>Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
>ide: Assuming 33MHz system bus speed for PIO modes; override with
>idebus=xx
>SCSI subsystem driver Revision: 1.00
>usb.c: registered new driver usbdevfs
>usb.c: registered new driver hub
>usb-ohci-embedded.c: USB OHCI at membase 0xf0001000, IRQ 44
>usb.c: new USB bus registered, assigned bus number 1
>hub.c: USB hub found
>hub.c: 2 ports detected
>usb.c: registered new driver hiddev
>usb.c: registered new driver hid
>hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
>hid-core.c: USB HID support drivers
>usb.c: registered new driver usblp
>printer.c: v0.11: USB Printer Device Class driver
>pegasus.c: v0.4.26 (2002/03/21):Pegasus/Pegasus II USB Ethernet driver
>usb.c: registered new driver pegasus
>Initializing USB Mass Storage driver...
>usb.c: registered new driver usb-storage
>USB Mass Storage support registered.
>eth0: Phy @ 0x0, type LXT971 (0x001378e2)
>Mitron multi chip CAN driver 0.4 inited
>Mitron SPI core functionality initialized
>spi-core.o: adapter SGVT SPI host registered as adapter 0.
>spi_add_driver: driver MKI driver registered.
>kb_probe_func: MKI keyboard 0 found. Versions: hw:3.1 sw:2.2
>spi_attach_client: client [SGVT SPI keyboard] registered to adapter
>[SGVT SPI host](pos. 0).
>MKI initialized succesfully
>SGVT_WDT: Software Watchdog Timer version 0.1, timeout 60 sec.
>SGVT Bank 0: Found 1 x16 devices at 0x0 in 8-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
>SGVT Bank 0: Swapping erase regions for broken CFI table.
>number of CFI chips: 1
>cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
>Creating 3 MTD partitions on "SGVT Bank 0":
>0x00000000-0x00200000 : "kernel"
>0x00200000-0x00280000 : "logo1"
>0x00280000-0x00300000 : "logo2"
>Initialised PWM buzzer, v. 0.2
>Nov. I/O 0.1 succesfully initialized
>spi_add_driver: driver A/D driver registered.
>spi_attach_client: client [SGVT SPI A/D converter] registered to adapter
>[SGVT SPI host](pos. 5).
>SPI A/D initialized succesfully
>ppcpmw 0.8 initialized
>NET4: Linux TCP/IP 1.0 for NET4.0
>IP Protocols: ICMP, UDP, TCP, IGMP
>IP: routing cache hash table of 512 buckets, 4Kbytes
>TCP: Hash tables configured (established 4096 bind 4096)
>eth0: config: auto-negotiation off, 100FDX, 100HDX, 10FDX, 10HDX.
>IP-Config: Complete:
> device=eth0, addr=192.168.30.130, mask=255.255.0.0,
>gw=192.168.1.1,
> host=SGVT_180, domain=, nis-domain=(none),
> bootserver=192.168.1.61, rootserver=192.168.1.61, rootpath=
>NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
>Looking up port of RPC 100003/2 on 192.168.1.61
>eth0: status: link up, 100 Mbps Full Duplex, auto-negotiation complete.
>portmap: server 192.168.1.61 not responding, timed out
>Root-NFS: Unable to get nfsd port number from server, using default
>Looking up port of RPC 100005/1 on 192.168.1.61
>
>then it stays until I reset the core :-(
>
> any hints ???
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
= = = = = = = = = = = = = = = = = = = =
^ permalink raw reply
* Re: rebuild net-snmp 5.0.6 from eldk 3.1.1
From: Wolfgang Denk @ 2005-08-26 8:48 UTC (permalink / raw)
To: 徐小威的EMAIL; +Cc: linuxppc-embedded
In-Reply-To: <1125017324.7073.4.camel@banana>
In message <1125017324.7073.4.camel@banana> you wrote:
>
> Anybody know how to setting fedora linux 3 environment to cross
> compile netsnmp 5.0.6
> contain in the eldk 3.1.1.
This is documented in detail in the DULG, please see
http://www.denx.de/twiki/bin/view/DULG/ELDKRebuildingComponents#Section_3.7.2.
Make sure to follow the instructions, especially those about setting
up your PATH!
> I'v try to modify net-snmp.spec for using pcc_8xx-gcc, but still got
> probems.
The unmodified spec file works just fine.
> Executing(%prep): /bin/sh -e /opt/eldk/var/tmp/rpm-tmp.4936
...
> + ./configure --host=i386-pc-linux-gnu --build=i386-pc-linux-gnu --
> target=ppc-denx-linux --program-prefix= --prefix=/usr --exec-prefix=/usr
> --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --
> datadir=/usr/share --includedir=/usr/include/net-snmp --libdir=/usr/lib
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com
> --mandir=/usr/share/man --infodir=/usr/share/info --host=ee --enable-
^^^^^^^
...
> checking host system type... Invalid configuration `ee': machine `ee'
> not recognized
You modified the spec file in a way that breaks it. Don't do this.
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
People seldom know what they want until you give them what they ask
for.
^ permalink raw reply
* Re: 827x/8x Linux USB Host driver
From: Alex Zeffertt @ 2005-08-26 10:10 UTC (permalink / raw)
To: Russell McGuire; +Cc: linuxppc-embedded
In-Reply-To: <20050716115551.GA47391@mail19b.g19.rapidsite.net>
Hello Russell,
I'm interested to know if you got anywhere with this? Did you find an OS USB driver for the 827x?
Or did you write one yourself?
TIA,
Alex
On Sat, 16 Jul 2005 08:55:52 -0700
"Russell McGuire" <rmcguire@uwbt.com> wrote:
>
>
> Does anyone know of the existence of an open source USB host driver for the
> 827x/8x PowerQUIC II processors for Linux 2.4.2x?
>
> This CPU introduced a USB host controller inside the CPU vs the 8260, which
> doesn't have one.
>
>
> Thanks,
>
> -Russ
^ permalink raw reply
* Re: AC Power handling broken for desktops
From: Olaf Hering @ 2005-08-26 11:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1124948071.7907.10.camel@gaston>
On Thu, Aug 25, Benjamin Herrenschmidt wrote:
> On Thu, 2005-08-25 at 07:15 +0200, Olaf Hering wrote:
> > On Thu, Aug 25, Benjamin Herrenschmidt wrote:
> >
> > > Not sure :) I don't fully know how to decode those power things in the
> > > device-tree... There are bits in darwin tho.
> >
> > Maybe just check for !PowerBook and force PMU_PWR_AC_PRESENT in this case.
>
> Yah, you can check that with pmac_feature, there is a "mobile" flag.
Its not obvious how to get to that flag. Is this patch acceptable?
No batteries present should mean AC Power == 1.
drivers/macintosh/apm_emu.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
Index: linux-2.6.13-rc7-ac-power/drivers/macintosh/apm_emu.c
===================================================================
--- linux-2.6.13-rc7-ac-power.orig/drivers/macintosh/apm_emu.c
+++ linux-2.6.13-rc7-ac-power/drivers/macintosh/apm_emu.c
@@ -430,8 +430,8 @@ static int apm_emu_get_info(char *buf, c
-1: Unknown
8) min = minutes; sec = seconds */
- unsigned short ac_line_status = 0xff;
- unsigned short battery_status = 0xff;
+ unsigned short ac_line_status;
+ unsigned short battery_status = 0;
unsigned short battery_flag = 0xff;
int percentage = -1;
int time_units = -1;
@@ -446,6 +446,7 @@ static int apm_emu_get_info(char *buf, c
ac_line_status = ((pmu_power_flags & PMU_PWR_AC_PRESENT) != 0);
for (i=0; i<pmu_battery_count; i++) {
if (pmu_batteries[i].flags & PMU_BATT_PRESENT) {
+ battery_status++;
if (percentage < 0)
percentage = 0;
if (charge < 0)
@@ -461,6 +462,9 @@ static int apm_emu_get_info(char *buf, c
charging++;
}
}
+ if (0 == battery_status)
+ ac_line_status = 1;
+ battery_status = 0xff;
if (real_count) {
if (amperage < 0) {
if (btype == PMU_BATT_TYPE_SMART)
^ permalink raw reply
* alsa tumbler audio-gpio-active-state handling broken after 2.6.12-rc2
From: Olaf Hering @ 2005-08-26 13:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
Ben,
this patch 03a53d4895d274ee8562ddc99723b98d8d0ef04c breaks tumbler
[PATCH] pmac: sound support for latest laptops
audio-gpio-active-state is zero. active_state was forced to 1 in this
case, now it is 0. As a result, no sound is played on my G4/466 and
600Mhz ibook.
This patch fixes it for me.
sound/ppc/tumbler.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.13-rc7-tumbler/sound/ppc/tumbler.c
===================================================================
--- linux-2.6.13-rc7-tumbler.orig/sound/ppc/tumbler.c
+++ linux-2.6.13-rc7-tumbler/sound/ppc/tumbler.c
@@ -1073,7 +1073,7 @@ static long tumbler_find_device(const ch
gp->inactive_val = (*base) ? 0x4 : 0x5;
} else {
u32 *prop = NULL;
- gp->active_state = 0;
+ gp->active_state = 1;
gp->active_val = 0x4;
gp->inactive_val = 0x5;
/* Here are some crude hacks to extract the GPIO polarity and
^ permalink raw reply
* Re: Best kernel for Xilinx VirtexII Pro/PPC405 ?
From: Peter Ryser @ 2005-08-26 14:33 UTC (permalink / raw)
To: Keith J Outwater; +Cc: linuxppc-embedded
In-Reply-To: <OF820ADBC7.FD07ABA9-ON07257061.00633C32-07257061.00641841@mck.us.ray.com>
Good to hear that you got everything working. Just as a note: XAPP542
(http://direct.xilinx.com/bvdocs/appnotes/xapp542.pdf) contains a patch
for the Linux kernel to make it work together with U-Boot.
Does linuxppc-2.4 still accept patches?
- Peter
Keith J Outwater wrote:
>Hi Peter -
>Well, the good news is that it works, and works well. In my humble
>opinion, supporting it would be pretty simple, but I completely understand
>why RHEL is the supported distribution. I would much rather see effort
>put into polishing up EDK under Linux than in supporting every Linux
>distro out there.
>For me, the bottom line was this: do I want to migrate all of other
>development activities from FC4 to RHEL for the sake of EDK, or try to run
>EDK under FC4? I tried the latter approach, and now that the Jungo
>WinDriver v7.1 is out, parallel port debugging works by simply using
>WinDriver 7.1 and patching the Xilinx XPC4 parport driver.
>I now have the kernel booting on a Memec 2VP50 eval board using U-Boot as
>the bootloader. I used the linuxppc-2.4 kernel rsynced from MontaVista.
>That particular kernel did not have support for U-Boot but it did support
>the ML300 and a Memec 2VP40/2VP70 board. I had to modify the kernel to
>accept a board description structure from U-Boot and I added a new board
>type for my custom hardware.
>The approach I took was definitely the "roll your own approach", but then
>again I've done this (Linux board ports) a couple times and I know U-Boot
>well.
>Keith
>
>Peter Ryser <peter.ryser@xilinx.com> wrote on 08/18/2005 07:39:21 AM:
>
>
>
>>>I am running all of my development tools (EDK, ISE, ELDK, etc...)
>>>
>>>
>under
>
>
>>>Fedora Core 4, so I am looking for a publicly accessible kernel source
>>>tree that best supports the PPC405 in the Virtex II Pro.
>>>
>>>
>>>
>>Keep in mind that EDK and ISE are not "officially" supported on FC4.
>>Anyway, with EDK, ISE, and ELDK you seem to have all that is needed to
>>get started with Linux on Virtex-II Pro and Virtex-4.
>>
>>- Peter
>>
>>
>>
>>
>
>
>
>
^ permalink raw reply
* Re: [PATCH] ppc32: ppc_sys system on chip identification additions
From: Kumar Gala @ 2005-08-26 18:48 UTC (permalink / raw)
To: Gala Kumar K.-galak; +Cc: Andrew Morton, linux-kernel, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0508241017480.23831@nylon.am.freescale.net>
Oops, this patch doesn't build since its missing a '{'. Will send up
an updated patch that fixes the problem.
- kumar
On Aug 24, 2005, at 10:18 AM, Gala Kumar K.-galak wrote:
> Add the ability to identify an SOC by a name and id. There are
> cases in
> which the integer identifier is not sufficient to specify a specific
> SOC.
> In these cases we can use a string to further qualify the match.
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
>
> ---
> commit 58d478e75ac5d6cb3a1f738a22555c3841445264
> tree 999d1722d74eb8dc76f40c8f4c52966cea681cb4
> parent eb5d5922d749a74f58416ca1a852651e7323449b
> author Kumar K. Gala <kumar.gala@freescale.com> Wed, 24 Aug 2005
> 10:14:42 -0500
> committer Kumar K. Gala <kumar.gala@freescale.com> Wed, 24 Aug 2005
> 10:14:42 -0500
>
> arch/ppc/syslib/ppc_sys.c | 51
> ++++++++++++++++++++++++++++++++++++++++++++-
> include/asm-ppc/ppc_sys.h | 1 +
> 2 files changed, 51 insertions(+), 1 deletions(-)
>
> diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
> --- a/arch/ppc/syslib/ppc_sys.c
> +++ b/arch/ppc/syslib/ppc_sys.c
> @@ -6,6 +6,7 @@
> * Maintainer: Kumar Gala <kumar.gala@freescale.com>
> *
> * Copyright 2005 Freescale Semiconductor Inc.
> + * Copyright 2005 MontaVista, Inc. by Vitaly Bordug
> <vbordug@ru.mvista.com>
> *
> * This program is free software; you can redistribute it and/or
> modify it
> * under the terms of the GNU General Public License as
> published by
> the
> @@ -35,8 +36,56 @@ void __init identify_ppc_sys_by_id(u32 i
>
> void __init identify_ppc_sys_by_name(char *name)
> {
> - /* TODO */
> + unsigned int i = 0;
> + while (ppc_sys_specs[i].ppc_sys_name[0])
> + if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
> + break;
> + i++;
> + }
> + cur_ppc_sys_spec = &ppc_sys_specs[i];
> return;
> +}
> +
> +static int __init count_sys_specs(void)
> +{
> + int i = 0;
> + while (ppc_sys_specs[i].ppc_sys_name[0])
> + i++;
> + return i;
> +}
> +
> +static int __init find_chip_by_name_and_id(char *name, u32 id)
> +{
> + int ret = -1;
> + unsigned int i = 0;
> + unsigned int j = 0;
> + unsigned int dups = 0;
> +
> + unsigned char matched[count_sys_specs()];
> +
> + while (ppc_sys_specs[i].ppc_sys_name[0]) {
> + if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
> + matched[j++] = i;
> + i++;
> + }
> + if (j != 0) {
> + for (i = 0; i < j; i++) {
> + if ((ppc_sys_specs[matched[i]].mask & id) ==
> + ppc_sys_specs[matched[i]].value) {
> + ret = matched[i];
> + dups++;
> + }
> + }
> + ret = (dups == 1) ? ret : (-1 * dups);
> + }
> + return ret;
> +}
> +
> +void __init identify_ppc_sys_by_name_and_id(char *name, u32 id)
> +{
> + int i = find_chip_by_name_and_id(name, id);
> + BUG_ON(i < 0);
> + cur_ppc_sys_spec = &ppc_sys_specs[i];
> }
>
> /* Update all memory resources by paddr, call before
> platform_device_register */
> diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
> --- a/include/asm-ppc/ppc_sys.h
> +++ b/include/asm-ppc/ppc_sys.h
> @@ -50,6 +50,7 @@ extern struct ppc_sys_spec *cur_ppc_sys_
> /* determine which specific SOC we are */
> extern void identify_ppc_sys_by_id(u32 id) __init;
> extern void identify_ppc_sys_by_name(char *name) __init;
> +extern void identify_ppc_sys_by_name_and_id(char *name, u32 id)
> __init;
>
> /* describes all devices that may exist in a given family of
> processors
> */
> extern struct platform_device ppc_sys_platform_devices[];
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ 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