John Linn wrote:
Ah I see, sorry about that, misunderstood what was needed.
So there may be other ways as I'm not a Git expert, but I clone the
repository, then reset to the a Git tag.
git reset --hard tag name
We're working on a new frame buffer driver for a new core, but the old
frame
Vince Asbridge wrote:
Stephane,
Thanks so much for your prompt reply.
We will pursue your suggestions, and let the forum know what we find. We're
at 1.3.0 uboot version.
Vince
-Original Message-
From: Fillod Stephane [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 14, 2008 8:06
[EMAIL PROTECTED] wrote:
Hello folks,
we run a proprietary board with Freescale MPC8641D using U-boot 1.1.4
and Linux kernel 2.6.23
I read in the logs some messages that 2.6.23 does contain some bugs
related to PCIe
Correct.
and it would be a good choice to upgrade to 2.6.25. Is
this
Victor Gallardo wrote:
I used the glacier.dts file as a base line. Is the
glacier.dts file in dts-v1 format?
Does it start with a /dts-v1/ declaration?
jdl
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
Vitaly Bordug wrote:
On Wed, 18 Jun 2008 22:45:57 +0400
Matvejchikov Ilya [EMAIL PROTECTED] wrote:
I'm glad that you have corrected it. Half a year ago I pointed out
that there was such a mistake:
http://patchwork.ozlabs.org/linuxppc/patch?id=10700
You've used -embedded ML, and patch wasn't
Leonid wrote:
Hi:
Hi.
1) Is the usage of device tree absolutely mandatory for powerpc boards
or just recommended and by combining appropriate defines in u-boot and
linux it can be avoided?
Consider it mandatory.
2) I understood that I can add my proprietary drivers without creating
vb wrote:
I recently ported two platforms (8245 and 8541) from ppc tree in
earlier 2.6 versions into powerpc tree in 2.6.25. It is amazing how
little the device tree contents are described, a lot of things
required reverse engineering of the kernel code to understand the
meaning of some numbers
Also sprach Zarathustra und Stefan Roese:
I hope -b 0 is set by default in recent dtc versions.
Und Git antwortete:
commit 548767f42eb00a2bac6f2a1361b7fd49f7b76908
Author: David Gibson [EMAIL PROTECTED]
Date: Fri May 16 13:22:57 2008 +1000
dtc: Rework handling of boot_cpuid_phys
Scott Wood wrote:
There are ways of debugging that don't involve a debugger.
I suppose we could get all tautological and start claiming
that anything that helped one debug something might be, by
definition, a debugger. :-)
(de-)buggering off,
jdl
Timur Tabi wrote:
Marco Stornelli wrote:
No, it didn't. I have the same problem even with the 2.6.18 plus the
2.6.24 PCI-Express code. I performed this action because I can't change
kernel version but I can modify it.
Please try 2.6.24 (or even better, 2.6.25-rc2). You may have done
Marco Stornelli wrote:
When I try to read some register from my FPGA (virtex5) I have this bus
error:
Hmmm OK, so if we've eliminated PCI-E as a source
for this issue, it really must be in the Virtex support
somewhere then. Unfortunately, I know nothing about those,
and am not going to
maxime louvel wrote:
Hi,
first of all I am sorry if this is not the good place to ask that but I
don't know where else ...
My question is:
Does anyone knows the difference between the mpc8548amc and mpc8548cds
platforms ?
Sorry, no knowledge of the AMC board here.
I am working on an
maxime louvel wrote:
Hi,
I am trying to make a 2.6.24 vanilla kernel boot (an work fine in a
second time) on a mpc8548amc board.
I have add the platform specific stuff from the sources of the current
kernel running on the cards.
What I have basically add is:
- a folder mpc8548amc, in
maxime louvel wrote:
Thanks for your answer,
I am going to check this ppc / powerpc things.
I should use the architecture powerpc, don't I?
ARCH == ppc is scheduled for _removal_ from the
entire Kernel source base is just about 4 months.
Feel free to move the deck chairs around. :-)
I'm
Johan Borkhuis wrote:
Hello,
I was using kernel version 2.6.14 (ppc) on a MVME3100 board (MPC8540
processor). We are planning to move to 2.6.20 (powerpc), but I have some
problems with the initialization of a PCI-PCI bridge.
Connected to the MVME3100 board is a PCI-PCI bridge (HiNT,
Steven Hein wrote:
Is there a document anywhere that describes how to submit
patches for the powerpc kernel?Or do I just create the patch
(I'm learning about git right now...) again the paulus/powerpc.git
tree, and send it to this list?
Correct. Don't just lean toward git, actually
On Tue, 2008-01-15 at 11:07, Scott Wood wrote:
On Tue, Jan 15, 2008 at 11:01:33AM -0600, Jon Loeliger wrote:
If it is the former group, 824x, perhaps some of the parts
in embedded6xx/ are usable?
Not all 824x fall into that category; for example, 8248 is pq2.
Gah. Of course
John Williams wrote:
Well, copying multiple configuration files into the kernel is not ideal.
Well, some advances in the DTC are being developed to help
mitigate the proliferation of DTS files there. It's still
slow going, but we're working on it...
Surely a little perl or python script
Matt Sealey wrote:
The orderable part numbers add 3 or 4 characters to the front and about
8 after. There is a difference between MPC7400 and PPC7400, and the
low voltage versions, and the different clock speeds. Orderable part
number for a recent G4 might be PPC7448B1333NL -
Yeah, part,
On Tue, 2007-09-18 at 03:06, Bartlomiej Sieka wrote:
The following switches to dtc taken from
http://www.denx.de/wiki/UBoot/UBootFdtInfo work for me:
dtc -b 0 -V 17 -R 4 -S 0x3000 -I dts -O dtb -f tqm5200.dts tqm5200.dtb
-V 17 is the current default, btw.
jdl
On Thu, 2007-04-26 at 13:36, Charles Krinke wrote:
I have a linux-2.6.17.11 source tree that has configs for two boards.
One has an 8241 and the other has an 8541. The kernel code works fine on
the 8241, but appears to lock up in my custom driver in the 8541 when
interrupts are enabled.
OK,
On Fri, 2007-04-06 at 08:33, Gary Schumacher wrote:
I am in the process of upgrading a Linux kernel from 2.4,20 to 2.6.20 on
a proprietary board that uses the PPC 750Fx (without Open Firmware) and
am having the following problems:
I'm afraid I can't speak to the 750.
1. Is there more
On Wed, 2007-03-14 at 16:42, Benedict, Michael wrote:
dtc- development snapshot dtc-20060419.tar.gz and recent git
sources
U-boot - 1.2.0, git sources from denx.de, and git sources from freescale
Kernel - 2.6.20.1, 2.6.20.2, and freescale git sources
Do yourself a favor and get an
So, like, the other day Benjamin Herrenschmidt mumbled:
Note that there are still things that we might want to change. For
example, I think we really should look into adding a macro mecanism
and/or an include mecanism to dtc so that we can do things like #include
ibm440gp.dtc to get the base
On Wed, 2006-12-06 at 10:21, Grant Likely wrote:
Add the -f flag to dtc to ignore the missing /chosen node error
Use the -O dtb flag to output a fdt blob
Oh, and like Kumar said, you need the -V 0x10 flag to generate the
correct blob version.
Oh, and, -V 0x10 is the default now with a
On Wed, 2006-11-01 at 02:39, Grant Likely wrote:
You'll also need to get the lite5200 device tree patch for u-boot off the
u-boot-users mailing list, and the device tree compiler from www.jdl.com.
Device tree is compiled w/:
$ dtc -V 0x10 -f -O dtb arch/powerpc/boot/dts/lite5200b.dts
On Fri, 2006-10-27 at 10:04, Nicolas DET wrote:
diff -uprN a/include/asm-powerpc/mpc52xx.h b/include/asm-powerpc/mpc52xx.h
--- a/include/asm-powerpc/mpc52xx.h 1970-01-01 01:00:00.0 +0100
+++ b/include/asm-powerpc/mpc52xx.h 2006-10-27 15:51:55.0 +0200
@@ -0,0 +1,414 @@
On Tue, 2006-09-12 at 10:58, Kim Phillips wrote:
I boot the board with U-Boot (version 1.1.4, customized), and I assume
that I need to add some stuff for this new device tree thing, but I
can't figure out exactly what the kernel will expect.
the kernel expects a pointer to a device tree
On Tue, 2006-08-08 at 14:12, Matthew McClintock wrote:
This is a patch to u-boot with the changes.
* Patch to modify ft_build.c to update flat device trees in place
Patch by Matthew McClintock 26-June-2006
Signed-off-by: Matthew McClintock msm at freescale.com
Also FYI, I have assembled
On Mon, 2006-07-31 at 08:39, Vitaly Bordug wrote:
On Mon, 31 Jul 2006 08:37:56 +0100
Demke Torsten-atd012 torsten.demke at motorola.com wrote:
Hi all,
with a recent versions from Paulus merge-tree the compilation
of MPC85xx CDS failed with following output:
...
No, since it is
So, like, the other day fengcheng lu mumbled:
I downloaded this patch from
http://patchwork.ozlabs.org/linuxppc/patch?id=3D4910. But I failed to apply
it. The following is the output:
debian:/usr/src/linux-2.6.16# patch -p1 powerpc.patch
patching file
So, like, the other day Arnd Bergmann mumbled:
[MPIC]
Shouldn't all this come from the device tree?
...
+/* PCI interrupt controller */
+#define PIRQ0A MPC85xx_IRQ_EXT0
+#define PIRQ0B MPC85xx_IRQ_EXT1
+#define PIRQ0C
On Tue, 2006-01-31 at 14:31, Peter Korsgaard wrote:
Tom == Tom Rini trini at kernel.crashing.org writes:
Tom I would suggest either Linus' current git tree or 2.6.16-rc1 if
Tom you don't use git. But please bear in mind that since this is a
Tom new feature (a new board) it won't be
Signed-off-by: Jon Loeliger jdl at freescale.com
Signed-off-by: Kumar Gala kumar.gala at freescale.com
-- next part --
A non-text attachment was scrubbed...
Name: mem_pieces_cleanup.patch
Type: text/x-patch
Size: 9638 bytes
Desc: not available
Url :
http://ozlabs.org/pipermail
On Thu, 2005-06-16 at 02:08, David Gibson wrote:
I now have a git tree for the device tree compiler up at
http://www.ozlabs.org/~dgibson/dtc/dtc.git
Very Cool!
And, um, rats. So, I'm the victim of an aggressive
and anti-social IT Firewall poo-poolicy Or maybe I
am just being dumb and
On Thu, 2005-06-16 at 16:15, Jerry Van Baren wrote:
And, um, rats. So, I'm the victim of an aggressive
and anti-social IT Firewall poo-poolicy Or maybe I
am just being dumb and haven't Googled up the Right Magic.
Door number 3, I am dumb.
Is there a way to set an HTTP Proxy
On Tue, 2005-06-07 at 22:06, Benjamin Herrenschmidt wrote:
It's basically used to extract some infos directly from the flattened
tree in order to construct the LMB list (list of memory blocks,
equivalent of ppc32's mem_pieces),
OK. So the unflattenting process requires a small amount
of
Ben and Folks,
I've read through ppc64/kernel/prom.c and done some minor
call-chain analysis rooted at the two functions:
early_init_devtree()
unflatten_device_tree()
as they are apparently the only two referenced in the
initial early boot up process.
My notion was to take the portion of
On Wed, 2005-06-01 at 03:26, Benjamin Herrenschmidt wrote:
Here's the fourth version of my document along with new kernel patches
for the new improved flattened format, and the first release of the
device-tree compiler tool. The patches will be posted as a reply to
this email. The compiler,
On Wed, 2005-06-01 at 03:26, Benjamin Herrenschmidt wrote:
DO NOT REPLY TO ALL LISTS PLEASE ! (and CC me on replies).
Here's the fourth version of my document along with new kernel patches
for the new improved flattened format, and the first release of the
device-tree compiler tool. The
On Mon, 2005-05-30 at 05:13, Clemens Koller wrote:
Hello, Jon!
I guess there is a little typo:
spped - speed?
Rats.
Thanks for looking into the mess, and catching that!
jdl
On Thu, 2005-05-26 at 18:08, Kumar Gala wrote:
Jon,
Can you break the patch up into a few pieces, it will be easier to
review that way. Here are the following pieces that make sense to me:
0. New firmware interface (fw_bdt*, Kconfig, ...)
1. board code changes (everything in
On Thu, 2005-05-26 at 18:08, Kumar Gala wrote:
Jon,
Can you break the patch up into a few pieces, it will be easier to
review that way. Here are the following pieces that make sense to me:
0. New firmware interface (fw_bdt*, Kconfig, ...)
1. board code changes (everything in
On Thu, 2005-05-26 at 18:08, Kumar Gala wrote:
Jon,
Can you break the patch up into a few pieces, it will be easier to
review that way. Here are the following pieces that make sense to me:
0. New firmware interface (fw_bdt*, Kconfig, ...)
1. board code changes (everything in
On Thu, 2005-05-26 at 18:08, Kumar Gala wrote:
Jon,
Can you break the patch up into a few pieces, it will be easier to
review that way. Here are the following pieces that make sense to me:
0. New firmware interface (fw_bdt*, Kconfig, ...)
1. board code changes (everything in
/bdt_cleanup_git.patch.gz
Signed-off-by: Jon Loeliger jdl at freescale.com
Please let me know if there are difficulties retrieving it.
This patch has a few caveats associated with it.
In particular, it does not address the entire
arch/ppc/boot/simple
issue at all. And for that reason, this patch
On Thu, 2005-05-19 at 01:41, Jakob Viketoft wrote:
Hello Jon!
Any news on the port of the OF-layer to ppc32? I'd love to hear some
more and it would be great be able to help out, even though I have some
heavy deadlines hanging over me for the next 2 months. From what I can
see on the
On Thu, 2005-04-14 at 04:54, Jakob Viketoft wrote:
Has any more happened on this off-list,
Not by me. A couple folks are also known to be on vacation.
or it is just in testing-mode right now?
likely. Still waiting for feedback such as yours! (Thanks!)
I applied the changes to a
On Thu, 2005-04-07 at 12:49, Tom Rini wrote:
Please post to the list as an RFC. Thanks.
Folks,
Apologies to those who have received this notice twice.
I first sent it to the list where it was summarily
denied for size reasons.
I have now posted a tgz file here instead:
On Thu, 2005-03-31 at 06:33, Jon Masters wrote:
Kumar Gala wrote:
| My intention was to give a device tree structure to the kernel at boot
| time via a (pseudo?) pointer in bd_info or similar.
This got resurrected recently.
Hi!
| I think this is reasonable. The best device tree would
On Thu, 2005-03-31 at 02:22, Li Yang-r58472 wrote:
Good point.
There is also IMMR need to be passed from bootloader to kernel. We
can make more use of the u-boot bd_info mechanism. But it binds ppc
linux to u-boot boot loader. I don't know if we should make it a
porting convention.
Hi
On Fri, 2005-03-04 at 09:53, Jaka Mo?nik wrote:
hello!
I don't really know if this mailing list is the proper place to direct
questions regarding U-Boot, but I've seen some preceding posts about it,
so I thought I'd ask...
Let's start with: The U-Boot list is over at:
u-boot-users
On Wed, 2004-10-13 at 22:13, Kumar Gala wrote:
Have you turned on emulation of FP in the kernel?
- kumar
On Oct 13, 2004, at 4:01 PM, Dan Malek wrote:
On Oct 13, 2004, at 1:07 PM, Laurent Lagrange wrote:
The console is mapped on SCC1 port.
CCSRBAR is mapped at 0xF800
On Wed, 2004-07-14 at 02:00, Stefan Nickl wrote:
Btw: Can support for the 8541 be expected anytime soon?
I added some #defines to my platform code, but I didn't look
closely into it's incarnation of the CPM yet.
--
Stefan Nickl
Kontron Modular Computers
Just yesterday, I was
On Thu, 2004-04-15 at 05:08, Gerrit Van de Velde wrote:
Hi,
I was wondering how well the mpc85xx of motorola (PowerPC e500 core) is
currently supported in the linux/u-boot combination.
Can anyone give some pointers about this matter ?
Kind regards,
Gerrit Van de Velde
Hi Gerrit,
I am
On Thu, 2004-04-15 at 10:05, Dan Malek wrote:
Jon Loeliger wrote:
I am planning to release an updated version of the mpc85xx support
for U-Boot in just a few days. It will be updated to Rev 1.1 and
has major improvements to the TSEC driver.
Major improvements? I recently posted
56 matches
Mail list logo
