* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:29 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <FB3CC275-6C15-414C-A1F2-F1A13E3E1279@freescale.com>
In message <FB3CC275-6C15-414C-A1F2-F1A13E3E1279@freescale.com> you wrote:
>
> Would it be acceptable to require a new command-line argument (I'm
> thinking specifically of the stdout device path, normally passed in
> the "chosen" node of the oftree) to be passed in the bootargs? Or is
> u-boot absolutely unupdateable on these swiftly-aging systems?
Command line options can be set as part of U-Boot environment
variables. These are freely changable. No update needed.
Yes, thius would be possible.
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
...when fits of creativity run strong, more than one programmer or
writer has been known to abandon the desktop for the more spacious
floor. - Fred Brooks, Jr.
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 21:29 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425212236.AA279352B18@atlas.denx.de>
On Apr 25, 2006, at 4:22 PM, Wolfgang Denk wrote:
> In message <265F73F8-F641-4EDD-B88F-
> A2B2F7FA1308@kernel.crashing.org> you wrote:
>>
>> I believe you with regards to custom boards, however I dont feel the
>> same is true for reference boards. I'm in the same boat as you with
>
> The same is true. Please listen.
I'm listening, I just dont agree. I see reference boards used by
developers who will end up building a custom board. I'm happy to be
enlightened if people are using reference boards for some other
purpose (beyond evaluation of the processor).
- kumar
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-25 21:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1448E56E-1327-40D5-BE44-0DC103AC3E8A@kernel.crashing.org>
In message <1448E56E-1327-40D5-BE44-0DC103AC3E8A@kernel.crashing.org> you wrote:
>
> If we have a u-boot shim there are some questions that need answering:
> * where should the .dts live (hate duplicating the file both in u-
> boot and kernel source tree)
Since U-Boot does not need nor use this information for it's
operation, but the kernel does, it should be part of the kernel.
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
"We don't have to protect the environment -- the Second Coming is at
hand." - James Watt
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 21:32 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425212440.65DF0352B18@atlas.denx.de>
On Apr 25, 2006, at 4:24 PM, Wolfgang Denk wrote:
> In message <E29663C3-8289-443F-BF7A-
> F973EC41CC72@kernel.crashing.org> you wrote:
>>
>> I'm not talking about all embedded PPC boards. I'm taking about the
>> subset that exists for 85xx. Also, its moving forward as the
>
> What's the difference?
The difference is that I'm only prescribing my views for a specific
subset of HW.
>
>> And how do you suggest we do this? My argument is for the boards I'm
>> talking about updating u-boot is the easiest and most straight
>> forward solution. I'm not advocating this at the right solution for
>
> It may be easiest for you, not for others.
Are we talking about other users of a board I maintain or for other
maintaining a different board?
- kumar
^ permalink raw reply
* Re: FT u-boot shim
From: Mark A. Greer @ 2006-04-25 21:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1448E56E-1327-40D5-BE44-0DC103AC3E8A@kernel.crashing.org>
On Tue, Apr 25, 2006 at 03:00:05PM -0500, Kumar Gala wrote:
> > So, don't break compatibility if you don't have time/interest to fix
> > it. We can wait till someone who "wants to move forward" can do this
> > professionally without screwing everybody else.
>
> So, lets turn this discussion into something useful (since having us
> going back and forth about our opinions isn't really going anywhere)
>
> If we have a u-boot shim there are some questions that need answering:
> * where should the .dts live (hate duplicating the file both in u-
> boot and kernel source tree)
> * how does build system find .dts
> * a Kconfig option to enable shim
> * assume done as a boot wrapper of sorts
Haven't we always had a shim like layer like this only we called it the
bootwrapper? IOW, arch/ppc/boot/*...now called arch/powerpc/boot?
FWIW, I'm farting around with a non u-boot platform and, basically, I added
a dts directory under arch/powerpc/boot. I use dtc to compile a dts file
into a .S file then build the .S file with the normal kernel build (you
could easily do the dtc compile w/ the build as well). Some minor hacking
of other stuff in the boot dir and it gets the job done. Its a total
hack right now so I'd rather not give a patch but the point is we
already have a logical place for it and its not that hard.
I know the boot dir is supposed to be moved at some point but it seems
like the logical place to put this functionality until it does move
(and even after it moves).
Mark
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-25 21:33 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425213043.2860B352B18@atlas.denx.de>
On Apr 25, 2006, at 4:30 PM, Wolfgang Denk wrote:
> In message <1448E56E-1327-40D5-
> BE44-0DC103AC3E8A@kernel.crashing.org> you wrote:
>>
>> If we have a u-boot shim there are some questions that need
>> answering:
>> * where should the .dts live (hate duplicating the file both in u-
>> boot and kernel source tree)
>
> Since U-Boot does not need nor use this information for it's
> operation, but the kernel does, it should be part of the kernel.
What about the case in which u-boot already has a .dts for a given
board? Should we duplicate the files between the kernel & u-boot?
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <07032FB1-0607-4862-815A-C817C7222FF5@kernel.crashing.org>
In message <07032FB1-0607-4862-815A-C817C7222FF5@kernel.crashing.org> you wrote:
>
> Which users are you speaking of, end users or developers that will
> use u-boot & linux for building a product?
Users that try to get some application running on some hardware; they
might be interested to compare different kernel versions, but they
probably have no interest (or are not capable or allowed) to change
U-Boot. I'm not sure if this is what you call "end users" - they are
software engineers, too, but work in a different department.
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
Gewöhnlich glaubt der Mensch, wenn er nur Worte hört, es müsse sich
dabei doch auch was denken lassen. -- Goethe, Faust I
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4BCCDE94-8A82-41C4-B4F9-F111E761F926@kernel.crashing.org>
In message <4BCCDE94-8A82-41C4-B4F9-F111E761F926@kernel.crashing.org> you wrote:
>
> I'm listening, I just dont agree. I see reference boards used by
> developers who will end up building a custom board. I'm happy to be
> enlightened if people are using reference boards for some other
> purpose (beyond evaluation of the processor).
Some do. Some use them in products.
Others (and not a small number) use them for testing application
code. In your definition these are probably "end users", too.
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
You can only live once, but if you do it right, once is enough.
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 21:38 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425213622.B116F352B18@atlas.denx.de>
On Apr 25, 2006, at 4:36 PM, Wolfgang Denk wrote:
> In message <4BCCDE94-8A82-41C4-B4F9-
> F111E761F926@kernel.crashing.org> you wrote:
>>
>> I'm listening, I just dont agree. I see reference boards used by
>> developers who will end up building a custom board. I'm happy to be
>> enlightened if people are using reference boards for some other
>> purpose (beyond evaluation of the processor).
>
> Some do. Some use them in products.
Can you give a concrete example of this.
> Others (and not a small number) use them for testing application
> code. In your definition these are probably "end users", too.
Then they can use the kernel the board comes with.
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <719F1078-8AFB-48A8-9FB7-4128354F7774@kernel.crashing.org>
In message <719F1078-8AFB-48A8-9FB7-4128354F7774@kernel.crashing.org> you wrote:
>
> >> I'm not talking about all embedded PPC boards. I'm taking about the
> >> subset that exists for 85xx. Also, its moving forward as the
> >
> > What's the difference?
>
> The difference is that I'm only prescribing my views for a specific
> subset of HW.
To me it makes things not better that just a certain group of boards
is affected.
> Are we talking about other users of a board I maintain or for other
> maintaining a different board?
I'm talking about users of any board. Yes, this includes the boards
you maintain.
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
Crash programs fail because they are based on the theory that, with
nine women pregnant, you can get a baby a month. - Wernher von Braun
^ permalink raw reply
* Re: FT u-boot shim
From: Eugene Surovegin @ 2006-04-25 21:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1448E56E-1327-40D5-BE44-0DC103AC3E8A@kernel.crashing.org>
On Tue, Apr 25, 2006 at 03:00:05PM -0500, Kumar Gala wrote:
>
> If we have a u-boot shim there are some questions that need answering:
> * where should the .dts live (hate duplicating the file both in u-
> boot and kernel source tree)
I have no strong opinion on this, maybe arch/powerpc/boot/85xx or
something. Although we may require having U-Boot tree somewhere I
don't particularly like this solution, it's better to keep kernel
self-contained, even if it requires some duplication. I personally
don't see this as an issue, because I assume this file isn't gonna
change frequently anyway.
Also, I think it's much safer to have this file in the kernel, this
way we will avoid potential problems with using different U-Boot
versions with different versions.
> * how does build system find .dts
If we go with "we-need-U-Boot-tree" solution, we can add Kconfig
option to specify path to U-Boot tree.
> * a Kconfig option to enable shim
Yes, there should be an option, for boards which can support old and
new U-Boot it should be user-selectable with old U-Boot being
a default. For boards which support only one type of U-Boot, this
option can be selected automatically.
> * assume done as a boot wrapper of sorts
Yeah, probably.
--
Eugene
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-25 21:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <07A76292-03D1-4648-AA40-11E06698FEE1@kernel.crashing.org>
In message <07A76292-03D1-4648-AA40-11E06698FEE1@kernel.crashing.org> you wrote:
>
> > Since U-Boot does not need nor use this information for it's
> > operation, but the kernel does, it should be part of the kernel.
>
> What about the case in which u-boot already has a .dts for a given
> board? Should we duplicate the files between the kernel & u-boot?
No. Remove them from the U-Boot tree. I was never happy to see this
stuff there.
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
Don't panic.
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-25 21:42 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <20060425213955.B9960352B18@atlas.denx.de>
On Apr 25, 2006, at 4:39 PM, Wolfgang Denk wrote:
> In message <07A76292-03D1-4648-
> AA40-11E06698FEE1@kernel.crashing.org> you wrote:
>>
>>> Since U-Boot does not need nor use this information for
>>> it's
>>> operation, but the kernel does, it should be part of the kernel.
>>
>> What about the case in which u-boot already has a .dts for a given
>> board? Should we duplicate the files between the kernel & u-boot?
>
> No. Remove them from the U-Boot tree. I was never happy to see this
> stuff there.
Then why did you accept the patches for them? I'm confused on what
you see as the solution for how to boot an arch/powerpc kernel going
forward.
- k
^ permalink raw reply
* Re: Xilinx Virtex-2 PRO FPGA ppc 405 on ML310 board
From: Vincent Winstead @ 2006-04-25 22:21 UTC (permalink / raw)
To: Aidan Williams; +Cc: linuxppc-embedded
In-Reply-To: <444D5907.6010506@nicta.com.au>
[-- Attachment #1: Type: text/plain, Size: 5956 bytes --]
Ok, so all that worked - it WAS necessary to choose "[*] Default all settings (lose changes)" in order for it to work though. Without this option checked I needed to add information and variables and constants and definitions that were not added into necessary files after make menuconfig and make dep were completed.
But I still have nothing working with the ML310 board. I did a "dow image.elf" at the XMD command prompt, then "con" and it showed up with a "RUNNING>" prompt, but nothing showed up on the hyperterminal window. I compiled using 115200 baud and I changed my hyperterminal to match this, but nothing shows up ...at all. Where do you think I would need to start looking to resolve this issue?
-Vincent
Aidan Williams <aidan@nicta.com.au> wrote:
After generating a new auto-config.in using the BSP,
you'll need to:
0. put new auto-config.in into kernel directory
linux-2.4.x/arch/ppc/platforms/xilinx_auto
1. change to the top uClinux-dist directory
(*NOT* the kernel directory)
2. In "Vendor/Product Selection --->"
Choose "Xilinx"
Choose "powerpc-auto"
3. In "Kernel/Library/Defaults Selection --->"
Choose linux-2.4.x as your kernel, making sure that
this is a symlink to or copy of the linuxppc-2.4
tarball from UQ.
4. In "Kernel/Library/Defaults Selection --->"
Choose "[*] Default all settings (lose changes)"
5. Save and quit..
This process will pull in default Xilinx/powerpc config
files from vendors/Xilinx/powerpc-auto/config.*
for the kernel and for other uClinux components.
It will also generate a new linux-2.4.x/.config
based on your auto-config.in and the defaults
in vendors/Xilinx/powerpc-auto/config.linux-2.4.x.
btw, I don't have an ML310 board. I have however gotten
the UQ kernel + uclinux to work on a v2pro FF1152 board
and a virtex-4 FX-12 minimodule.
another btw, the linuxppc-2.4 code has an auto-config.in
inside it which, if you follow the above steps (without
doing step 0), should compile. The supplied auto-config.in
won't match your board, but it should at least compile.
- aidan
Vincent Winstead wrote:
> guess what - I got the BSP to work! But now I have a problem with the
> make command. I put the auto-config.in where it needs to be then I did
> a make menuconfig to configure it, then I did a make dep, but when I did
> a make is when an error came up that I can't seem to figure out:
>
> In file included from
> /home/ml310_linux/uClinux-dist/linuxppc-2.4/include/linux/pagemap.h:16,
> from
> /home/ml310_linux/uClinux-dist/linuxppc-2.4/include/linux/locks.h:8,
> from
> /home/ml310_linux/uClinux-dist/linuxppc-2.4/include/linux/blk.h:5,
> from init/main.c:25:
> /home/ml310_linux/uClinux-dist/linuxppc-2.4/include/linux/highmem.h: In
> function `kmap':
> /home/ml310_linux/uClinux-dist/linuxppc-2.4/include/linux/highmem.h:68:
> error: `CONFIG_KERNEL_START' undeclared (first use in this function)
> init/main.c: In function `start_kernel':
> init/main.c:393: error: `CONFIG_KERNEL_START' undeclared (first use in
> this function)
> make[1]: *** [init/main.o] Error 1
> make[1]: Leaving directory `/home/ml310_linux/uClinux-dist/linuxppc-2.4'
> make: *** [linux] Error 1
>
> This CONFIG_KERNEL_START is the problem. It doesn't seem to be defined
> anywhere and I guess it needs to be. Is this something I need to get
> from somewhere? Or is it maybe generated along with the BSP so I would
> have to put a start number into the platform Studio configuration?
>
> -Vincent
>
>
> */Aidan Williams /* wrote:
>
>
> Vincent Winstead wrote:
> > Now, as far as step 5, am I supposed to have a symbolic link that is
> > named linux-2.4.x placed into the uClinux-dist directory? Because
> > there's already a folder named linux-2.4.x which was in there
> already
> > when I untarred everything. At the command prompt in the
> uClinux-dist
> > directory I entered the following line:
> >
> > ln -s ../linuxppc-2.4 linux-2.4.x
> >
> > and the result of this operation was to put a symbolic link into my
> > linuxppc-2.4 directory with the name of linux-2.4.x - is this
> correct?
> >
>
> First, you'll need to move the existing directory aside using
> a command like:
>
> mv linux-2.4.x linux-2.4.x-dist
>
> and then re-run the ln -s command above.
>
> > Now on to Step 6 problem.
> > How am I supposed to make use uClinux EDK Board Support Package 1.0
> > files? I'm not sure how to go about using them in the Xilinx
> Platform
> > Studio in order to generate the necessary auto-config.in file.
> >
>
> See the document below for the general approach:
>
> > Even though it is about the microblaze rather than
> > the PPC, a helpful "getting started" document is:
> >
> http://www.itee.uq.edu.au/~wu/downloads/uClinux_ready_Microblaze_design.pdf
> >
>
> Look particularly at the section "Software Platform Settings"
> on page 29, steps 67,68.
>
> If you are not overly familiar with the EDK, it would
> be best to find someone locally who can help walk you
> through the process of generating a system.
>
> - aidan
>
>
> --------------------------------------------------------------------------
> This email and any attachments may be confidential. They may contain
> legally
> privileged information or copyright material. You should not read, copy,
> use or disclose them without authorisation. If you are not an intended
> recipient, please contact us at once by return email and then delete
> both
> messages. We do not accept liability in connection with computer virus,
> data corruption, delay, interruption, unauthorised access or
> unauthorised
> amendment. This notice should not be removed.
>
>
[-- Attachment #2: Type: text/html, Size: 6947 bytes --]
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 22:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <D6F58AA4-54EA-44BF-A0B7-83397B115B27@kernel.crashing.org>
In message <D6F58AA4-54EA-44BF-A0B7-83397B115B27@kernel.crashing.org> you wrote:
>
> > Some do. Some use them in products.
>
> Can you give a concrete example of this.
No, I cannot. Not in public.
> > Others (and not a small number) use them for testing application
> > code. In your definition these are probably "end users", too.
>
> Then they can use the kernel the board comes with.
No, they cannot. Running different kernel versions (including old
ones, eventually even 2.4) may be the key issue of their tests. Note
that this is something which does not require any modification to the
board - I can just TFTP the kernel image and boot it.
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
Weekends were made for programming. - Karl Lehenbauer
^ permalink raw reply
* Re: FT u-boot shim
From: Wolfgang Denk @ 2006-04-25 22:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <DAD4396E-7458-471C-8150-9DDCD396BA63@kernel.crashing.org>
In message <DAD4396E-7458-471C-8150-9DDCD396BA63@kernel.crashing.org> you wrote:
>
> > No. Remove them from the U-Boot tree. I was never happy to see this
> > stuff there.
>
> Then why did you accept the patches for them? I'm confused on what
Because I had neither time nor nerves to discuss with kernel
maintainers how this could be done. Several people asked me again and
again to accept these patches because they were vital for FDT
support, so I gave in.
> you see as the solution for how to boot an arch/powerpc kernel going
> forward.
I strongly agree with Dan and Eugene: the kernel should not depend on
any specific version of a boot loader, and more general not even on
any specific boot loader at all.
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
Any sufficiently advanced technology is indistinguishable from magic.
Clarke's Third Law - _Profiles of the Future_ (1962; rev. 1973)
``Hazards of Prophecy: The Failure of Imagination''
^ permalink raw reply
* PPC Linux support for Tundra TSI148
From: Martin, Tim @ 2006-04-25 23:47 UTC (permalink / raw)
To: linuxppc-embedded
Does anyone out there have any real world measured performance of a
Linux PowerPC (kernel module + user space application) doing 2eSST VME
transfers with the Tundra TSI148 chipset?
Tundra has a Linux driver available for the Motorola MVME6100 , but told
me they don't have any performance data available. I'm looking for
sustained throughput rates, not the peak burst rates (e.g. 320 MBps, 267
MBps).
Thanks!
Tim
^ permalink raw reply
* Re: maple_defconfig - CONFIG_ALTIVEC is not set
From: Segher Boessenkool @ 2006-04-26 0:15 UTC (permalink / raw)
To: Stephen Winiecki; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <OFC5EF8ADF.0CD9CACA-ON8725715B.0049AB44-8525715B.0049E2DA@us.ibm.com>
> Is there a reason why ALTIVEC is not enabled in maple_defconfig?
Is it not? You're kidding me. [checks] It's not. Ouch.
Please, Ben or Paul, can you fix this? Thanks!
Segher
p.s. I probably should check if it has some more errors /
shortcomings. But I'm too lazy. Stephen, do you see anything
else wrong?
^ permalink raw reply
* Re: PPC Linux support for Tundra TSI148
From: Gerhard Jaeger @ 2006-04-26 7:26 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <821B2170E9E7F04FA38DF7EC21DE487104970DA7@VCAEXCH01.hq.corp.viasat.com>
On Wednesday 26 April 2006 01:47, Martin, Tim wrote:
> Does anyone out there have any real world measured performance of a
> Linux PowerPC (kernel module + user space application) doing 2eSST VME
> transfers with the Tundra TSI148 chipset?
>
> Tundra has a Linux driver available for the Motorola MVME6100 , but told
> me they don't have any performance data available. I'm looking for
> sustained throughput rates, not the peak burst rates (e.g. 320 MBps, 267
> MBps).
>
Hi,
I've done here some tests between two MVME6100, while updating the 6100 BSP
for our embedded Linux distro. Depending on the buffersize, alignment, VME and
PCI FIFO settings we have (without further optimizations) throughput rates ranging
from 100MBps up to 168MBps. I think some tuning could still be done.
HTH
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* Linux 2.6 sources for MPC852T processor
From: Chandrasekhar Nagaraj @ 2006-04-26 9:50 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 668 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
From: Michael Ellerman @ 2006-04-26 10:37 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc64-dev, netdev
In-Reply-To: <1143421876.7795.2.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]
On Mon, 2006-03-27 at 12:11 +1100, Michael Ellerman wrote:
> On Thu, 2006-03-02 at 13:40 -0600, Santiago Leon wrote:
> > From: Michael Ellerman <michael@ellerman.id.au>
> >
> > After a kexec the veth driver will fail when trying to register with the
> > Hypervisor because the previous kernel has not unregistered.
> >
> > So if the registration fails, we unregister and then try again.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> > Acked-by: Anton Blanchard <anton@samba.org>
> > Signed-off-by: Santiago Leon <santil@us.ibm.com>
> > ---
> >
> > drivers/net/ibmveth.c | 32 ++++++++++++++++++++++++++------
> > 1 files changed, 26 insertions(+), 6 deletions(-)
>
> Looks like this hit the floor. Any chance of getting it into to 2.6.17
> Jeff? AFAICT it should still apply cleanly.
/me knocks politely
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Linux 2.6 sources for MPC852T processor
From: David Jander @ 2006-04-26 11:50 UTC (permalink / raw)
To: linuxppc-embedded, chandrasekhar_n
In-Reply-To: <20060426025008.C8A7D773@resin02.mta.everyone.net>
On Wednesday 26 April 2006 11:50, Chandrasekhar Nagaraj wrote:
> <DIV style="font-family:Arial,sans-serif;"><DIV>Hi,</DIV>
> <DIV>I have a customized board based on the MPC852T based processor.</DIV>
> <DIV>I intend to develop a BSP for this board.</DIV>
> <DIV> </DIV>
> <DIV>Does 2.6.16 from the kernel.org support this processor?</DIV>
First of all, please avoid HTML in e-mail messages. It is hard to read, and
normally banned on mailing list such as this one.
Yes, MPC852T is supported, although I might add that I have been using 2.6.14
and 2.6.15 sucessfully with our own MPC852T-based board, but 2.6.16 did not
boot and as of today I don't know why, or whether this is an issue at all
with boards other than ours.
> <DIV> </DIV>
> <DIV>In the 2.6.16 sources I found support for CONFIG_8xx. Does this mean
> that 852T processor is also supported?</DIV> <DIV> </DIV>
Yes. Look at BSP stuff for other 8xx boards to learn how to port yours. Keep
an eye on the new platform_bus stuff, that's currently being implemented for
different drivers and subsystmes for powerpc (this could be the reason, our
own BSP stuff stopped working with 2.6.16, btw).
Also a transition from /arch/ppc and /arch/ppc64 towards the
common /arch/powerpc is in progress, and therefore some things might be in a
state of flux between released versions of the kernel. As of today (kernel
2.6.16) the architecture you need to use is still /arch/ppc.
Good luck!
Greetings,
--
David Jander
^ permalink raw reply
* Re: FT u-boot shim
From: Kumar Gala @ 2006-04-26 14:37 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <20060425222841.C2D0E353DAC@atlas.denx.de>
On Apr 25, 2006, at 5:28 PM, Wolfgang Denk wrote:
> In message
> <DAD4396E-7458-471C-8150-9DDCD396BA63@kernel.crashing.org> you wrote:
>>
>>> No. Remove them from the U-Boot tree. I was never happy to see
>>> this
>>> stuff there.
>>
>> Then why did you accept the patches for them? I'm confused on what
>
> Because I had neither time nor nerves to discuss with kernel
> maintainers how this could be done. Several people asked me again and
> again to accept these patches because they were vital for FDT
> support, so I gave in.
>
>> you see as the solution for how to boot an arch/powerpc kernel going
>> forward.
>
> I strongly agree with Dan and Eugene: the kernel should not depend on
> any specific version of a boot loader, and more general not even on
> any specific boot loader at all.
I think thats part of the idea with arch/powerpc defining a standard
mechanism for how a boot loader should pass information to the kernel
(via a flat device tree).
How would you propose that we handle booting arch/powerpc kernels
from u-boot going forward? (for new board ports and existing board
ports).
- kumar
^ permalink raw reply
* [PATCH] nvram_print_partitions cosmetic fixup
From: Will Schmidt @ 2006-04-26 16:09 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org list, paulus
This is a cosmetic fixup. When printing the nvram partition table, the
first couple entries have a shorter 'index' value than the others, so
table is a bit askew. This change makes the table look pretty.
Tested on pseries and g5. Footnote: yes, this table is normally hidden
behind a DEBUG_NVRAM #define.
Signed-off-by: Will Schmidt <willschm@us.ibm.com>
diff --git a/arch/powerpc/kernel/nvram_64.c
b/arch/powerpc/kernel/nvram_64.c
index ada50aa..6960f09 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -204,7 +204,7 @@ static void nvram_print_partitions(char
printk(KERN_WARNING "indx\t\tsig\tchks\tlen\tname\n");
list_for_each(p, &nvram_part->partition) {
tmp_part = list_entry(p, struct nvram_partition, partition);
- printk(KERN_WARNING "%d \t%02x\t%02x\t%d\t%s\n",
+ printk(KERN_WARNING "%4d \t%02x\t%02x\t%d\t%s\n",
tmp_part->index, tmp_part->header.signature,
tmp_part->header.checksum, tmp_part->header.length,
tmp_part->header.name);
^ permalink raw reply related
* RE: PPC Linux support for Tundra TSI148
From: Martin, Tim @ 2006-04-26 16:24 UTC (permalink / raw)
To: Gerhard Jaeger, linuxppc-embedded
Gerhard,
Thanks for the information. More questions...
What type of transfers were you doing? (e.g. A32/D64? SST320 or SST267?)
Are these transfer from userspace data, from kernelspace data, or from
the Tundra's pattern buffer?
What was your PCI bus speed & width?
Were you using inbound/outbound windows or Tundra's DMA controller?
What was the Tundra chipset configuration for the 168 MBps?
Thanks,
Tim
> -----Original Message-----
> From: linuxppc-embedded-bounces+tmartin=3Dviasat.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+tmartin=3Dviasat.com@ozlabs.org] On
Behalf
> Of Gerhard Jaeger
> Sent: Wednesday, April 26, 2006 12:26 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: PPC Linux support for Tundra TSI148
>=20
> On Wednesday 26 April 2006 01:47, Martin, Tim wrote:
> > Does anyone out there have any real world measured performance of a
> > Linux PowerPC (kernel module + user space application) doing 2eSST
VME
> > transfers with the Tundra TSI148 chipset?
> >
> > Tundra has a Linux driver available for the Motorola MVME6100 , but
told
> > me they don't have any performance data available. I'm looking for
> > sustained throughput rates, not the peak burst rates (e.g. 320 MBps,
267
> > MBps).
> >
>=20
> Hi,
>=20
> I've done here some tests between two MVME6100, while updating the
6100
> BSP
> for our embedded Linux distro. Depending on the buffersize, alignment,
VME
> and
> PCI FIFO settings we have (without further optimizations) throughput
rates
> ranging
> from 100MBps up to 168MBps. I think some tuning could still be done.
>=20
> HTH
> Gerhard
>=20
> --
> Gerhard Jaeger <gjaeger@sysgo.com>
> SYSGO AG Embedded and Real-Time Software
> www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
>=20
> _______________________________________________
> 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