* 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
* 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: 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
* 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: 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: 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: 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: 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: 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: 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: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: 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: 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: 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: 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: 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: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: 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: Wolfgang Denk @ 2006-04-25 21:25 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20060425184857.GB1132@gate.ebshome.net>
In message <20060425184857.GB1132@gate.ebshome.net> you wrote:
>
> Yes. This was suggested numerous number of times. Kumar, for some
> reason which I don't understand, keeps ignoring this.
>
> And yes, I think person who breaks compatibility is the one who should
> be doing this work :).
Agreed. No smiley here.
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
The software required `Windows 95 or better', so I installed Linux.
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <E29663C3-8289-443F-BF7A-F973EC41CC72@kernel.crashing.org>
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?
> 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.
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
As far as we know, our computer has never had an undetected error.
-- Weisert
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <265F73F8-F641-4EDD-B88F-A2B2F7FA1308@kernel.crashing.org>
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.
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
No one can guarantee the actions of another.
-- Spock, "Day of the Dove", stardate unknown
^ permalink raw reply
* Re: 85xx FDT updates?
From: Kumar Gala @ 2006-04-25 21:19 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <20060425211639.DD1E8353DAC@atlas.denx.de>
On Apr 25, 2006, at 4:16 PM, Wolfgang Denk wrote:
> In message <6F7CAB43-B4C0-47DA-
> BC7D-3FD04A552131@kernel.crashing.org> you wrote:
>>
>> If we are talking about a reference board than I think this is an
>> absurd requirement. If you are willing to update your kernel on such
>> a board why would you not be willing to update the firmware as well.
>
> For example, because I don't own it and have to return it in the
> original state.
>
> For example, because U-Boot is in a ROM which cannot be written to
> without special tools.
>
> Kumar, please try seeing the world from the eyes of a *user*, not the
> developer you and me are.
>
> We should help the users, not make their live harder than necessary.
Which users are you speaking of, end users or developers that will
use u-boot & linux for building a product?
- kumar
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <6F7CAB43-B4C0-47DA-BC7D-3FD04A552131@kernel.crashing.org>
In message <6F7CAB43-B4C0-47DA-BC7D-3FD04A552131@kernel.crashing.org> you wrote:
>
> If we are talking about a reference board than I think this is an
> absurd requirement. If you are willing to update your kernel on such
> a board why would you not be willing to update the firmware as well.
For example, because I don't own it and have to return it in the
original state.
For example, because U-Boot is in a ROM which cannot be written to
without special tools.
Kumar, please try seeing the world from the eyes of a *user*, not the
developer you and me are.
We should help the users, not make their live harder than necessary.
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
If you believe that feeling bad or worrying long enough will change a
past or future event, then you are residing on another planet with a
different reality system.
^ permalink raw reply
* Re: Kernel panic on mpc852.
From: Wolfgang Denk @ 2006-04-25 21:12 UTC (permalink / raw)
To: Gautam Borad; +Cc: linuxppc-embedded
In-Reply-To: <444E2ABA.60400@eisodus.com>
In message <444E2ABA.60400@eisodus.com> you wrote:
>
> I'm trying to port linux-2.4.21 to mpc852t custom board.
> The bootloader (u-boot) works fine and the kernel boots.
> The kernel is _VERY_ unstable, in that it gives sig 11
> ( Oops: kernel access of bad area, sig: 11 ) at random
> intervals.
2.4.21 is *very* old. I recommend to use a more recent (and better
supported) version of the kernel.
And please read the FAQ, especially
http://www.denx.de/wiki/view/DULG/LinuxCrashesRandomly
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
Disc space - the final frontier!
^ permalink raw reply
* Re: 85xx FDT updates?
From: Wolfgang Denk @ 2006-04-25 21:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <34C11E8A-ED04-490F-B601-841DC1F94AD6@kernel.crashing.org>
In message <34C11E8A-ED04-490F-B601-841DC1F94AD6@kernel.crashing.org> you wrote:
>
> > What about systems that can't update u-boot, but want to run
> > a newer kernel?
>
> Does this situation exist for any in tree boards that are supported?
Probably. We don't know what our users do. Not so few of the projects
run a policy on never touching U-Boot.
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
The only way to get rid of a temptation is to yield to it.
- Oscar Wilde
^ 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