* Re: add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 16:30 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <20080109153511.GA5086@powerlinux.fr>
Sven Luther wrote:
>
> Let's just fix this in the kernel, until we get a fixed efika firmware,
> then we can drop it easily enough. But until this happens, we need to be
> able to boot the kernel without any extra work on the users part.
That is exactly why I don't like the idea. Yes, it makes it easier for users
and easier for distro managers to say "it supports the Efika" but it makes
the Forth fixing, and any further firmware development (ignore the lack of
releases, it means nothing) much harder.
It should not be a function of Linux to fix firmware problems. This was
the FIRM line by Ben, Segher and the rest of the LinuxPPC guys when we
released the Efika - fix the firmware, not Linux, don't hack drivers, don't
rely on fixups. I disagreed at the time due to the urgency to release the
board, but now, we have the luxury of not having to rush it through to get
a product on sale.
I would much rather the Linux kernel did not implement fixups for firmware
which we can fix. The phy-handle part that Olaf specifies in his patch
can be added by a user to nvramrc, BY HAND, in around 10 lines of Forth
code. Those 6 lines are in the efika.forth script, and in fact Olaf is
simply running "interpret" over an encoded version of this! (I say 10 lines
because the efika.forth script is needlessly verbose for the purpose of
being readable by humans).
It is not scary or difficult to do this if you need ethernet to work, and
not beyond the scope of the installation documentation or an Efika wiki
page. The Forth stuff will work fine for *all* operating systems.
If you don't like not having your Linux distro or a default kernel working
on our default firmware, PLEASE FEEL FREE TO BLAME US. PROFUSELY.
Alternatively I'd love to work with people to create a comprehensive
pre-update binary fix (not a boot loader but an installer) for the Forth
script so that users can run it before they boot any distro disk, and then
the kernel on the CD, the kernel in the distro repositories, will not have
the burden of tracking firmware releases, and the Linux team will not have
the burden of maintaining tiny fixes for things which may always be fixed.
After all, there is no profit or benefit in fixing something 5 times just
in case the user only has 4 of them installed.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Grant Likely @ 2008-01-09 16:26 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080109140608.GA15673@aepfle.de>
On 1/9/08, Olaf Hering <olaf@aepfle.de> wrote:
>
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties. But only the phy stuff is required to get a
> working network.
>
> This should go into the kernel because its appearently
> impossible to boot the script via tftp and then load the real boot
> binary (yaboot or zimage).
>
Signed-off-by?
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Fix remainder calculating bug in single floating pointdivision
From: Kumar Gala @ 2008-01-09 16:19 UTC (permalink / raw)
To: Liu Yu; +Cc: linuxppc-dev
In-Reply-To: <6EBEC19BF4A8F843BCD6B9155BBE2515D1B70D@zch01exm26.fsl.freescale.net>
On Jan 9, 2008, at 9:38 AM, Liu Yu wrote:
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+b13201=freescale.com@ozlabs.org
>> [mailto:linuxppc-dev-bounces+b13201=freescale.com@ozlabs.org]
>> On Behalf Of Kumar Gala
>> Sent: Tuesday, January 08, 2008 2:20 PM
>> To: Dan Malek
>> Cc: Liu Yu; linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH] Fix remainder calculating bug in single
>> floating pointdivision
>>
>>
>> On Jan 6, 2008, at 2:44 PM, Dan Malek wrote:
>>
>>>
>>> On Jan 6, 2008, at 12:07 PM, Benjamin Herrenschmidt wrote:
>>>
>>>> It's nice to see somebody digging in that scary math emu stuff. If
>>>> you could also get rid of the warnings, it would be perfect :-)
>>>
>>> Yes, it is :-) I didn't think it would have a life beyond MPC8xx.
>>>
>>>> .... that this code was lifted from
>>>> somewhere else (glibc ? gcc soft-float ?),
>>>
>>> It seems like a lifetime ago.... I copied the framework
>> from Sparc,
>>> and the internals from gcc soft-float. I didn't change any of the
>>> internal emulation functions (hence, some of the warnings),
>> just the
>>> calling interface.
>>>
>>> While it's convenient, I still don't think kernel float emulation
>>> should be a solution. The tools should generate soft-float for the
>>> applications and libraries.
>>
>> If we think this is really true, we could move to using include/math-
>> emu/* instead of the files in powerpc/math-emu.
>
> Why it's better to move to using include/math-emu.
> I found they have similar framework, is powerpc/math-emu evolved from
> include/math-emu?
* We dont really need more than one way in the kernel source tree to
do math-emu
* include/math-emu is used by more archs so gets more review
* include/math-emu is closer to glibc soft-fp code so fixes to one
apply cleanly to the other
- k
^ permalink raw reply
* Re: PCI interrupt assignment on sequoia board
From: Josh Boyer @ 2008-01-09 16:18 UTC (permalink / raw)
To: Matthias Fuchs; +Cc: linuxppc-dev
In-Reply-To: <200801091653.22478.matthias.fuchs@esd-electronics.com>
On Wed, 9 Jan 2008 16:53:22 +0100
Matthias Fuchs <matthias.fuchs@esd-electronics.com> wrote:
> Hi,
>
> I noticed that Josh's 'for-2.5.25' does not assign PCI interrupts correctly:
>
> bash-3.00# lspci -v
> 00:00.0 Class 0680: 1014:027f
> Subsystem: 10e8:cafe
> Flags: bus master, medium devsel, latency 0, IRQ 16
> Memory at <unassigned> (32-bit, prefetchable)
> Capabilities: [58] Power Management version 2
>
> 00:0a.0 Class 0b20: 1014:027f (this is a PPC440EPx PCI target board in a sequoia PCI slot)
> Subsystem: 12fe:0441
> Flags: bus master, medium devsel, latency 128, IRQ 16
> Memory at 0000000180000000 (32-bit, prefetchable) [size=64M]
> Memory at 0000000184000000 (32-bit, prefetchable) [size=16M]
> Capabilities: [58] Power Management version 2
>
> 00:0c.0 Class 0200: 168c:0013 (rev 01)
> Subsystem: 14b7:0a60
> Flags: bus master, medium devsel, latency 128, IRQ 16
> Memory at 0000000185000000 (32-bit, non-prefetchable) [size=64K]
> Capabilities: [44] Power Management version 2
>
> bash-3.00# uname -a
> Linux sequoia 2.6.24-rc6-g78994e24 #5 Wed Jan 9 16:22:31 CET 2008 ppc ppc ppc GNU/Linux
>
>
> All interrupts are '16'. But I expected 67 as correctly stated in the device tree.
> This test has been made with the uboot wrapper code.
>
> Any idea?
Does lspci display the virtual IRQ number that is assigned when the
device tree is parsed and interrupts are mapped? I think so. If you
look at the other devices in /proc/interrupts you'll see they have the
virtual IRQ numbers as well.
josh
^ permalink raw reply
* Re: PCI interrupt assignment on sequoia board
From: Stefan Roese @ 2008-01-09 16:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200801091653.22478.matthias.fuchs@esd-electronics.com>
Hi Matthias,
On Wednesday 09 January 2008, Matthias Fuchs wrote:
> I noticed that Josh's 'for-2.5.25' does not assign PCI interrupts
> correctly:
>
> bash-3.00# lspci -v
> 00:00.0 Class 0680: 1014:027f
> Subsystem: 10e8:cafe
> Flags: bus master, medium devsel, latency 0, IRQ 16
> Memory at <unassigned> (32-bit, prefetchable)
> Capabilities: [58] Power Management version 2
>
> 00:0a.0 Class 0b20: 1014:027f (this is a PPC440EPx PCI target board in a
> sequoia PCI slot) Subsystem: 12fe:0441
> Flags: bus master, medium devsel, latency 128, IRQ 16
> Memory at 0000000180000000 (32-bit, prefetchable) [size=64M]
> Memory at 0000000184000000 (32-bit, prefetchable) [size=16M]
> Capabilities: [58] Power Management version 2
>
> 00:0c.0 Class 0200: 168c:0013 (rev 01)
> Subsystem: 14b7:0a60
> Flags: bus master, medium devsel, latency 128, IRQ 16
> Memory at 0000000185000000 (32-bit, non-prefetchable) [size=64K]
> Capabilities: [44] Power Management version 2
>
> bash-3.00# uname -a
> Linux sequoia 2.6.24-rc6-g78994e24 #5 Wed Jan 9 16:22:31 CET 2008 ppc ppc
> ppc GNU/Linux
>
>
> All interrupts are '16'. But I expected 67 as correctly stated in the
> device tree. This test has been made with the uboot wrapper code.
Those are virtual interrupt numbers. Yeah, that's confusing, I know.
The implementation should be correct.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* PCI interrupt assignment on sequoia board
From: Matthias Fuchs @ 2008-01-09 15:53 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I noticed that Josh's 'for-2.5.25' does not assign PCI interrupts correctly:
bash-3.00# lspci -v
00:00.0 Class 0680: 1014:027f
Subsystem: 10e8:cafe
Flags: bus master, medium devsel, latency 0, IRQ 16
Memory at <unassigned> (32-bit, prefetchable)
Capabilities: [58] Power Management version 2
00:0a.0 Class 0b20: 1014:027f (this is a PPC440EPx PCI target board in a sequoia PCI slot)
Subsystem: 12fe:0441
Flags: bus master, medium devsel, latency 128, IRQ 16
Memory at 0000000180000000 (32-bit, prefetchable) [size=64M]
Memory at 0000000184000000 (32-bit, prefetchable) [size=16M]
Capabilities: [58] Power Management version 2
00:0c.0 Class 0200: 168c:0013 (rev 01)
Subsystem: 14b7:0a60
Flags: bus master, medium devsel, latency 128, IRQ 16
Memory at 0000000185000000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [44] Power Management version 2
bash-3.00# uname -a
Linux sequoia 2.6.24-rc6-g78994e24 #5 Wed Jan 9 16:22:31 CET 2008 ppc ppc ppc GNU/Linux
All interrupts are '16'. But I expected 67 as correctly stated in the device tree.
This test has been made with the uboot wrapper code.
Any idea?
Matthias
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Olof Johansson @ 2008-01-09 16:02 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <4784E78C.40904@genesi-usa.com>
On Wed, Jan 09, 2008 at 03:26:04PM +0000, Matt Sealey wrote:
> Clarification: I really have to disagree with this patch, and Sven.
>
> The whole point of removing the stuff from the Linux kernel (as the
> efika.forth script and the associated patch performs) is that it means
> the Linux kernel is no longer a "moving target" for our firmware
> development.
But that's what this _accomplishes_. If linux needs something from the
firmware environment that it doesn't provide, it adds it itself. That
means that the firmware<>linux interface is no longer a moving target.
> If anyone wants to help/assist/suggest any updates to efika.forth,
> create binary tools which assist the installation of the script for
> users and for placement on Linux distro CDs etc. I would be very
> grateful, but it seems we have hit the Wall of Apathy where users
> complain for a feature but are not willing to work for it.
Amazing. Olaf just did that work for you, and he did it without providing
yet another tool for distros to pick up and maintain. And still you
complain. Is it really that strange that people aren't helping you out?!
-Olof
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: David Woodhouse @ 2008-01-09 15:49 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <4784E78C.40904@genesi-usa.com>
On Wed, 2008-01-09 at 15:26 +0000, Matt Sealey wrote:
> If anyone wants to help/assist/suggest any updates to efika.forth,
> create binary tools which assist the installation of the script for
> users and for placement on Linux distro CDs etc. I would be very
> grateful, but it seems we have hit the Wall of Apathy where users
> complain for a feature but are not willing to work for it.
We're already shipping efika.forth in Fedora rawhide, and in my updated
spins of Fedora 8. It's a pain in the arse, but it kind of works.
It would be much better if the kernel would 'just work'. The ideal way
of achieving that is for the firmware to be fixed -- but that's been
promised for a long time now, and we just don't believe you any more. So
working round it in the kernel seems to be the next best option.
> (I am invoking the Open Source Fallacy of that if the source is
> available you can patch it, I say that patching Linux is not the
> solution, but patching the firmware is. But nobody is willing to
> work on patching the firmware and keeping Linux entirely independant
> of our so-deemed "crappy" firmware)
/me looks at http://git.infradead.org/?p=openfirmware.git
/me looks at the Efika...
--
dwmw2
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Grant Likely @ 2008-01-09 15:46 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <4784E78C.40904@genesi-usa.com>
On 1/9/08, Matt Sealey <matt@genesi-usa.com> wrote:
> Please let's keep the nature of our firmware and the Linux codebase
> independant, and move the burden of support to Genesi, and not the
> Linux PowerPC team. After all, what is next, after phy-handle do
> you want to add i2c, irda, missing xlb/cdm entries in the patch so
> that other things work? Does everyone have to custom compile their
> own kernel? What happens if we do another firmware release and
> the Linux kernel overwrites important values without checking as
> it does now? It simply causes problems.
FWIW, I've got a patch in my tree that removes a bunch of the efika
fixups. I've learned a lot over the past year and I'm taking a more
pragmatic approach. So, fixups that are not absolutely required to
get a working Efika are going away.
However, I'm still inclined to pick up Olaf's patch with the
appropriate protections around it so it is only done if the nodes are
missing.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] enable built-in networking for Sequoia defconfig
From: Matthias Fuchs @ 2008-01-09 15:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <20080109092133.7ce85e94@zod.rchland.ibm.com>
Thanks,
Sorry, I must have been blind.
Matthias
On Wednesday 09 January 2008 16:21, Josh Boyer wrote:
> On Wed, 9 Jan 2008 15:42:38 +0100
> Matthias Fuchs <matthias.fuchs@esd-electronics.com> wrote:
>
> > On Wednesday 09 January 2008 13:07, Josh Boyer wrote:
> > > On Wed, 9 Jan 2008 12:16:25 +0100
> > > Matthias Fuchs <matthias.fuchs@esd-electronics.com> wrote:
> > >
> > > > Josh,
> > > >
> > > > Where did you apply this patch to? Couldn't find it in your for-2.6.25 branch.
> > >
> > > I applied it there, just haven't pushed it out yet. Will do that today.
> > >
> > > > BTW, is it normal to edit the defconfig file by hand?
> > >
> > > The defconfig? Not sure. What I normally do is a make foo_defconfig,
> > > edit the .config, make oldconfig, and copy the resulting .config back
> > > to foo_defconfig.
> > Yes, this is what I also do.
> >
> > But how did Hollis get these lines into .config or sequoia_defconfig:
> >
> > +CONFIG_IBM_NEW_EMAC=y
> > +CONFIG_IBM_NEW_EMAC_RXB=128
> > +CONFIG_IBM_NEW_EMAC_TXB=64
> > +CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32
> > +CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256
> > +CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0
> >
> > I did not find any Kconfigs where these might come from.
>
> They're in drivers/net/ibm_newemac/Kconfig.
>
> josh
>
>
^ permalink raw reply
* RE: [PATCH] Fix remainder calculating bug in single floating pointdivision
From: Liu Yu @ 2008-01-09 15:38 UTC (permalink / raw)
To: Kumar Gala, Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <C387A6C8-3FC9-4DD9-A79D-3ADAB1F5A73F@kernel.crashing.org>
> -----Original Message-----
> From: linuxppc-dev-bounces+b13201=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b13201=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Kumar Gala
> Sent: Tuesday, January 08, 2008 2:20 PM
> To: Dan Malek
> Cc: Liu Yu; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Fix remainder calculating bug in single=20
> floating pointdivision
>=20
>=20
> On Jan 6, 2008, at 2:44 PM, Dan Malek wrote:
>=20
> >
> > On Jan 6, 2008, at 12:07 PM, Benjamin Herrenschmidt wrote:
> >
> >> It's nice to see somebody digging in that scary math emu stuff. If=20
> >> you could also get rid of the warnings, it would be perfect :-)
> >
> > Yes, it is :-) I didn't think it would have a life beyond MPC8xx.
> >
> >> .... that this code was lifted from
> >> somewhere else (glibc ? gcc soft-float ?),
> >
> > It seems like a lifetime ago.... I copied the framework=20
> from Sparc,=20
> > and the internals from gcc soft-float. I didn't change any of the=20
> > internal emulation functions (hence, some of the warnings),=20
> just the=20
> > calling interface.
> >
> > While it's convenient, I still don't think kernel float emulation=20
> > should be a solution. The tools should generate soft-float for the=20
> > applications and libraries.
>=20
> If we think this is really true, we could move to using include/math-
> emu/* instead of the files in powerpc/math-emu.
Why it's better to move to using include/math-emu.
I found they have similar framework, is powerpc/math-emu evolved from
include/math-emu?
>=20
> The problem I had was when I tried to recreate the history of=20
> the code in powerpc/math-emu and how it doesn't really match=20
> the glibc code base. There are some differences and I wasn't=20
> sure if they were do to trying to match PPC HW at a bit level or not.
>=20
> I was hoping that the work Liu Yu would get as a bit of a=20
> testsuite to see if there was any harm in moving over to=20
> include/math-emu.
>=20
> - k
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Sven Luther @ 2008-01-09 15:35 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Olaf Hering, sven
In-Reply-To: <4784E78C.40904@genesi-usa.com>
On Wed, Jan 09, 2008 at 03:26:04PM +0000, Matt Sealey wrote:
> Clarification: I really have to disagree with this patch, and Sven.
>
> The whole point of removing the stuff from the Linux kernel (as the
> efika.forth script and the associated patch performs) is that it means
> the Linux kernel is no longer a "moving target" for our firmware
> development.
What firmware development ?
> If users require these kernels they can run efika.forth - the major
> stumbling block being this is quite ugly to do right now. This is our
> problem - bplan, Genesi, myself whoever you want to target - it should
> not be made into a Linux problem by creating this "moving target" that
> needs constant patching to maintain driver coherency.
Then get the firmware fixed, and everyone would be happy. I don't see
that happening in the near future, just as there has been no pegasos
firmware release in ages, and my work on it has been scratched, and
ignored for the efika firmware which has lot of regression compared to
the latest pegasos beta releases.
A new efika firmware upgrade has been promised in, what was it, marsch
last year or so, where is it ?
Let's just fix this in the kernel, until we get a fixed efika firmware,
then we can drop it easily enough. But until this happens, we need to be
able to boot the kernel without any extra work on the users part.
Friendly,
Sven Luther
^ permalink raw reply
* Re: printk() does not work on UART1
From: mike zheng @ 2008-01-09 15:34 UTC (permalink / raw)
To: Haiying Wang; +Cc: linuxppc-dev
In-Reply-To: <1199888068.3004.3.camel@udp097527uds.am.freescale.net>
I found the problem. The CONFIG_CMDLINE was overwritten. Right now, it
is working.
Thanks for all the help,
Mike
On 1/9/08, Haiying Wang <Haiying.Wang@freescale.com> wrote:
> On Wed, 2008-01-09 at 00:06 -0500, mike zheng wrote:
> > Hi All,
> >
> > I have one mpc8568 board using UART1 as the serial port. The OS is
> > Linux Kernel2.4. If I use the polling mode driver of
> > gen550_progress(), it works fine. However the printk() does not work
> > after the console_init(). Anyone know what shall I change in the
> > kernel to use UART1 as serial console? I assume the default is UART0,
> > but I don't know where the value is set. I changed the CONFIG_CMDLINE
> > to ttyS1, it does NOT work.
>
> Make sure you've configured PC0/1/2/3 for UART1 SOUT/RTS/CTS/SIN in
> u-boot.
>
> Haiying
>
>
^ permalink raw reply
* Re: [PATCH 1/8] pseries: phyp dump: Docmentation
From: Linas Vepstas @ 2008-01-09 15:31 UTC (permalink / raw)
To: Nathan Lynch; +Cc: mahuja, linuxppc-dev, lkessler, strosake
In-Reply-To: <20080109042911.GT14201@localdomain>
Hi Nathan,
Thank you for looking at this.
On 08/01/2008, Nathan Lynch <ntl@pobox.com> wrote:
> Manish Ahuja wrote:
> > +
> > + Hypervisor-Assisted Dump
> > + ------------------------
> > + November 2007
>
> Date is unneeded (and, uhm, dated :)
I'll argue very very strongly against this. One of the worst things
I deal with is undated documents. Google pulls up multiple
versions of a document, and you start wondering: "which one
of these is the *right one*?" Its only after trying some suggested
sequence of commands that aren't working, and more time googling
and effort wasted, that you finallly realize that you are reading
the version 0.1 of documentation from 1999 that some idiot
did not have the decency to put a date on. (A version number
is acceptable). Documentation is often in mediocre state,
don't compound the problem be leaving off critical info.
> > +The goal of hypervisor-assisted dump is to enable the dump of
> > +a crashed system, and to do so from a fully-reset system, and
> > +to minimize the total elapsed time until the system is back
> > +in production use.
>
> Is it actually faster than kdump?
This is a basic presumption; it should blow it away, as, after all,
it requires one less reboot! As a side effect, the system is in
production *while* the dump is being taken; with kdump,
you can't go into production until after the dump is finished,
and the system has been rebooted a second time. On
systems with terabytes of RAM, the time difference can be
hours.
> > +-- As the userspace tools complete saving a portion of
> > + dump, they echo an offset and size to
> > + /sys/kernel/release_region to release the reserved
> > + memory back to general use.
> > +
> > + An example of this is:
> > + "echo 0x40000000 0x10000000 > /sys/kernel/release_region"
> > + which will release 256MB at the 1GB boundary.
>
> This violates the "one file, one value" rule of sysfs, but nobody
> really takes that seriously, I guess. In any case, consider
> documenting this in Documentation/ABI.
This interface will almost certainly be changed, in order to allow
phyp dump to work with the kdump user-space tools. Its provisional
right now, until the details of user-space is hammered out.
> > +Please note that the hypervisor-assisted dump feature
> > +is only available on Power6-based systems with recent
> > +firmware versions.
>
> This statement will of course become dated/incorrect so I recommend
> removing it.
A provisional statement. I figure it should get taken out after
a few years.
> > +Implementation details:
> > +----------------------
> > +In order for this scheme to work, memory needs to be reserved
> > +quite early in the boot cycle. However, access to the device
> > +tree this early in the boot cycle is difficult, and device-tree
> > +access is needed to determine if there is a crash data waiting.
>
> I don't think this bit about early device tree access is correct. By
> the time your code is reserving memory (from early_init_devtree(), I
> think), RTAS has been instantiated and you are able to test for the
> existence of /rtas/ibm,dump-kernel.
If I remember right, it was still too early to look up this token directly,
so we wrote some code to crawl the flat device tree to find it. But
not only was that a lot of work, but I somehow decided that doing this
to the flat tree was wrong, as otherwise someone would surely have
written the access code. If this can be made to work, that would be
great, but we couldn't make it work at the time.
> > +To work around this problem, all but 256MB of RAM is reserved
> > +during early boot. A short while later in boot, a check is made
> > +to determine if there is dump data waiting. If there isn't,
> > +then the reserved memory is released to general kernel use.
>
> So I think these gymnastics are unneeded -- unless I'm
> misunderstanding something, you should be able to determine very early
> whether to reserve that memory.
Only if you can get at rtas, but you can't get at rtas at that point.
I think we would have been the earliest users of rtas at that point.
Possibly the order of how things are initialized could be changed.
> > +Open issues/ToDo:
> > +------------
> > + o The various code paths that tell the hypervisor that a crash
> > + occurred, vs. it simply being a normal reboot, should be
> > + reviewed, and possibly clarified/fixed.
> > +
> > + o Instead of using /sys/kernel, should there be a /sys/dump
> > + instead? There is a dump_subsys being created by the s390 code,
> > + perhaps the pseries code should use a similar layout as well.
>
> Well, it seems to me that there's little reason to duplicate the s390
> layout unless we can actually share code.
I'm thinking "user-space tools". This could probably be decided very
quickly after a short chat with the s390 architects about tools and
standardization and dump formats and the support process. In the
end, its some third-level support people who will be dissecting the
dump using god-knows-what tool (a hacked kdgb ???), so things
should get standardized as much as possible so that we don't
duplicate work.
> FWIW, I've been thinking about making a /sys/firmware/phyp hierarchy
> which could contain much of the System P-specific functions (DLPAR,
> lparcfg, other crud in /proc/ppc64)... seems suited to this
> platform-specific dump mechanism.
Works for me. I was always unclear what /sys/firmware was supposed
to contain.
--linas
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 15:34 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <20080109145850.GA4413@powerlinux.fr>
I'd also say that the sound driver isn't ready for production use and it
misuses the BestComm task for generic bidirectional buffer copies by
forcing it to 32-bit transfers (this obviously involves some software
upsampling at some point as nearly all common sound data is 16-bit,
also twice the bandwidth to achieve). The Freescale docs for this task
(and the one provided by the firmware, no doubt, is identical in
operation) clearly state that the transfer size is configurable, so
saying it only accepts 32-bit sample data is simply inefficient and
lazy.
Someone needs to sit down and look at these, after a year of simple
stagnation since Sylvain lost the time to maintain them. I don't think
it is at all a good idea to think "oh it has been in the wild for a
year and nobody maintains it so we will mainline it now". That's a
ridiculous development philosophy. And, since nobody seems to give a
shit, it will stay as bad as it is right now (a quick hack) whether
in the wild or mainlined..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Sven Luther wrote:
> On Wed, Jan 09, 2008 at 07:50:14AM -0700, Grant Likely wrote:
>> On 1/9/08, Sven Luther <sven@powerlinux.fr> wrote:
>>> On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote:
>>>> Woo! Thanks Olaf. I was just about to sit down and write something
>>>> like this myself. Looks good to me. I'll pick this up (but I'm going
>>>> to move it to the fixup_device_tree_efika() function)
>>> Indeed, thanks, this makes the efika kernel again work out of the box.
>>> Would it be possible to merge this upstream asap ?
>> I'll see if paulus will pick it up for 2.6.24
>
> Cool, this would mean the only thing missing the patchset i have been
> carrying is the sound driver. Do you see something else that has been
> added since then ?
>
> Friendly,
>
> Sven Luther
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Linux for ml310
From: Grant Likely @ 2008-01-09 15:24 UTC (permalink / raw)
To: Joachim Meyer; +Cc: linuxppc-embedded
In-Reply-To: <524013725@web.de>
On 1/9/08, Joachim Meyer <Jogi95@web.de> wrote:
> Hi
>
http://git.secretlab.ca/git/gitweb.cgi?p=linux-2.6-virtex.git;a=snapshot;h=d7ed933b578d9c4dec0e23a5a6f78c464b31c47c;sf=tbz2
> Is this a complete Kernel? I don't really understand this whole git-tree stuff.
> then i copied the arch/ppc/configs/ml300_defconfig to .config.
Hint: this does the same thing,
$ ARCH=ppc make ml300_defconfig
> I used an edk9.1 with linux_2_6 as OS for the ppc405_0, 0x10000000 for memory size, 100000000 for uart16550 bus clock freq and set the target directory. Under connected_periphs where: RS232_Uart, SPI_EEPROM, PCI32_BRIDGE, SysACE_CompactFlash and opb_intc_0.
> At Software I pressed the "Generate Libaries and BSPs" Button and copied the generated xparameters.h to linux-2.6-virtex/arch/ppc/platforms/4xx/xparameters.
you want to copy xparameter_ml???.h to arch/ppc/platform/4xx/xparameters_ml300.h
Do not replace xparameter.h; it's a wrapper around the real xparams
file and it defines things that Linux needs.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 15:26 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080109140608.GA15673@aepfle.de>
Clarification: I really have to disagree with this patch, and Sven.
The whole point of removing the stuff from the Linux kernel (as the
efika.forth script and the associated patch performs) is that it means
the Linux kernel is no longer a "moving target" for our firmware
development.
If users require these kernels they can run efika.forth - the major
stumbling block being this is quite ugly to do right now. This is our
problem - bplan, Genesi, myself whoever you want to target - it should
not be made into a Linux problem by creating this "moving target" that
needs constant patching to maintain driver coherency.
There is a clever way to load in a forth script to nvramrc on the
Efika through exploitation of an exposed internal firmware structure
(not security critical, just very useful). Unfortunately right now I
am not willing to shoulder the entire burden of writing, testing and
further development of a suite of tools to bridge the gap between the
current firmware which misses certain features, and a new firmware
which may not be released in a timely fashion.
If anyone wants to help/assist/suggest any updates to efika.forth,
create binary tools which assist the installation of the script for
users and for placement on Linux distro CDs etc. I would be very
grateful, but it seems we have hit the Wall of Apathy where users
complain for a feature but are not willing to work for it.
(I am invoking the Open Source Fallacy of that if the source is
available you can patch it, I say that patching Linux is not the
solution, but patching the firmware is. But nobody is willing to
work on patching the firmware and keeping Linux entirely independant
of our so-deemed "crappy" firmware)
Please let's keep the nature of our firmware and the Linux codebase
independant, and move the burden of support to Genesi, and not the
Linux PowerPC team. After all, what is next, after phy-handle do
you want to add i2c, irda, missing xlb/cdm entries in the patch so
that other things work? Does everyone have to custom compile their
own kernel? What happens if we do another firmware release and
the Linux kernel overwrites important values without checking as
it does now? It simply causes problems.
Therefore I heartily do not acknowledge this patch. Olaf, if you
would like to assist in the development of an easy installer for
the device tree supplement for users, please feel free... save
these guys from having to maintain support for a broken device
tree by providing a correct one :D
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Olaf Hering wrote:
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties. But only the phy stuff is required to get a
> working network.
>
> This should go into the kernel because its appearently
> impossible to boot the script via tftp and then load the real boot
> binary (yaboot or zimage).
>
> ---
> arch/powerpc/kernel/prom_init.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
> else if (strncmp(version, "FirmWorks,3.", 12) == 0) {
> of_workarounds = OF_WA_CLAIM | OF_WA_LONGTRAIL;
> call_prom("interpret", 1, 1, "dev /memory 0 to allow-reclaim");
> +#ifdef CONFIG_PPC_MPC52xx
> + } else if (strcmp(version, "EFIKA5K2") == 0) {
> + call_prom("interpret", 1, 1,
> + " .\" Adding EFIKA5K2 Ethernet PHY\" cr"
> + " s\" /builtin\" find-device"
> + " new-device"
> + " 1 encode-int s\" #address-cells\" property"
> + " 0 encode-int s\" #size-cells\" property"
> + " s\" mdio\" 2dup device-name device-type"
> + " s\" mpc5200b-fec-phy\" encode-string s\" compatible\" property"
> + " 0xf0003000 0x400 reg"
> + " 0x2 encode-int"
> + " 0x5 encode-int encode+"
> + " 0x3 encode-int encode+"
> + " s\" interrupts\" property"
> + " new-device"
> + " s\" ethernet-phy\" 2dup device-name device-type"
> + " 0x10 encode-int s\" reg\" property"
> + " my-self"
> + " ihandle>phandle"
> + " finish-device"
> + " finish-device"
> + " s\" /builtin/ethernet\" find-device"
> + " encode-int"
> + " s\" phy-handle\" property"
> + " device-end"
> + );
> +#endif
> } else
> return;
> _prom->memory = call_prom("open", 1, 1, ADDR("/memory"));
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] enable built-in networking for Sequoia defconfig
From: Josh Boyer @ 2008-01-09 15:21 UTC (permalink / raw)
To: Matthias Fuchs; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <200801091542.38914.matthias.fuchs@esd-electronics.com>
On Wed, 9 Jan 2008 15:42:38 +0100
Matthias Fuchs <matthias.fuchs@esd-electronics.com> wrote:
> On Wednesday 09 January 2008 13:07, Josh Boyer wrote:
> > On Wed, 9 Jan 2008 12:16:25 +0100
> > Matthias Fuchs <matthias.fuchs@esd-electronics.com> wrote:
> >
> > > Josh,
> > >
> > > Where did you apply this patch to? Couldn't find it in your for-2.6.25 branch.
> >
> > I applied it there, just haven't pushed it out yet. Will do that today.
> >
> > > BTW, is it normal to edit the defconfig file by hand?
> >
> > The defconfig? Not sure. What I normally do is a make foo_defconfig,
> > edit the .config, make oldconfig, and copy the resulting .config back
> > to foo_defconfig.
> Yes, this is what I also do.
>
> But how did Hollis get these lines into .config or sequoia_defconfig:
>
> +CONFIG_IBM_NEW_EMAC=y
> +CONFIG_IBM_NEW_EMAC_RXB=128
> +CONFIG_IBM_NEW_EMAC_TXB=64
> +CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32
> +CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256
> +CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0
>
> I did not find any Kconfigs where these might come from.
They're in drivers/net/ibm_newemac/Kconfig.
josh
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Sven Luther @ 2008-01-09 15:21 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Olaf Hering, sven
In-Reply-To: <4784E67F.6000000@genesi-usa.com>
On Wed, Jan 09, 2008 at 03:21:35PM +0000, Matt Sealey wrote:
> NO.
YES :)
Friendly,
Sven Luther
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Grant Likely @ 2008-01-09 15:20 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <4784E67F.6000000@genesi-usa.com>
On 1/9/08, Matt Sealey <matt@genesi-usa.com> wrote:
> NO.
please elaborate
>
> --
> Matt Sealey <matt@genesi-usa.com>
> Genesi, Manager, Developer Relations
>
> Sven Luther wrote:
> > On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote:
> >> Woo! Thanks Olaf. I was just about to sit down and write something
> >> like this myself. Looks good to me. I'll pick this up (but I'm going
> >> to move it to the fixup_device_tree_efika() function)
> >
> > Indeed, thanks, this makes the efika kernel again work out of the box.
> > Would it be possible to merge this upstream asap ?
> >
> > Friendly,
> >
> > Sven Luther
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Linux for ml310
From: Joachim Meyer @ 2008-01-09 15:19 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
Hi
First I want to thank you for you fast and useful answer last time.
I decided to use the kernel 2.6 for my ml310 now.
I downloaded this Kernel:
http://git.secretlab.ca/git/gitweb.cgi=3Fp=3Dlinux-2.6-virtex.git;a=3Dsnapshot;h=
=3Dd7ed933b578d9c4dec0e23a5a6f78c464b31c47c;sf=3Dtbz2
Is this a complete Kernel=3F I don't really understand this whole git-tree s=
tuff.
then i copied the arch/ppc/configs/ml300=5Fdefconfig to .config.
I used an edk9.1 with linux=5F2=5F6 as OS for the ppc405=5F0, 0x10000000 for me=
mory size, 100000000 for uart16550 bus clock freq and set the target direc=
tory. Under connected=5Fperiphs where: RS232=5FUart, SPI=5FEEPROM, PCI32=5FBRIDGE,=
SysACE=5FCompactFlash and opb=5Fintc=5F0.
At Software I pressed the "Generate Libaries and BSPs" Button and copied t=
he generated xparameters.h to linux-2.6-virtex/arch/ppc/platforms/4xx/xpar=
ameters.
I tried to compile with=20
make ARCH=3Dppc CROSS=5FCOMPILE=3Dpowerpc-405-linux-gnu- zImage
but it soon aborted with:
---------------------------
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
CC arch/ppc/syslib/xilinx=5Fpic.o
In file included from arch/ppc/syslib/xilinx=5Fpic.c:16:
arch/ppc/platforms/4xx/xparameters/xparameters.h:14:26: linux/config.h: No=
such file or directory
make[1]: *** [arch/ppc/syslib/xilinx=5Fpic.o] Error 1
make: *** [arch/ppc/syslib] Error 2
------------------------------
Can you help me=3F
Is there any tutorial (beside http://wiki.secretlab.ca/index.php/Linux=5Fon=5F=
Xilinx=5FVirtex) which provides detailed information=3F
Which Kernel should I use (And where to get it)=3F
Are ther eany patches necessary=3F
As crosscompiler I used crosstool with:
eval `cat powerpc-405.dat gcc-4.1.0-glibc-2.3.6.dat` sh all.sh --notest
I hope I don't bother you too much
Greetings & Thanks
Joachim
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Jetzt neu! Sch=FCtzen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/=3Fmc=3D022220
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 15:21 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <20080109144910.GA4222@powerlinux.fr>
NO.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Sven Luther wrote:
> On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote:
>> Woo! Thanks Olaf. I was just about to sit down and write something
>> like this myself. Looks good to me. I'll pick this up (but I'm going
>> to move it to the fixup_device_tree_efika() function)
>
> Indeed, thanks, this makes the efika kernel again work out of the box.
> Would it be possible to merge this upstream asap ?
>
> Friendly,
>
> Sven Luther
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Sven Luther @ 2008-01-09 14:49 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <fa686aa40801090644q5d1aa117ka7e8f5aed34237bd@mail.gmail.com>
On Wed, Jan 09, 2008 at 07:44:58AM -0700, Grant Likely wrote:
> Woo! Thanks Olaf. I was just about to sit down and write something
> like this myself. Looks good to me. I'll pick this up (but I'm going
> to move it to the fixup_device_tree_efika() function)
Indeed, thanks, this makes the efika kernel again work out of the box.
Would it be possible to merge this upstream asap ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH] enable built-in networking for Sequoia defconfig
From: Stefan Roese @ 2008-01-09 15:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Hollis Blanchard
In-Reply-To: <200801091542.38914.matthias.fuchs@esd-electronics.com>
On Wednesday 09 January 2008, Matthias Fuchs wrote:
> > The defconfig? Not sure. What I normally do is a make foo_defconfig,
> > edit the .config, make oldconfig, and copy the resulting .config back
> > to foo_defconfig.
>
> Yes, this is what I also do.
>
> But how did Hollis get these lines into .config or sequoia_defconfig:
>
> +CONFIG_IBM_NEW_EMAC=3Dy
> +CONFIG_IBM_NEW_EMAC_RXB=3D128
> +CONFIG_IBM_NEW_EMAC_TXB=3D64
> +CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=3D32
> +CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=3D256
> +CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=3D0
>
> I did not find any Kconfigs where these might come from.
Take a look at drivers/net/ibm_newemac/Kconfig.
Viele Gr=FC=DFe,
Stefan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Grant Likely @ 2008-01-09 15:10 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20080109140608.GA15673@aepfle.de>
On 1/9/08, Olaf Hering <olaf@aepfle.de> wrote:
>
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties. But only the phy stuff is required to get a
> working network.
Question: What will happen with this code if the mdio and phy nodes
have already been created by the forth script? There is not checking
to see if the phy node already exists.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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