* where is the kernel source for ppc embedded?(may sound stupid)
From: Lei Sun @ 2006-07-17 15:44 UTC (permalink / raw)
To: linuxppc-embedded
Hi:
I am taking another guys porting work, he downloaded 2.4.30 for ppc.
I was looking at http://www.denx.de/, and kernel.org, didn't feel like
it was from there, since the current source tree only have arch/ppc
directory, no other arch specific tree.
So where i should download 2.4.30 with all patch applied?
Thanks
ls
^ permalink raw reply
* Re: where is the kernel source for ppc embedded?(may sound stupid)
From: Grant Likely @ 2006-07-17 17:15 UTC (permalink / raw)
To: Lei Sun; +Cc: linuxppc-embedded
In-Reply-To: <f9a7e7a80607170844v1626009at43766449872bd25f@mail.gmail.com>
On 7/17/06, Lei Sun <leisun124@gmail.com> wrote:
> Hi:
> I am taking another guys porting work, he downloaded 2.4.30 for ppc.
> I was looking at http://www.denx.de/, and kernel.org, didn't feel like
> it was from there, since the current source tree only have arch/ppc
> directory, no other arch specific tree.
> So where i should download 2.4.30 with all patch applied?
http://penguinppc.org/kernel/
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: where is the kernel source for ppc embedded?(may sound stupid)
From: Lei Sun @ 2006-07-17 18:29 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0607171015i5a6048aaje2d9ec557fbde22d@mail.gmail.com>
I looked at that website, and it suggested downloading kernel from
kernel.org. I've downloaded , but apparently, it's different with what
I have right now, there is no ADS8260 and PQ2FADS-VR board type . I
think there are some patch for that board already, where can I find
those patches?
Thanks
ls
On 7/17/06, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 7/17/06, Lei Sun <leisun124@gmail.com> wrote:
> > Hi:
> > I am taking another guys porting work, he downloaded 2.4.30 for ppc.
> > I was looking at http://www.denx.de/, and kernel.org, didn't feel like
> > it was from there, since the current source tree only have arch/ppc
> > directory, no other arch specific tree.
> > So where i should download 2.4.30 with all patch applied?
>
> http://penguinppc.org/kernel/
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
^ permalink raw reply
* Re: where is the kernel source for ppc embedded?(may sound stupid)
From: Grant Likely @ 2006-07-17 18:52 UTC (permalink / raw)
To: Lei Sun; +Cc: linuxppc-embedded
In-Reply-To: <f9a7e7a80607171129r3b541087l73a57bc3c8108e43@mail.gmail.com>
On 7/17/06, Lei Sun <leisun124@gmail.com> wrote:
> I looked at that website, and it suggested downloading kernel from
> kernel.org. I've downloaded , but apparently, it's different with what
> I have right now, there is no ADS8260 and PQ2FADS-VR board type . I
> think there are some patch for that board already, where can I find
> those patches?
Try the "no longer used" tree listed at the bottom of the page if you
want a 2.4 kernel.
If you want 2.6, use kernel.org
I don't know if ADS8260 or PQ2FADS-VR support is in either tree.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Kumar Gala @ 2006-07-17 19:16 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <a0bc9bf80607140921y5d11bf37r3f18e2dbdd03b017@mail.gmail.com>
On Jul 14, 2006, at 11:21 AM, Li Yang wrote:
> On 7/14/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>> Nack, my expectation is this is all setup by the boot loader.
>
> That's a good wish. ;) However, USB is not required by bootloader. So
> it is not likely to be initialized there. And if we put it in
> bootloader, it will be hard to change the mode(MPH/DR), which requires
> a re-burn of bootloader. It's better that we make sure it's correctly
> configured here.
I disagree. You are coming from this from a board that does
everything under the sun. I'd like to avoid having this type of
initialization in the kernel. There is a whole additional kitchen
sink that could move into the kernel as well.
- kumar
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Hollis Blanchard @ 2006-07-17 20:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <A4F686A1-9558-4DD0-BF4C-BB64494BB719@kernel.crashing.org>
On Mon, 2006-07-17 at 14:16 -0500, Kumar Gala wrote:
> On Jul 14, 2006, at 11:21 AM, Li Yang wrote:
>
> > On 7/14/06, Kumar Gala <galak@kernel.crashing.org> wrote:
> >> Nack, my expectation is this is all setup by the boot loader.
> >
> > That's a good wish. ;) However, USB is not required by bootloader. So
> > it is not likely to be initialized there. And if we put it in
> > bootloader, it will be hard to change the mode(MPH/DR), which requires
> > a re-burn of bootloader. It's better that we make sure it's correctly
> > configured here.
>
> I disagree. You are coming from this from a board that does
> everything under the sun. I'd like to avoid having this type of
> initialization in the kernel. There is a whole additional kitchen
> sink that could move into the kernel as well.
Seems to me that it's far better to have init code in the kernel than
firmware. For one example, look at the x86 video card init problem
PowerPC Linux has. It's also far easier to fix/deploy Linux code than
firmware code, as Li observed, and on top of that it's less work for
non-UBoot firmwares in the future.
-Hollis
^ permalink raw reply
* kernel memory map/usage/holes?
From: Chris Friesen @ 2006-07-17 20:06 UTC (permalink / raw)
To: linuxppc-dev
I've got a Maple board with 4GB of memory running a modified 2.6.10
kernel. When it boots, I see the following in the logs:
Top of RAM: 0x180000000, Total RAM: 0x100000000
On node 0 totalpages: 1048576
DMA zone: 1048576 pages, LIFO batch:16
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Then a bit later, I see:
Memory: 4006976k/6291456k available (3408k kernel code, 2284124k
reserved, 1656k data, 448k bss, 220k init)
1048576 pages works out to 4194304kB, so what happened to the 187328kB
that is the difference between the "Total RAM" and "Memory:" lines?
We've got an app that wants as much memory as possible, so I need to
explain where this 183MB of memory is being used.
Thanks,
Chris
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Dan Malek @ 2006-07-17 20:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <A4F686A1-9558-4DD0-BF4C-BB64494BB719@kernel.crashing.org>
On Jul 17, 2006, at 3:16 PM, Kumar Gala wrote:
> I disagree. You are coming from this from a board that does
> everything under the sun. I'd like to avoid having this type of
> initialization in the kernel. There is a whole additional kitchen
> sink that could move into the kernel as well.
Well, I'm going to have to disagree with your disagreement :-)
The kernel should not assume things are properly initialized
and rely on the boot rom to do such things. I have several
reasons for this. One is that we are always pressed to make
embedded systems boot more quickly, and taking time to
initialize things in the boot rom just makes that a totally
inflexible system design. We don't need to initialize things
we don't use, or can postpone until later. Two, it makes
us dependent upon a particular boot rom, or boot rom
behavior, that not all boards may choose to support.
Three, board designs may have external logic that requires
a certain start up sequence or control register access
that complicates the boot rom in it's ability to share
code or implementation.
There are more, but I think you see the trend. In my
years of doing this kind of development, you can't
assume a boot rom is going to do much more than initialize
memory and load the kernel. I prefer the flexibility
to be in the kernel, and not in the boot rom, because it
is so much easier to develop and control.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Kumar Gala @ 2006-07-17 21:39 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <5C69B7C2-1637-4B9A-BDCA-596DBE70A7DC@embeddedalley.com>
On Jul 17, 2006, at 3:17 PM, Dan Malek wrote:
>
> On Jul 17, 2006, at 3:16 PM, Kumar Gala wrote:
>
>> I disagree. You are coming from this from a board that does
>> everything under the sun. I'd like to avoid having this type of
>> initialization in the kernel. There is a whole additional kitchen
>> sink that could move into the kernel as well.
>
> Well, I'm going to have to disagree with your disagreement :-)
> The kernel should not assume things are properly initialized
> and rely on the boot rom to do such things. I have several
> reasons for this. One is that we are always pressed to make
> embedded systems boot more quickly, and taking time to
> initialize things in the boot rom just makes that a totally
> inflexible system design. We don't need to initialize things
> we don't use, or can postpone until later. Two, it makes
> us dependent upon a particular boot rom, or boot rom
> behavior, that not all boards may choose to support.
> Three, board designs may have external logic that requires
> a certain start up sequence or control register access
> that complicates the boot rom in it's ability to share
> code or implementation.
Well, I think there is a coupling that exists between whatever your
boot rom is and the kernel. If you are trying to optimize boot time
I'd say one thing you would want is to avoid multiple writing the
same configuration registers.
I dont have an issue if a fixed function board decides to do these
things in their kernel init instead of their boot rom. I however,
don't want thousand and one config options to support all the various
ways one can configure the Freescale board.
> There are more, but I think you see the trend. In my
> years of doing this kind of development, you can't
> assume a boot rom is going to do much more than initialize
> memory and load the kernel. I prefer the flexibility
> to be in the kernel, and not in the boot rom, because it
> is so much easier to develop and control.
- kumar
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Dan Malek @ 2006-07-17 22:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <71D808D5-8227-4B0D-AF41-FADFC4B12463@kernel.crashing.org>
On Jul 17, 2006, at 5:39 PM, Kumar Gala wrote:
> Well, I think there is a coupling that exists between whatever your
> boot rom is and the kernel.
There shouldn't be, I've always said that, but Freescale
seems to want to insist on it :-) The problem is people
creating this evaluation/demo boards seem to think
they are workstations, which they are not. There is
such a minimal amount of information needed to
actually get a system from the boot rom to the kernel
that I don't understand why we are complicating this
process for embedded systems.
Here is my product development experience. People
buy these evaluation boards to test a few of the features
they need for a product. These boards try to be everything
to everyone, but in reality have never done what someone
has wanted very well. Products developed using Linux
and many different boot roms are very focused on a particular
set of features. Their requirements are nothing like that of
an evaluation board, and all of these cute workstation
features we are pushing into these evaluation board ports
do nothing to help get these products customized for market.
> If you are trying to optimize boot time I'd say one thing you would
> want is to avoid multiple writing the same configuration registers.
That's what I said. Just do it in Linux when the feature is
started, either as a built-in driver or loadable module. No
need to do this in a boot rom if there isn't any need for it.
> I dont have an issue if a fixed function board decides to do these
> things in their kernel init instead of their boot rom. I however,
> don't want thousand and one config options to support all the
> various ways one can configure the Freescale board.
I don't understand how configuration options fit into this
discussion. In this particular discussion, if you have selected
the USB option, then include the proper initialization code
in the kernel for the board. No additional options needed.
Thanks.
-- Dan
^ permalink raw reply
* Re: Using bestcomm in an external module (MPC5200B to be exact)
From: Sylvain Munaut @ 2006-07-17 22:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-embedded
In-Reply-To: <1151710395.27137.7.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
>> But anyway, it's mainly internal cleanup and adapting drivers
>> from the public version on my git tree to this newest/cleaner
>> version is a 15 min work ;)
>>
>
> Any reason why you aren't regulary submitting those patches for upstream
> inclusion ?
>
Yes. What's in there and not in main streams adds quite a lot to
arch/ppc ... So
MPC5200 should be adapted to arch/powerpc first and then those changes.
And since
no-one did that yet and I haven't done it yet either ... (I must admit I
had a quick look
and I didn't understand much on how to do the change ...)
Sylvain
PS: Sorry for the lag (like 15 days...) you know email
problem/appartement change/vacation/... the usual ;)
^ permalink raw reply
* Re: [PATCH] panic_on_oops: remove ssleep()
From: Andi Kleen @ 2006-07-17 22:27 UTC (permalink / raw)
To: Horms
Cc: Andrew Morton, Chris Zankel, Tony Luck, linux-ia64, discuss,
linux-kernel, linuxppc-dev, Paul Mackerras, Anton Blanchard,
Russell King
In-Reply-To: <31687.FP.7244@verge.net.au>
On Monday 17 July 2006 18:17, Horms wrote:
> This patch is part of an effort to unify the panic_on_oops behaviour
> across all architectures that implement it.
>
> It was pointed out to me by Andi Kleen that if an oops has occured
> in interrupt context, then calling sleep() in the oops path will only cause
> a panic, and that it would be really better for it not to be in the path at
> all.
>
> This patch removes the ssleep() call and reworks the console message
> accordinly. I have a slght concern that the resulting console message is
> too long, feedback welcome.
Keeping the delay might be actually useful so that you can see the panic
before system reboots when reboot on panic is enabled. I would just use a loop
of mdelays(1) with touch_nmi_watchdog/touch_softirq_watchdog()s
inbetween.
-Andi
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
From: David Brownell @ 2006-07-17 22:57 UTC (permalink / raw)
To: linux-usb-devel; +Cc: linuxppc-dev
In-Reply-To: <1153166894.4459.4.camel@basalt.austin.ibm.com>
On Monday 17 July 2006 1:08 pm, Hollis Blanchard wrote:
>
> Seems to me that it's far better to have init code in the kernel than
> firmware.
If there's a general Linux policy on the issue, I think that'd be it.
Plus, remember that boot firmware _can't_ always be changed/bugfixed;
sometimes it can, but not as a general rule.
- Dave
> For one example, look at the x86 video card init problem
> PowerPC Linux has. It's also far easier to fix/deploy Linux code than
> firmware code, as Li observed, and on top of that it's less work for
> non-UBoot firmwares in the future.
>
> -Hollis
>
^ permalink raw reply
* Re: [PATCH] panic_on_oops: remove ssleep()
From: Horms @ 2006-07-17 23:10 UTC (permalink / raw)
To: Andi Kleen
Cc: Andrew Morton, Chris Zankel, Tony Luck, linux-ia64, discuss,
linux-kernel, linuxppc-dev, Paul Mackerras, Anton Blanchard,
Russell King
In-Reply-To: <200607180027.51986.ak@suse.de>
On Tue, Jul 18, 2006 at 12:27:51AM +0200, Andi Kleen wrote:
> On Monday 17 July 2006 18:17, Horms wrote:
> > This patch is part of an effort to unify the panic_on_oops behaviour
> > across all architectures that implement it.
> >
> > It was pointed out to me by Andi Kleen that if an oops has occured
> > in interrupt context, then calling sleep() in the oops path will only cause
> > a panic, and that it would be really better for it not to be in the path at
> > all.
> >
> > This patch removes the ssleep() call and reworks the console message
> > accordinly. I have a slght concern that the resulting console message is
> > too long, feedback welcome.
>
> Keeping the delay might be actually useful so that you can see the panic
> before system reboots when reboot on panic is enabled. I would just use a loop
> of mdelays(1) with touch_nmi_watchdog/touch_softirq_watchdog()s
> inbetween.
Ok, I will look into making that happen. I agree that the pause is
quite useful.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
^ permalink raw reply
* Re: [PATCH] panic_on_oops: remove ssleep()
From: Andrew Morton @ 2006-07-18 0:23 UTC (permalink / raw)
To: Horms
Cc: chris, tony.luck, linux-ia64, discuss, ak, linux-kernel,
linuxppc-dev, paulus, anton, rmk
In-Reply-To: <20060717231056.GC12463@verge.net.au>
On Mon, 17 Jul 2006 19:10:59 -0400
Horms <horms@verge.net.au> wrote:
> On Tue, Jul 18, 2006 at 12:27:51AM +0200, Andi Kleen wrote:
> > On Monday 17 July 2006 18:17, Horms wrote:
> > ...
> > Keeping the delay might be actually useful so that you can see the panic
> > before system reboots when reboot on panic is enabled. I would just use a loop
> > of mdelays(1) with touch_nmi_watchdog/touch_softirq_watchdog()s
> > inbetween.
>
> Ok, I will look into making that happen. I agree that the pause is
> quite useful.
It's kind-of already implemented, via pause_on_oops. Perhaps doing
something like
if (panic_on_oops)
pause_on_oops = max(pause_on_oops, 5*HZ);
would be sufficient.
^ permalink raw reply
* Re: [PATCH] panic_on_oops: remove ssleep()
From: Chuck Ebbert @ 2006-07-18 1:22 UTC (permalink / raw)
To: Horms
Cc: Andrew Morton, Chris Zankel, Tony Luck, linux-ia64, discuss,
Andi Kleen, linux-kernel, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Russell King
In-Reply-To: <31687.FP.7244@verge.net.au>
On Mon, 17 Jul 2006 12:17:20 -0400, Horms wrote:
> This patch is part of an effort to unify the panic_on_oops behaviour
> across all architectures that implement it.
>
> It was pointed out to me by Andi Kleen that if an oops has occured
> in interrupt context, then calling sleep() in the oops path will only cause
> a panic, and that it would be really better for it not to be in the path at
> all.
i386 already checks in_interrupt() and panics immediately:
--- a/arch/i386/kernel/traps.c
+++ b/arch/i386/kernel/traps.c
@@ -442,11 +442,9 @@ #endif
===> if (in_interrupt())
===> panic("Fatal exception in interrupt");
- if (panic_on_oops) {
- printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
- ssleep(5);
- panic("Fatal exception");
- }
+ if (panic_on_oops)
+ panic("Fatal exception: panic_on_oops");
+
oops_exit();
do_exit(SIGSEGV);
}
--
Chuck
And did we tell you the name of the game, boy, we call it Riding the Gravy Train.
^ permalink raw reply
* reboot on PQ2FADS board.
From: Lei Sun @ 2006-07-18 3:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi:
I have linux 2.4.30 runnning on this board, the "reboot -f"
command cause machine check and kernel ooops. The problem seems in
the "m8260_gorom" in head.S. The restart() function in m8260_setup.c
passed 2 parameters to that assembly code, r3 is the bd_info , r4 is
the warm start address, I changed it to 0xFF800100, that's where the
u-boot's _start_warm lives, I have verified that address by typing "g
ff800100" in u-boot console, which cause the board reset.
I assume the m8260_gorom has been heavily tested for other
boards. I wonder if anyone got a PQ2FADS-VR board that has the similar
problem? I am not familar with the assembly code for PPC. Any
suggestions?
Thanks
lei
^ permalink raw reply
* RE: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
From: Li Yang-r58472 @ 2006-07-18 6:34 UTC (permalink / raw)
To: David Brownell, linux-usb-devel, linux-kernel; +Cc: linuxppc-dev
In-Reply-To: <200607171557.50368.david-b@pacbell.net>
> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: Tuesday, July 18, 2006 6:58 AM
> To: linux-usb-devel@lists.sourceforge.net
> Cc: Hollis Blanchard; Kumar Gala; linuxppc-dev@ozlabs.org; Li
Yang-r58472
> Subject: Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform
support
>=20
> On Monday 17 July 2006 1:08 pm, Hollis Blanchard wrote:
> >
> > Seems to me that it's far better to have init code in the kernel
than
> > firmware.
>=20
> If there's a general Linux policy on the issue, I think that'd be it.
Do we have a general policy for this now?
>=20
> Plus, remember that boot firmware _can't_ always be changed/bugfixed;
> sometimes it can, but not as a general rule.
>=20
> - Dave
>=20
>=20
> > For one example, look at the x86 video card init problem
> > PowerPC Linux has. It's also far easier to fix/deploy Linux code
than
> > firmware code, as Li observed, and on top of that it's less work for
> > non-UBoot firmwares in the future.
> >
> > -Hollis
> >
^ permalink raw reply
* RE: [PATCH] Add USB to MPC8349 PB platform support
From: Li Yang-r58472 @ 2006-07-18 7:40 UTC (permalink / raw)
To: Kumar Gala, Dan Malek; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <71D808D5-8227-4B0D-AF41-FADFC4B12463@kernel.crashing.org>
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Tuesday, July 18, 2006 5:39 AM
> To: Dan Malek
> Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org;
linux-usb-devel@lists.sourceforge.net
> Subject: Re: [PATCH] Add USB to MPC8349 PB platform support
>=20
>=20
> On Jul 17, 2006, at 3:17 PM, Dan Malek wrote:
>=20
> >
> > On Jul 17, 2006, at 3:16 PM, Kumar Gala wrote:
> >
> >> I disagree. You are coming from this from a board that does
> >> everything under the sun. I'd like to avoid having this type of
> >> initialization in the kernel. There is a whole additional kitchen
> >> sink that could move into the kernel as well.
> >
> > Well, I'm going to have to disagree with your disagreement :-)
> > The kernel should not assume things are properly initialized
> > and rely on the boot rom to do such things. I have several
> > reasons for this. One is that we are always pressed to make
> > embedded systems boot more quickly, and taking time to
> > initialize things in the boot rom just makes that a totally
> > inflexible system design. We don't need to initialize things
> > we don't use, or can postpone until later. Two, it makes
> > us dependent upon a particular boot rom, or boot rom
> > behavior, that not all boards may choose to support.
> > Three, board designs may have external logic that requires
> > a certain start up sequence or control register access
> > that complicates the boot rom in it's ability to share
> > code or implementation.
>=20
> Well, I think there is a coupling that exists between whatever your
> boot rom is and the kernel. If you are trying to optimize boot time
> I'd say one thing you would want is to avoid multiple writing the
> same configuration registers.
>=20
> I dont have an issue if a fixed function board decides to do these
> things in their kernel init instead of their boot rom. I however,
> don't want thousand and one config options to support all the various
> ways one can configure the Freescale board.
We won't have the thousand and one config options, making use of the
device
tree. So this is not a problem.
>=20
> > There are more, but I think you see the trend. In my
> > years of doing this kind of development, you can't
> > assume a boot rom is going to do much more than initialize
> > memory and load the kernel. I prefer the flexibility
> > to be in the kernel, and not in the boot rom, because it
> > is so much easier to develop and control.
>=20
> - kumar
^ permalink raw reply
* PPC440GP board hangs
From: Denny @ 2006-07-18 10:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <3DBBCC5C2604704D9351456CFE118AC10460F146@msilexch01.marvell.com>
[-- Attachment #1: Type: text/plain, Size: 4489 bytes --]
Hi,
After success uncompress the kernel to ram, it hangs,
## Transferring control to Linux (at address 0000000)
Does anyone encounter the symton on PPC440GP? I double checked my external UART clock and system clock both in hareware and software, they are all right.
the log buffer is as below:
BDI>md 0x01ed5c4 100
001ed5c4 : 0x20322e36 540159542 2.6
001ed5c8 : 0x2e313420 774976544 .14
001ed5cc : 0x28726f6f 678588271 (roo
001ed5d0 : 0x73696f6e 1936289646 sion
001ed5d4 : 0x20322e36 540159542 2.6
001ed5d8 : 0x2e313420 774976544 .14
001ed5dc : 0x28726f6f 678588271 (roo
001ed5e0 : 0x6c646f7d 1818521469 ldo}
001ed5e4 : 0x61696e29 1634299433 ain)
001ed5e8 : 0x20286763 539518819 (gc
001ed5ec : 0x63207665 1663071845 c ve
001ed5f0 : 0x6c646f7d 1818521469 ldo}
001ed5f4 : 0x61696e29 1634299433 ain)
001ed5f8 : 0x20286763 539518819 (gc
001ed5fc : 0x63207665 1663071845 c ve
001ed600 : 0x5820054c 1478493516 X .L
001ed604 : 0x444b2034 1145774132 DK 4
001ed608 : 0x2f302034 791683124 /0 4
001ed60c : 0x2e302e30 774909488 .0.0
001ed610 : 0x5820054c 1478493516 X .L
001ed614 : 0x444b2034 1145774132 DK 4
001ed618 : 0x2f302034 791683124 /0 4
001ed61c : 0x2e302e30 774909488 .0.0
001ed620 : 0x2031383a 540096570 18:
001ed624 : 0x31383a33 825768499 18:3
001ed628 : 0x34204353 874529619 4 CS
001ed62c : 0x54203630 1411397168 T 60
001ed630 : 0x2031383a 540096570 18:
001ed634 : 0x31383a33 825768499 18:3
001ed638 : 0x34204353 874529619 4 CS
001ed63c : 0x54203630 1411397168 T 60
001ed640 : 0x6e652063 1852121187 ne c
001ed644 : 0x6865636b 1751475051 heck
001ed648 : 0x20696e20 543780384 in
001ed64c : 0x6b65726e 1801810542 kern
001ed650 : 0x6e652063 1852121187 ne c
001ed654 : 0x6865636b 1751475051 heck
001ed658 : 0x20696e20 543780384 in
001ed65c : 0x6b65726e 1801810542 kern
001ed660 : 0x656c206d 1701585005 el m
001ed664 : 0x6f64652e 1868850478 ode.
001ed668 : 0x0a3c343e 171717694 .<4>
001ed66c : 0x504c4230 1347174960 PLB0
001ed670 : 0x3a204245 975192645 : BE
001ed674 : 0x41523d30 1095908656 AR=0
001ed678 : 0x78303030 2016423984 x000
001ed67c : 0x30303030 808464432 0000
001ed680 : 0x32306563 842032483 20ec
001ed684 : 0x30303030 808464432 0000
001ed688 : 0x36204143 908083523 6 AC
001ed68c : 0x523d2020 1379737632 R=
001ed690 : 0x30783962 813185378 0x9b
001ed694 : 0x30303030 808464432 0000
001ed698 : 0x30302042 808460354 00 B
001ed69c : 0x4553523d 1163088445 ESR=
001ed6a0 : 0x20307830 540047408 0x0
001ed6a4 : 0x63303030 1664102448 c000
001ed6a8 : 0x3030300a 808464394 000.
001ed6ac : 0x3c343e50 1010056784 <4>P
001ed6b0 : 0x4f42303a 1329737786 OB0:
001ed6b4 : 0x20424541 541214017 BEA
001ed6b8 : 0x523d3078 1379741816 R=0x
001ed6bc : 0x30303030 808464432 0000
001ed6c0 : 0x30303030 808464432 0000
001ed6c4 : 0x30303030 808464432 0000
001ed6c8 : 0x30303030 808464432 0000
001ed6cc : 0x20424553 541214035 BES
001ed6d0 : 0x52303d30 1378893104 R0=0
001ed6d4 : 0x78303030 2016423984 x000
001ed6d8 : 0x30303030 808464432 0000
001ed6dc : 0x30204245 807420485 0 BE
001ed6e0 : 0x5352313d 1397895485 SR1=
001ed6e4 : 0x30783030 813183024 0x00
001ed6e8 : 0x30303030 808464432 0000
001ed6ec : 0x30300a3c 808454716 00.<
001ed6f0 : 0x343e4f50 876498768 4>OP
001ed6f4 : 0x42303a20 1110456864 B0:
001ed6f8 : 0x42454152 1111834962 BEAR
001ed6fc : 0x3d307830 1026586672 =0x0
001ed700 : 0x30303030 808464432 0000
001ed704 : 0x30303030 808464432 0000
001ed708 : 0x30303030 808464432 0000
001ed70c : 0x30303020 808464416 000
001ed710 : 0x42535441 1112757313 BSTA
001ed714 : 0x543d3078 1413296248 T=0x
001ed718 : 0x30303030 808464432 0000
001ed71c : 0x30303030 808464432 0000
001ed720 : 0x0a3c343e 171717694 .<4>
001ed724 : 0x4f6f7073 1332703347 Oops
001ed728 : 0x3a206d61 975203681 : ma
001ed72c : 0x6368696e 1667787118 chin
001ed730 : 0x65206368 1696621416 e ch
001ed734 : 0x65636b2c 1701014316 eck,
001ed738 : 0x20736967 544434535 sig
001ed73c : 0x3a203720 975189792 : 7
001ed740 : 0x5b23315d 1529033053 [#1]
001ed744 : 0x0a3c343e 171717694 .<4>
001ed748 : 0x4e49503a 1313427514 NIP:
001ed74c : 0x20433030 541274160 C00
001ed750 : 0x30443946 809777478 0D9F
BDI>
Any point on this is very appreciated!
- Denny
[-- Attachment #2: Type: text/html, Size: 7306 bytes --]
^ permalink raw reply
* page locking in PowerPC cores
From: Parav Pandit @ 2006-07-18 11:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 552 bytes --]
Hi,
We allocate memory for DMA operation on PCI device using pci_alloc_constistent().
I want to know how this function is boil down to the actual instruction which locks the page in the RAM so that it cannot be paged out and dma can do its work.
Can anybody tell me which instructions do we use to set this page entry in TLB and page table?
What bit gets set in the PTE for this?
Regards,
Parav Pandit
---------------------------------
Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta.
[-- Attachment #2: Type: text/html, Size: 784 bytes --]
^ permalink raw reply
* Linux bin Commands download
From: none none @ 2006-07-18 12:35 UTC (permalink / raw)
To: linuxppc-dev
Hi
I would like to download precompiled linux commands
and programs for powerPC but i cannot find any
binaries anyware. Are there any links?
thanks in advance
sotirakopoulos andreas
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
^ permalink raw reply
* AltiVec in the kernel
From: Matt Sealey @ 2006-07-18 12:48 UTC (permalink / raw)
To: linuxppc-dev
Once upon a time we were all told this wouldn't work for some reason,
but a lot of documentation now hints that it does actually work and
for instance there is a RAID5/6 driver (for G5) which uses AltiVec
in a kernel context.
But I didn't find any definitive documentation on how one goes about
it. The largest clue I found was in Documentation/cpu_features.txt:
#ifdef CONFIG_ALTIVEC
BEGIN_FTR_SECTION
mfspr r22,SPRN_VRSAVE /* if G4, save vrsave register value */
stw r22,THREAD_VRSAVE(r23)
END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
#endif /* CONFIG_ALTIVEC */
So we can use AltiVec by implementing this kind of wrapper around
kernel functions which may use AltiVec?
In the code above is there ANY significance of r22 and r23 other
than that they are fairly high up and probably marked as "will
be trashed" by all the relevant ABIs and so?
Just curious, as I would like to investigate writing some docs at
least on this (in article fashion) to go with PPCZone, Libfreevec
and so on. I think there is a problem here in that simply developers
who may be interested in doing this kind of optimized code do not
know where to start (and we are thinking from a point of view of
also teaching sessions too, like we did at FTF Frankfurt 2004, so
after we teach them what AltiVec is etc. we demonstrate application
AND kernel functionality and the quirks associated with it).
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Kumar Gala @ 2006-07-18 13:52 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0509EB@zch01exm20.fsl.freescale.net>
[snip]
>> Well, I think there is a coupling that exists between whatever your
>> boot rom is and the kernel. If you are trying to optimize boot time
>> I'd say one thing you would want is to avoid multiple writing the
>> same configuration registers.
>>
>> I dont have an issue if a fixed function board decides to do these
>> things in their kernel init instead of their boot rom. I however,
>> don't want thousand and one config options to support all the various
>> ways one can configure the Freescale board.
>
> We won't have the thousand and one config options, making use of the
> device
> tree. So this is not a problem.
I'm talking about opening the door to a ton of options, not that we
have them now. For example, your patch doesnt handle the USB PHYs if
they are on the MDS instead of the SYS board. It doesn't handle
setting SCCR properly for different frequency choices. I'm concerned
about where to draw the line because of all the ways a user can
configure the MDS board.
- kumar
^ permalink raw reply
* Re: AltiVec in the kernel
From: Kumar Gala @ 2006-07-18 13:53 UTC (permalink / raw)
To: matt; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <004c01c6aa68$6f580d00$99dfdfdf@bakuhatsu.net>
On Jul 18, 2006, at 7:48 AM, Matt Sealey wrote:
>
> Once upon a time we were all told this wouldn't work for some reason,
> but a lot of documentation now hints that it does actually work and
> for instance there is a RAID5/6 driver (for G5) which uses AltiVec
> in a kernel context.
Using Altivec generally in the kernel is still something that is not
recommended. The key to using it is in disabling preemption, this
ensures that when the code is done the Altivec register state is back
to how the kernel found it.
preempt_disable();
enable_kernel_altivec();
raid6_altivec$#_gen_syndrome_real(disks, bytes, ptrs);
preempt_enable();
> But I didn't find any definitive documentation on how one goes about
> it. The largest clue I found was in Documentation/cpu_features.txt:
>
> #ifdef CONFIG_ALTIVEC
> BEGIN_FTR_SECTION
> mfspr r22,SPRN_VRSAVE /* if G4, save vrsave register value */
> stw r22,THREAD_VRSAVE(r23)
> END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
> #endif /* CONFIG_ALTIVEC */
>
> So we can use AltiVec by implementing this kind of wrapper around
> kernel functions which may use AltiVec?
>
> In the code above is there ANY significance of r22 and r23 other
> than that they are fairly high up and probably marked as "will
> be trashed" by all the relevant ABIs and so?
I'd guess those were the registers used by the code this was snipped
from.
> Just curious, as I would like to investigate writing some docs at
> least on this (in article fashion) to go with PPCZone, Libfreevec
> and so on. I think there is a problem here in that simply developers
> who may be interested in doing this kind of optimized code do not
> know where to start (and we are thinking from a point of view of
> also teaching sessions too, like we did at FTF Frankfurt 2004, so
> after we teach them what AltiVec is etc. we demonstrate application
> AND kernel functionality and the quirks associated with it).
I'm pretty sure Paul looked into using AltiVec for memory operations
in the kernel and didn't see a significant benefit to it.
- kumar
^ 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