* Re: alignment bugs in prom_init
From: Olaf Hering @ 2006-03-03 17:24 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev
In-Reply-To: <44086B5E.60201@smiths-aerospace.com>
On Fri, Mar 03, Jerry Van Baren wrote:
> Looks like you should use -malign-natural to make it do what you want it
Same story.
c00000000040b924: 3b 01 00 78 addi r24,r1,120
c00000000040b968: 57 08 00 38 rlwinm r8,r24,0,0,28
c00000000040b984: 4b ff d6 01 bl c000000000408f84 <.call_prom>
c00000000040b998: 80 01 00 78 lwz r0,120(r1)
,28 is even worse.
^ permalink raw reply
* [PATCH] Workaround gcc bug #26549 which causes pointers to be truncated.
From: Olaf Hering @ 2006-03-03 16:52 UTC (permalink / raw)
To: linuxppc-dev, Paul Mackeras
In-Reply-To: <20060303135717.GA5707@suse.de>
Workaround gcc bug #26549 which causes pointers to be truncated.
The address of variable val in prom_init_stdout is passed to prom_getprop.
prom_getprop casts the pointer to u32 and passes it to call_prom in the hope
that OpenFirmware stores something there.
But the pointer is truncated in the lower bits and the expected value is
stored somewhere else.
This gcc bug does not exist in SLES9 gcc33 toolchain, but it is present in
gcc4.0+, likely also in gcc3.4. Compiling a testcase without any -O produces
also correct code.
In my testing I had a stackpointer of 0x0023e6b4. val was at offset 120,
wich has address 0x0023e72c. But the value passed to OF was 0x0023e728.
c00000000040b710: 3b 01 00 78 addi r24,r1,120
...
c00000000040b754: 57 08 00 38 rlwinm r8,r24,0,0,28
...
c00000000040b784: 80 01 00 78 lwz r0,120(r1)
...
c00000000040b798: 90 1b 00 0c stw r0,12(r27)
...
simple testcase:
int f(unsigned);
void g(void)
{
unsigned a;
unsigned int b = (unsigned long)(void*)(&a);
f(b);
}
asm should look like this:
c: 38 61 00 70 addi r3,r1,112
10: 78 63 00 20 clrldi r3,r3,32
14: 48 00 00 01 bl 14 <.g+0x14>
But instead it looks like:
c: 38 61 00 70 addi r3,r1,112
10: 54 63 00 36 rlwinm r3,r3,0,0,27
14: 48 00 00 01 bl 14 <.g+0x14>
So just uninline prom_getprop to workaround this gcc bug.
c000000000409034 <.prom_getprop>:
c000000000409054: 7c bc 2b 78 mr r28,r5
c000000000409074: 7b 88 00 20 clrldi r8,r28,32
...
c00000000040b29c <.prom_init>:
...
c00000000040b3d0: 3b 41 00 74 addi r26,r1,116
...
c00000000040b3f8: e8 82 a4 a8 ld r4,-23384(r2)
c00000000040b3fc: 7f 45 d3 78 mr r5,r26
c00000000040b404: 80 7d 00 04 lwz r3,4(r29)
c00000000040b408: 38 c0 00 04 li r6,4
c00000000040b410: 4b ff dc 25 bl c000000000409034 <.prom_getprop>
...
c00000000040b424: 80 01 00 74 lwz r0,116(r1)
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/prom_init.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/kernel/prom_init.c
@@ -422,7 +422,8 @@ static int __init prom_next_node(phandle
}
}
-static int inline prom_getprop(phandle node, const char *pname,
+/* do not mark as inline to work around gcc bug #26549 */
+static int __init prom_getprop(phandle node, const char *pname,
void *value, size_t valuelen)
{
return call_prom("getprop", 4, 1, node, ADDR(pname),
^ permalink raw reply
* Re: Linux on PPC
From: David Hawkins @ 2006-03-03 16:53 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060303160434.3886335261F@atlas.denx.de>
>>If the vendor provided the VxWorks BSP, then hopefully they
>>also provided you with the physical memory map of the board.
>>This is what you really need to get another bootloader (eg. U-Boot)
>
> This is *NOT* corect, and actually dangerous.
Thanks Wolfgang!
I did start the email with "I'm not an expert on this ...".
>>Step 1. Get the memory map of the board.
>
> Never use any given memory map unreflected. At least *check* if it's
> usable with Linux.
>
> Many memory maps (especially those provides with some eval boards for
> demonstration purpose) will NOT work with Linux. Remember that the
> memory map is usually not cast in silicon, but implemented in
> software, so you can change it as needed.
Right, thats I made sure to say; Physical Memory Map.
For example, on the Artesyn manual on their PrPMC they give a
physical memory map, and in the Yosemite board, there is a
physical memory map. I know many of the memory areas can be
redefined in hardware to have a different memory location, but
its still a physical address.
Now, when the bootloader loads, eg. U-Boot, it sets up the
memory management. Now this is where my understanding gets
shakey, since I haven't looked at much of the code, so perhaps
you can clarify. The translation unit (TLB) maps virtual addresses
(or should that be MMU output addresses) into physical addresses,
and for the Yosemite port the default translation
addresses appear to be identical to the physical addresses,
though obviously this doesn't have to be the case. Then on
top of that there is virtual memory addresses generated by
the core (input to the MMU if its enabled?), that then go
through the MMU/TLB and get mapped to physical addresses. If
I was going to do a port, obviously I'd take the time to
understand this fully :) (I think the Linux Kernel Internals
book has a description, but its usually meaningless to me until
I play with the code).
What are the basic requirements for a Linux memory map then?
Cheers
Dave
^ permalink raw reply
* fbdev_drv/xfree86 getting rid of /dev/tty0 console
From: Arun @ 2006-03-03 16:27 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: RASS Arun
[-- Attachment #1: Type: text/plain, Size: 138 bytes --]
Hello Sir
I am also getting the same error with ELDK 3.1 ppc_7xx, so please help us if u are able to solve it.
Regards
Arun Kumar
[-- Attachment #2: Type: text/html, Size: 737 bytes --]
^ permalink raw reply
* Re: alignment bugs in prom_init
From: Jerry Van Baren @ 2006-03-03 15:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060303135717.GA5707@suse.de>
Olaf Hering wrote:
> Some G5 and pSeries models dont boot with recent kernels. The reason is
> likely the casting of pointers of stack variables to u32. One example is
> the prom_getprop() call in prom_init_stdout().
>
> sp is 0x0023e784, val is at offset 120, which makes 0x0023e7fc. This
> address is casted to u32, which changes it to 0x0023e7f8. The firmware
> writes to the wrong addres and things go downhill very quick.
>
> c00000000040baa8: 3b 21 00 78 addi r25,r1,120
> ..
> c00000000040baf4: 57 28 00 38 rlwinm r8,r25,0,0,28
> ..
> c00000000040bb10: 4b ff d3 3d bl c000000000408e4c <.call_prom>
>
> If I remove the casts and pass the pointer as is, everything starts to
> work as expected? Why is all this (u32)(unsigned long) casting in
> arch/powerpc/kernel/prom_init.c required?
>
> Does -Os vs -O2 make a difference here?
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hi Olaf,
The casting is 8-byte aligning the address because it is a 64 bit
variable and it is frowned on (and on some processors, fatal) to have an
8-byte variable misaligned (not on a 8 byte boundary).
In your example above, the variable is named "sp"... the sp is suppose
to be on a 8 byte boundary per the EABI (quoted below... note that the
ABI requires it to be on a 16 byte boundary):
----
The Stack Frame
Unlike the SVR4 ABI, the stack pointer (GPR1) shall maintain 8-byte
alignment, from initialization through all routine calls and dynamic
stack space allocation.
----
In the instance above, the proper solution (but I don't know if it is a
realistic solution :-/) is to properly align the stack pointer on a 8
byte boundary. I also don't know if there are other, non sp variable,
problems. It sounds like the prom isn't 64 bit clean. What are our
options to make it 64 bit clean?
Disclaimer: Yeah, I know most PPCs handle misaligned longs, but that
doesn't make it _right_ and it definitely doesn't make it efficient.
gvb
^ permalink raw reply
* Re: alignment bugs in prom_init
From: Jerry Van Baren @ 2006-03-03 16:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060303135717.GA5707@suse.de>
Olaf Hering wrote:
> Some G5 and pSeries models dont boot with recent kernels. The reason is
> likely the casting of pointers of stack variables to u32. One example is
> the prom_getprop() call in prom_init_stdout().
>
> sp is 0x0023e784, val is at offset 120, which makes 0x0023e7fc. This
> address is casted to u32, which changes it to 0x0023e7f8. The firmware
> writes to the wrong addres and things go downhill very quick.
>
> c00000000040baa8: 3b 21 00 78 addi r25,r1,120
> ..
> c00000000040baf4: 57 28 00 38 rlwinm r8,r25,0,0,28
> ..
> c00000000040bb10: 4b ff d3 3d bl c000000000408e4c <.call_prom>
>
> If I remove the casts and pass the pointer as is, everything starts to
> work as expected? Why is all this (u32)(unsigned long) casting in
> arch/powerpc/kernel/prom_init.c required?
>
> Does -Os vs -O2 make a difference here?
Hi Olaf, me again...
<http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/RS_002f6000-and-PowerPC-Options.html>
Looks like you should use -malign-natural to make it do what you want it
to do:
-malign-natural
-malign-power
On AIX, 32-bit Darwin, and 64-bit PowerPC GNU/Linux, the option
-malign-natural overrides the ABI-defined alignment of larger types,
such as floating-point doubles, on their natural size-based boundary.
The option -malign-power instructs GCC to follow the ABI-specified
alignment rules. GCC defaults to the standard alignment defined in the ABI.
On 64-bit Darwin, natural alignment is the default, and
-malign-power is not supported.
gvb
^ permalink raw reply
* Re: Linux on PPC
From: Wolfgang Denk @ 2006-03-03 16:04 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <4407CFD3.4060206@ovro.caltech.edu>
In message <4407CFD3.4060206@ovro.caltech.edu> you wrote:
>
> If the vendor provided the VxWorks BSP, then hopefully they
> also provided you with the physical memory map of the board.
> This is what you really need to get another bootloader (eg. U-Boot)
This is *NOT* corect, and actually dangerous.
> Step 1. Get the memory map of the board.
Never use any given memory map unreflected. At least *check* if it's
usable with Linux.
Many memory maps (especially those provides with some eval boards for
demonstration purpose) will NOT work with Linux. Remember that the
memory map is usually not cast in silicon, but implemented in
software, so you can change it as needed.
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
C++ was an interesting and valuable experiment, but we've learned its
lessons and it's time to move on.
- Peter Curran in <DCqM4z.BxB@isgtec.com>
^ permalink raw reply
* Re: Linux on PPC
From: Wolfgang Denk @ 2006-03-03 16:00 UTC (permalink / raw)
To: nreddy; +Cc: linuxppc-embedded
In-Reply-To: <2611.61.95.208.2.1141362572.squirrel@61.95.208.2>
In message <2611.61.95.208.2.1141362572.squirrel@61.95.208.2> you wrote:
>
> 1. You can use u-boot as a boot loader.
> 2. You can choose any standard linux kernel but you may have to do some
> R&D on it to port to your board.
> Insted you can buy Montavista Linux, so that you can get support also.
Commercial support is available not only from MV, but also from many
other companies.
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 one who says it cannot be done should never interrupt the one who
is doing it.
^ permalink raw reply
* Re: alignment bugs in prom_init
From: Olaf Hering @ 2006-03-03 15:27 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jefylz1tkh.fsf@sykes.suse.de>
On Fri, Mar 03, Andreas Schwab wrote:
> Olaf Hering <olh@suse.de> writes:
>
> > sp is 0x0023e784, val is at offset 120, which makes 0x0023e7fc. This
> > address is casted to u32, which changes it to 0x0023e7f8.
>
> Since when does casting to u32 cut off the low bits?
Way before gcc4.0 release at least.
^ permalink raw reply
* Re: boot failure on lite5200b board
From: White @ 2006-03-03 15:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <84A109BF918D934CB46ACF33BCE187C002D54D96@mail02.student.main.ntu.edu.sg>
It looks like, your mpc52xx fec is missing...
have you patched in the FEC Driver ?
>Am Fri, 3 Mar 2006 16:06:40 +0800 schrieb "#LI JIANGGAN#"
><lijianggan@pmail.ntu.edu.sg> :
>I couldn't figure out why error 101 /* Network is unreachable */ is
>given. Below is my current U-boot settings and a snapshot of the
>booting:
^ permalink raw reply
* Re: alignment bugs in prom_init
From: Andreas Schwab @ 2006-03-03 14:39 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060303135717.GA5707@suse.de>
Olaf Hering <olh@suse.de> writes:
> sp is 0x0023e784, val is at offset 120, which makes 0x0023e7fc. This
> address is casted to u32, which changes it to 0x0023e7f8.
Since when does casting to u32 cut off the low bits?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* kmod: /sbin/modprobe char-major-4 failed
From: antonio.dibacco @ 2006-03-03 14:17 UTC (permalink / raw)
To: linuxppc-embedded
Why should the kernel try to load this char-major-4? What should I configure
in the kernel to have this module not loadable but included in the kernel?
Bye,
Antonio.
^ permalink raw reply
* alignment bugs in prom_init
From: Olaf Hering @ 2006-03-03 13:57 UTC (permalink / raw)
To: linuxppc-dev
Some G5 and pSeries models dont boot with recent kernels. The reason is
likely the casting of pointers of stack variables to u32. One example is
the prom_getprop() call in prom_init_stdout().
sp is 0x0023e784, val is at offset 120, which makes 0x0023e7fc. This
address is casted to u32, which changes it to 0x0023e7f8. The firmware
writes to the wrong addres and things go downhill very quick.
c00000000040baa8: 3b 21 00 78 addi r25,r1,120
..
c00000000040baf4: 57 28 00 38 rlwinm r8,r25,0,0,28
..
c00000000040bb10: 4b ff d3 3d bl c000000000408e4c <.call_prom>
If I remove the casts and pass the pointer as is, everything starts to
work as expected? Why is all this (u32)(unsigned long) casting in
arch/powerpc/kernel/prom_init.c required?
Does -Os vs -O2 make a difference here?
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-03-03 11:23 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
More bugfixes, including a fix for the nasty timebase synchronization
bug reported by Kyle Moffett, plus a patch from Ben H. to tell
userland (via the AT_HWCAP mechanism) if the cpu has hardware threads
and if the i-cache snoops the d-cache.
Thanks,
Paul.
Benjamin Herrenschmidt:
powerpc: Fix old g5 issues with windfarm
powerpc: Fix windfarm_pm112 not starting all control loops
powerpc: Expose SMT and L1 icache snoop userland features
powerpc: incorrect rmo_top handling in prom_init
David Gibson:
powerpc: Fix incorrect pud_ERROR() message
Paul Mackerras:
powerpc: Fix might-sleep warning in program check exception handler
powerpc: Turn off verbose debug output in powermac platform functions
powerpc32: Fix timebase synchronization on 32-bit powermacs
arch/powerpc/kernel/cputable.c | 9 +++++--
arch/powerpc/kernel/prom_init.c | 2 +-
arch/powerpc/kernel/traps.c | 2 ++
arch/powerpc/platforms/powermac/pfunc_base.c | 5 ++++
arch/powerpc/platforms/powermac/pfunc_core.c | 6 +++++
arch/powerpc/platforms/powermac/smp.c | 2 +-
drivers/macintosh/windfarm_core.c | 7 ++++++
drivers/macintosh/windfarm_cpufreq_clamp.c | 8 +++++++
drivers/macintosh/windfarm_lm75_sensor.c | 32 +++++++++++++++++++-------
drivers/macintosh/windfarm_max6690_sensor.c | 25 +++++++++++++++-----
drivers/macintosh/windfarm_pm112.c | 8 ++++---
include/asm-powerpc/cputable.h | 2 ++
include/asm-powerpc/pgtable-4k.h | 2 +-
13 files changed, 85 insertions(+), 25 deletions(-)
^ permalink raw reply
* Re: incorrect rmo_top handling in prom_init
From: Olaf Hering @ 2006-03-03 11:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1141342541.13565.6.camel@localhost.localdomain>
On Fri, Mar 03, Benjamin Herrenschmidt wrote:
> On Thu, 2006-03-02 at 19:55 +0100, Olaf Hering wrote:
> > My iBook1 has 2 memory regions in reg. Depending on how I boot it
> > (vmlinux+initrd) or zImage.initrd, it will not boot with current Linus
> > tree.
> > rmo_top should be 160MB instead of 32MB.
>
> Does that fix it ?
My G5 may need similar tweaks. looking.
0 > dev /memory .properties
name memory
device_type memory
reg 00000000 00000000 10000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
slot-names 0000000f
DIMM0/J11
DIMM1/J12
DIMM2/J13
DIMM3/J14
available 00003000 0fbf9000
bank-names 0000000f
64 bit Bank0/J11/J12/front
64 bit Bank1/J11/J12/back
64 bit Bank2/J13/J14/front
64 bit Bank3/J13/J14/back
bank-sizes 10000000 00000000 00000000 00000000
dimm-info 8008070d 09014000 04607000 82100001 0e040c01 0220c075
70000048 30482a20 75754545 00000000 003c4830 2d550000
00000000 00000000 00000000 000000e7 ad000000 00000000
0148594d 44323136 20363436 41364a2d 4a202041 41033432
06873900 00000000 00000000 00000000 00000000 00000000
00000000 00000000 8008070d 09014000 04607000 82100001
0e040c01 0220c075 70000048 30482a20 75754545 00000000
003c4830 2d550000 00000000 00000000 00000000 000000e7
ad000000 00000000 0148594d 44323136 20363436 41364a2d
4a202041 41033432 06863800 00000000 00000000 00000000
00000000 00000000 00000000 00000000
... 00000200 bytes total
dimm-types DDR SDRAM
DDR SDRAM
dimm-speeds PC2700U-25330
PC2700U-25330
ram-layout-architecture 00000001
ok
^ permalink raw reply
* Re: Linux on PPC
From: Adrian Cox @ 2006-03-03 9:33 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <4407CFD3.4060206@ovro.caltech.edu>
On Thu, 2006-03-02 at 21:10 -0800, David Hawkins wrote:
> Step 2. Find a PPC 750 port in the Linux source.
>
> For example, in the 2.6 series kernel, the place to start
> looking is under arch/ppc/platforms. grep -Ie 750 shows
> up some of the PPC 750 based systems.
>
> chestnut.c 750FX/GX evaluation board
> katana.c Looks like one too
> prpmc750.c Looks like a Motorola board
>
> Look at the comments in the code, look at the memory map
> of the reference board versus your custom board. There is
> a very good chance that the custom board is based on a
> reference design - thats the whole point of them.
I'd add the caution that within the 6xx, 7xx, and 7xxx family of
processors, the north-bridge makes a much greater difference than the
processor core. Within that family of processors Linux will auto-detect
the processor specific features at boot time. It will be easier to port
from a board using a 7450 with the same north-bridge, than from a board
using a 750 with a different north-bridge.
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply
* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: Mathieu Deschamps @ 2006-03-03 9:08 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200603021706.14618.david.jander@protonic.nl>
On Thursday 02 March 2006 17:06, David Jander wrote:
> Hi,
>
> I was wondering if there is a trick or common technique I am ignoring to
> make this more efficient:
>
> This is for a 2.4 kernel based system.
> In production we use either u-boot or a NFS mounted linux system to erase
> flash and write jffs2 partitions to it. The jffs2 images are small (not
> padded to full partition size to save programming time), but the partitions
> are rather big (12 Mbyte in one case). Problem is that when booting for the
> first time, one has to wait several minutes (during which the system is
> more or less useless and busy) to get all cleanmarkers written to flash by
> the jffs2 gc thread. This huge delay is rather unacceptable for production,
> so we are looking for a work-around.
>
> One option would be to make jffs2 images that are padded to full partition
> size, but that also isn't very efficient, considering the image is only
> about 100k in beginning and the partition is 12 Mbyte in size. That would
> take a lot of time programming flash (less time than having the jffs2
> driver fix this nevertheless).
>
> Another option is making a little program that writes cleanmarkers in every
> eraseblock starting from the first completely empty one in a partition
> before mounting that partition for the very first time after flashing.
>
> Since this seems to me like a common situation, I'd like to know if anybody
> knows about a better solution, or if anybody has already dealt with this
> before.
>
> Greetings,
Hi,
"When preparing a flash partition for JFFS2, it is recommended to put
cleanmarkers to the erased blocks.
This might be done my means of "-j" option of the "flash_eraseall" MTD
utility. Otherwise, JFFS2 will re-erase the blocks
which contain all 0xFF and have no cleanmarker. This is an unneeded wasting of
time."
Source : http://www.linux-mtd.infradead.org/faq/jffs2.html
does this may be relevant ?
Best Regards,
Mathieu Deschamps.
^ permalink raw reply
* RE: boot failure on lite5200b board
From: #LI JIANGGAN# @ 2006-03-03 8:06 UTC (permalink / raw)
To: John Rigby; +Cc: haidong_feng, linuxppc-embedded
In-Reply-To: <4b73d43f0603011652w39fb4393x8879891b7538f0b1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 22566 bytes --]
Thanks John, the Kernel now boots well. However it gives a kernel panic while mounting the root file sysem over NFS:
Looking up port of RPC 100003/2 on 10.190.3.103
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
I couldn't figure out why error 101 /* Network is unreachable */ is given. Below is my current U-boot settings and a snapshot of the booting:
=> printenv
baudrate=115200
autoload=no
ethact=FEC ETHERNET
ethaddr=00:01:9F:00:27:2F
preboot=echo; echo Autostarting. Press any key to abort..; echo
bootdelay=5
hostname=icecube
bootfile=MPC5200/uImage
nv=nfsroot root=/dev/nfs rw nfsroot=10.190.3.113:/opt/eldk/rootfs
netmask=255.255.240.0
ipaddr=10.190.3.144
serverip=10.190.3.103
bootcmd=run net_nfs
netdev=eth0
rootpath=/opt/eldk-4-0/rootfs
ramargs=setenv bootargs root=/dev/ram rw
addip=setenv bootargs ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube:eth0:off panic=1
ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube:eth0:off
net_nfs=tftp 200000 MPC5200/uImage;run nfsargs;bootm
nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
rootfs=10.190.3.103:/opt/eldk-4-0/rootfs
nfsargs=setenv bootargs console=ttyS0,115200 nfsroot=10.190.3.103:/opt/eldk-4-0/nfs root=/dev/nfs rw
stdin=serial
stdout=serial
stderr=serial
Environment size: 882/65532 bytes
=> boot
Using FEC ETHERNET device
TFTP from server 10.190.3.103; our IP address is 10.190.3.144
Filename 'MPC5200/uImage'.
Load address: 0x200000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
###################################
done
Bytes transferred = 1510143 (170aff hex)
## Booting image at 00200000 ...
Image Name: Linux-2.6.11.7
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1510079 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
ocp: exit
arch: exit
Linux version 2.6.11.7 (root@bob) (gcc version 3.3.2) #1 Tue Sep 6 22:40:03 UTC 2005
Real-Time Preemption Support (c) Ingo Molnar
Built 1 zonelists
Kernel command line: console=ttyS0,115200 nfsroot=10.190.3.103:/opt/eldk-4-0/nfs root=/dev/nfs rw
PID hash table entries: 2048 (order: 11, 32768 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 256268k available (2336k kernel code, 896k data, 140k init, 0k highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
BUG: scheduling while atomic: swapper/0x00000001/0
caller is schedule+0x50/0xe8
Call trace:
[c0006bd8] dump_stack+0x18/0x28
[c0242818] __sched_text_start+0x69c/0x6a0
[c024286c] schedule+0x50/0xe8
[c0003f00] syscall_exit_work+0x108/0x10c
[c030c578] proc_root_init+0x144/0x150
[c0320000] 0xc0320000
[c02fe624] start_kernel+0x180/0x1b8
[000035fc] 0x35fc
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
softirq RT prio: 24.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
PCI: Probing PCI hardware
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
ppdev: user-space parallel port driver
Serial: MPC52xx PSC driver
ttyS0 at MMIO 0xf0002000 (irq = 39) is a MPC52xx PSC
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ipb=132MHz, set clock period to 7
GPIO config: 91051024
ATA invalid: 01000000
ATA hostcnf: 03000000
ATA pio1 : 100a0a00
ATA pio2 : 02040600
XLB Arb cnf: 0000a366
mpc52xx_ide: Setting up IDE interface ide0...
flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x0 in 8-bit bank
flash chip on the Lite5200/Lite5200B: Found 1 x16 devices at 0x1000000 in 8-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
flash chip on the Lite5200/Lite5200B: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 2
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
Creating 7 MTD partitions on "flash chip on the Lite5200/Lite5200B":
0x00000000-0x01000000 : "Filesystem"
0x01000000-0x01040000 : "BootLOW"
0x01040000-0x01060000 : "EnvLOW"
0x01060000-0x01d00000 : "Spare"
0x01d00000-0x01f00000 : "Kernel"
0x01f00000-0x01f40000 : "BootHIGH"
0x01f40000-0x01f60000 : "EnvHIGH"
ocp-ohci 02: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
i2c-algo-52xx.o: scanning bus Lite5200 I2C module #1 interface...
................................................................................................................................
i2c-lite5200.o: I2C module #1 installed
i2c-algo-52xx.o: scanning bus Lite5200 I2C module #2 interface...
................................................................................(0x50)..............................................(0x7f)
i2c-lite5200.o: I2C module #2 installed
Advanced Linux Sound Architecture Driver Version 1.0.8 (Thu Jan 13 09:39:32 2005 UTC).
ALSA device list:
No soundcards found.
NET: Registered protocol family 2
IP: routing cache hash table of 256 buckets, 16Kbytes
TCP established hash table entries: 16384 (order: 8, 1048576 bytes)
TCP bind hash table entries: 16384 (order: 7, 917504 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
Looking up port of RPC 100003/2 on 10.190.3.103
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 10.190.3.103
RPC: sendmsg returned error 101
portmap: RPC call returned error 101
Root-NFS: Unable to get mountd port number from server, using default
RPC: sendmsg returned error 101
mount: RPC call returned error 101
Root-NFS: Server returned error -101 while mounting /opt/eldk-4-0/nfs
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
<0>Rebooting in 180 seconds..
regards,
Jianggan
-----Original Message-----
From: John Rigby [mailto:jcrigby@gmail.com]
Sent: Thu 3/2/2006 8:52
To: #LI JIANGGAN#
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: boot failure on lite5200b board
Here is a uboot setup that works with a freescale kernel:
bootdelay=5
baudrate=115200
preboot=echo;echo Type "run flash_nfs" to mount root filesystem over NFS;echo
autoload=no
ethact=FEC ETHERNET
ramargs=setenv bootargs root=/dev/ram rw
jffs2args=setenv bootargs root=/dev/mtdblock0 rw rootfstype=jffs2
addip=setenv bootargs $(bootargs)
ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):$(netdev):off
panic=1
flash_nfs=run nfsargs addip;bootm $(kernel_addr)
flash_self=run ramargs addip;bootm $(kernel_addr) $(ramdisk_addr)
flash_jffs2=run jffs2args;bootm $(kernel_addr)
net_nfs=tftp 200000 $(bootfile);run nfsargs addip;bootm
netdev=eth0
ethaddr=00:04:9f:22:33:44
bootfile=/tftpboot/uImage
kernel_addr=ffd00000
rootpath=/tftpboot/ltib
filesize=c9d700
fileaddr=1000000
gatewayip=172.27.255.254
netmask=255.255.0.0
ipaddr=172.27.152.99
serverip=172.27.152.5
bootcmd=run net_nfs
nfsargs=setenv bootargs console=ttyS0,115200 root=/dev/nfs rw
nfsroot=$(serverip):$(rootpath)
stdin=serial
stdout=serial
stderr=serial
Change ip info, bootfile, rootpath etc to fit you config.
If you want it to work with Sylvain's kernel then you need to change
ttyS0 to ttyPSC0.
Also add a printenv just before the bootm so you can verify that your
bootargs really are getting set correctly.
On 3/1/06, #LI JIANGGAN# <lijianggan@pmail.ntu.edu.sg> wrote:
>
>
> how about the following U-boot settings:
>
> ..............................
>
>
> Hit any key to stop autoboot: 0
> => printenv
> baudrate=115200
> autoload=no
> ethact=FEC ETHERNET
> ethaddr=00:01:9F:00:27:2F
> preboot=echo; echo Autostarting. Press any key to abort..; echo
> bootdelay=5
> hostname=icecube
> bootfile=MPC5200/uImage
> nv=nfsroot root=/dev/nfs rw nfsroot=10.190.3.113:/opt/eldk/rootfs
> netmask=255.255.240.0
> ipaddr=10.190.3.144
> serverip=10.190.3.103
> bootcmd=run net_nfs
>
> rootfs=root=/dev/nfs rw
> netdev=eth0
> rootpath=/opt/eldk-4-0/rootfs
> nfsargs=setenv bootargs root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
>
> ramargs=setenv bootargs root=/dev/ram rw
> addip=setenv bootargs
> ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube:eth0:off
> panic=1
> net_nfs=tftp 200000 MPC5200/uImage;run nfsargs addip;bootm
>
> stdin=serial
> stdout=serial
> stderr=serial
>
> Environment size: 738/65532 bytes
> => .
> ................................
>
>
>
> The output is still the same, it hangs after displaying arch:exit
>
> I have also tried the above settings with console set, it gives the same
> output
>
> I am really wondering whether the problem is with the kernel. Sylvain's
> kernel uImage is only around 600k while the one from freescale is 1.4M,
> anybody knows where the difference is?
>
> .....................................
>
> Autostarting. Press any key to abort..
>
> Hit any key to stop autoboot: 0
> Using FEC ETHERNET device
> TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> Filename 'MPC5200/uImage'.
> Load address: 0x200000
>
> Loading:
> #################################################################
>
> #################################################################
>
> #################################################################
>
> #################################################################
> ###################################
> done
> Bytes transferred = 1510143 (170aff hex)
> ## Booting image at 00200000 ...
>
> Image Name: Linux-2.6.11.7
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1510079 Bytes = 1.4 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> ocp: exit
> arch: exit
>
>
>
>
>
> .....................
>
> Regards,
>
> Jianggan LI
>
> ________________________________
>
> From: John Rigby [mailto:jcrigby@gmail.com]
> Sent: Sat 2/25/2006 1:17
> To: #LI JIANGGAN#
> Cc: tnt@246tnt.com; linuxppc-embedded@ozlabs.org
>
> Subject: Re: boot failure on lite5200b board
>
>
>
>
> I don't think your syntax for appending to an env variable is correct:
>
> try:
> set bootargs $(bootargs) ...appended stuff...
> instead of:
> set bootargs env bootargs ...appended stuff....
>
> Also to see what bootargs is actually set to after all the nested
> commands, add a printenv just before the bootm
>
> On 2/23/06, #LI JIANGGAN# <lijianggan@pmail.ntu.edu.sg> wrote:
> >
> >
> > I have actually tried both kernel with both console configurations. It
> gave
> > the same output, thus I presume that the problem lies somewhere else. I
> > attached the log to this email.
> >
> > the board is Lite5200B Version 1.0. Which .config file do you want?
> >
> > Sylvain, we have ordered a debugging set but we are still waiting for
> > delivery, the leaking time is said to be one month, tant pis. And the log
> I
> > attached here are booting from a higher address (0x500000).
> >
> > My current u-boot args:
> > Autostarting. Press any key to abort..
> >
> > Hit any key to stop autoboot: 0
> > => printenv
> > baudrate=115200
> > autoload=no
> > ethact=FEC ETHERNET
> > flshroot=root=/dev/mtdblock2 rw
> > ethaddr=00:01:9F:00:27:2F
> > preboot=echo; echo Autostarting. Press any key to abort..; echo
> > bootdelay=5
> > hostname=icecube
> > bootfile=MPC5200/uImage
> > nv=nfsroot root=/dev/nfs rw nfsroot=10.190.3.113:/opt/eldk/rootfs
> > ip=ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> > nfsroot=root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > bootcmd=run net_nfs
> > filesize=546
> > fileaddr=500000
> > netmask=255.255.240.0
> > ipaddr=10.190.3.144
> > serverip=10.190.3.103
> > setconsole=setenv bootargs console=ttyPSC0, 115200n8 console=tty1
> > rootfs=root=/dev/nfs rw
> nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > bootargs=env bootargs root=/dev/nfs rw
> > nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> > flash_nfs=run setconsole nfsargs addip;bootm
> > net_nfs=tftp 500000 MPC5200/uImage;run setconsole nfsargs addip;bootm
> > nfsargs=setenv bootargs env bootargs root=/dev/nfs rw
> > nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> >
> ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::offroot=/dev/nfs
> > rw
> > addip=setenv bootargs env bootargs root=/dev/nfs rw
> > nfsroot=10.190.3.103:/opt/eldk-4-0/rootfs
> > ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> > ramargs=setenv bootargs root=/dev/ram rw
> > console=console=ttyS0,115200n8 console=tty1
> > stdin=serial
> > stdout=serial
> > stderr=serial
> >
> > Environment size: 1472/65532 bytes
> > =>
> >
> >
> >
> >
> > USING Sylvain's KERNEL:
> >
> > U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
> >
> > CPU: MPC5200 v2.2 at 462 MHz
> > Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> > Board: Freescale MPC5200 (Lite5200B)
> > I2C: 85 kHz, ready
> > DRAM: 256 MB
> > FLASH: 32 MB
> > PCI: Bus Dev VenId DevId Class Int
> > 00 1a 1057 5809 0680 00
> > In: serial
> > Out: serial
> > Err: serial
> > Net: FEC ETHERNET
> > IDE: Bus 0: OK
> > Device 0: not available
> > Device 1: not available
> >
> > Autostarting. Press any key to abort..
> >
> > Hit any key to stop autoboot: 0
> > Using FEC ETHERNET device
> > TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> > Filename 'MPC5200/uImage'.
> > Load address: 0x500000
> > Loading:
> #################################################################
> >
> ################################################################
> > done
> > Bytes transferred = 658114 (a0ac2 hex)
> > ## Booting image at 00500000 ...
> > Image Name: Linux-2.6.16-rc1
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 658050 Bytes = 642.6 kB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> > id mach(): done
> > MMU:enter
> > MMU:hw init
> > MMU:mapin
> > MMU:setio
> > MMU:exit
> > setup_arch: enter
> > setup_arch: bootmem
> > arch: exit
> >
> >
> >
> > USING KERNEL FROM Freescale:
> >
> > U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
> >
> > CPU: MPC5200 v2.2 at 462 MHz
> > Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> > Board: Freescale MPC5200 (Lite5200B)
> > I2C: 85 kHz, ready
> > DRAM: 256 MB
> > FLASH: 32 MB
> > PCI: Bus Dev VenId DevId Class Int
> > 00 1a 1057 5809 0680 00
> > In: serial
> > Out: serial
> > Err: serial
> > Net: FEC ETHERNET
> > IDE: Bus 0: OK
> > Device 0: not available
> > Device 1: not available
> >
> > Autostarting. Press any key to abort..
> >
> > Hit any key to stop autoboot: 0
> > Using FEC ETHERNET device
> > TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> > Filename 'MPC5200/uImage'.
> > Load address: 0x500000
> > Loading:
> #################################################################
> >
> #################################################################
> >
> #################################################################
> >
> #################################################################
> > ###################################
> > done
> > Bytes transferred = 1510143 (170aff hex)
> > ## Booting image at 00500000 ...
> > Image Name: Linux-2.6.11.7
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 1510079 Bytes = 1.4 MB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> > id mach(): done
> > MMU:enter
> > MMU:hw init
> > MMU:mapin
> > MMU:setio
> > MMU:exit
> > setup_arch: enter
> > setup_arch: bootmem
> > ocp: exit
> > arch: exit
> >
> >
> >
> >
> > -----Original Message-----
> > From: John Rigby [mailto:jcrigby@gmail.com]
> > Sent: Fri 2/24/2006 0:18
> > To: #LI JIANGGAN#
> > Subject: Re: boot failure on lite5200b board
> >
> > If you are using Sylvain's kernel you need to set console=ttyPSC0. If
> you
> > are
> > using a kernel from Freescale then you need to set console=ttyS0.
> >
> > Also what rev of the board do you have?
> >
> >
> >
> > On 2/23/06, #LI JIANGGAN# <lijianggan@pmail.ntu.edu.sg> wrote:
> > >
> > >
> > > Thank you Jos? Mar?a and Andrey for your advices, however the problem
>
> > > remains. I've tried setting the console (though I remember that our
> > previous
> > > lite5200 board was working fine on kernel 2.4 without setting the
> > console);
> > > meantime, I've set the booting image to 0x500000; I have also tried
> using
> > > the kernel image come together with the BSP, it's always the same
> error.
> > >
> > > Sylvain, I've actually using your kernel source, the compiled image is
> > > around 700k (compared to the 1.4M image from the BSP), but it doesn't
> > solve
> > > the problem. So I presume that the problem is lying somewhere else.
> > >
> > > A SNAPSHOT OF THE BOOTING MESSAGES:
> > >
> > >
> > > U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
> > >
> > > CPU: MPC5200 v2.2 at 462 MHz
> > > Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> > > Board: Freescale MPC5200 (Lite5200B)
> > > I2C: 85 kHz, ready
> > > DRAM: 256 MB
> > > FLASH: 32 MB
> > > PCI: Bus Dev VenId DevId Class Int
> > > 00 1a 1057 5809 0680 00
> > > In: serial
> > > Out: serial
> > > Err: serial
> > > Net: FEC ETHERNET
> > > IDE: Bus 0: OK
> > > Device 0: not available
> > > Device 1: not available
> > >
> > > Autostarting. Press any key to abort..
> > >
> > > Hit any key to stop autoboot: 0
> > > Using FEC ETHERNET device
> > > TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> > > Filename 'MPC5200/uImage'.
> > > Load address: 0x100000
> > > Loading:
> > >
> #################################################################
> > >
> > >
> ################################################################
> > > done
> > > Bytes transferred = 658114 (a0ac2 hex)
> > > ## Booting image at 00100000 ...
> > > Image Name: Linux-2.6.16-rc1
> > > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > > Data Size: 658050 Bytes = 642.6 kB
> > > Load Address: 00000000
> > > Entry Point: 00000000
> > > Verifying Checksum ... OK
> > > Uncompressing Kernel Image ... OK
> > > id mach(): done
> > > MMU:enter
> > > MMU:hw init
> > > MMU:mapin
> > > MMU:setio
> > > MMU:exit
> > > setup_arch: enter
> > > setup_arch: bootmem
> > > arch: exit
> > >
> > >
> > > I am wondering whether it's a kernel problem or more likely to be a
> > problem
> > > lying with the U-boot. It seems to hang when executing setup_arch()
> > > function, or maybe there is sth else behind the wall?
> > >
> > > Regards,
> > > Jianggan LI
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Sylvain Munaut [mailto:tnt@246tNt.com]
> > > Sent: Thu 2/23/2006 15:38
> > > To: #LI JIANGGAN#
> > > Cc: linuxppc-embedded@ozlabs.org
> > > Subject: Re: boot failure on lite5200b board
> > >
> > > #LI JIANGGAN# wrote:
> > > > Hello all,
> > > >
> > > > For my end-of-study project, I am working on an embedded system with
> > > > reference of freescale's lite5200b reference board. I was trying to
> > boot
> > > > Linux 2.6.15 on the board (with the fec and bestcomm corrected).
> > however
> > > > the booting was stuck at the following stage:
> > >
> > > In addition to what has already been said (use a higher address for
> the
> > > image and don't forget console=ttyPSC0 in kernel command line), make
> > > sure you use the kernel from my git tree, it contains a few patches
> from
> > > John Rigby to add support for the lite5200b.
> > >
> > > Please report if it works, I've not been able to test those myself
> since
> > > i'm still on lite5200.
> > >
> > >
> > > Sylvain
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
[-- Attachment #2: Type: text/html, Size: 32295 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix windfarm_pm112 not starting all control loops
From: Benjamin Herrenschmidt @ 2006-03-03 6:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Linux Kernel list
This adds a couple of printk's to windfarm_pm112 to display which
control loops are actually starting and fixes a bug where it would not
start all loops.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/drivers/macintosh/windfarm_pm112.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_pm112.c 2006-03-03 16:24:44.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_pm112.c 2006-03-03 17:04:53.000000000 +1100
@@ -358,6 +358,7 @@ static void backside_fan_tick(void)
return;
if (!backside_tick) {
/* first time; initialize things */
+ printk(KERN_INFO "windfarm: Backside control loop started.\n");
backside_param.min = backside_fan->ops->get_min(backside_fan);
backside_param.max = backside_fan->ops->get_max(backside_fan);
wf_pid_init(&backside_pid, &backside_param);
@@ -407,6 +408,7 @@ static void drive_bay_fan_tick(void)
return;
if (!drive_bay_tick) {
/* first time; initialize things */
+ printk(KERN_INFO "windfarm: Drive bay control loop started.\n");
drive_bay_prm.min = drive_bay_fan->ops->get_min(drive_bay_fan);
drive_bay_prm.max = drive_bay_fan->ops->get_max(drive_bay_fan);
wf_pid_init(&drive_bay_pid, &drive_bay_prm);
@@ -458,6 +460,7 @@ static void slots_fan_tick(void)
return;
if (!slots_started) {
/* first time; initialize things */
+ printk(KERN_INFO "windfarm: Slots control loop started.\n");
wf_pid_init(&slots_pid, &slots_param);
slots_started = 1;
}
@@ -504,6 +507,7 @@ static void pm112_tick(void)
if (!started) {
started = 1;
+ printk(KERN_INFO "windfarm: CPUs control loops started.\n");
for (i = 0; i < nr_cores; ++i) {
if (create_cpu_loop(i) < 0) {
failure_state = FAILURE_PERM;
@@ -594,8 +598,6 @@ static void pm112_new_sensor(struct wf_s
{
unsigned int i;
- if (have_all_sensors)
- return;
if (!strncmp(sr->name, "cpu-temp-", 9)) {
i = sr->name[9] - '0';
if (sr->name[10] == 0 && i < NR_CORES &&
^ permalink raw reply
* [PATCH] powerpc: Fix old g5 issues with windfarm
From: Benjamin Herrenschmidt @ 2006-03-03 6:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Linux Kernel list
Some of the windfarm sensor modules can initialize on old machines that
don't have full windfarm support like non-dual core desktop G5s.
Unfortunately, by doing so, they would trigger a bug in their matching
algorithm causing them to attach to the wrong bus, thus triggering
issues with the i2c core and breaking the thermal driver.
This patch fixes the probing issue (so that they will work when a
windfarm port is done to these machines) and also prevents for now
windfarm to load at all on these machines that still use therm_pm72 to
avoid wasting resources.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/drivers/macintosh/windfarm_lm75_sensor.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_lm75_sensor.c 2006-03-03 16:02:56.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_lm75_sensor.c 2006-03-03 16:41:01.000000000 +1100
@@ -25,9 +25,9 @@
#include "windfarm.h"
-#define VERSION "0.1"
+#define VERSION "0.2"
-#define DEBUG
+#undef DEBUG
#ifdef DEBUG
#define DBG(args...) printk(args)
@@ -113,6 +113,7 @@ static struct wf_lm75_sensor *wf_lm75_cr
const char *loc)
{
struct wf_lm75_sensor *lm;
+ int rc;
DBG("wf_lm75: creating %s device at address 0x%02x\n",
ds1775 ? "ds1775" : "lm75", addr);
@@ -139,9 +140,11 @@ static struct wf_lm75_sensor *wf_lm75_cr
lm->i2c.driver = &wf_lm75_driver;
strncpy(lm->i2c.name, lm->sens.name, I2C_NAME_SIZE-1);
- if (i2c_attach_client(&lm->i2c)) {
- printk(KERN_ERR "windfarm: failed to attach %s %s to i2c\n",
- ds1775 ? "ds1775" : "lm75", lm->i2c.name);
+ rc = i2c_attach_client(&lm->i2c);
+ if (rc) {
+ printk(KERN_ERR "windfarm: failed to attach %s %s to i2c,"
+ " err %d\n", ds1775 ? "ds1775" : "lm75",
+ lm->i2c.name, rc);
goto fail;
}
@@ -175,16 +178,22 @@ static int wf_lm75_attach(struct i2c_ada
(dev = of_get_next_child(busnode, dev)) != NULL;) {
const char *loc =
get_property(dev, "hwsensor-location", NULL);
- u32 *reg = (u32 *)get_property(dev, "reg", NULL);
- DBG(" dev: %s... (loc: %p, reg: %p)\n", dev->name, loc, reg);
- if (loc == NULL || reg == NULL)
+ u8 addr;
+
+ /* We must re-match the adapter in order to properly check
+ * the channel on multibus setups
+ */
+ if (!pmac_i2c_match_adapter(dev, adapter))
+ continue;
+ addr = pmac_i2c_get_dev_addr(dev);
+ if (loc == NULL || addr == 0)
continue;
/* real lm75 */
if (device_is_compatible(dev, "lm75"))
- wf_lm75_create(adapter, *reg, 0, loc);
+ wf_lm75_create(adapter, addr, 0, loc);
/* ds1775 (compatible, better resolution */
else if (device_is_compatible(dev, "ds1775"))
- wf_lm75_create(adapter, *reg, 1, loc);
+ wf_lm75_create(adapter, addr, 1, loc);
}
return 0;
}
@@ -206,6 +215,11 @@ static int wf_lm75_detach(struct i2c_cli
static int __init wf_lm75_sensor_init(void)
{
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
return i2c_add_driver(&wf_lm75_driver);
}
Index: linux-work/drivers/macintosh/windfarm_max6690_sensor.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_max6690_sensor.c 2006-02-17 14:38:40.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_max6690_sensor.c 2006-03-03 16:40:05.000000000 +1100
@@ -17,7 +17,7 @@
#include "windfarm.h"
-#define VERSION "0.1"
+#define VERSION "0.2"
/* This currently only exports the external temperature sensor,
since that's all the control loops need. */
@@ -81,7 +81,7 @@ static struct wf_sensor_ops wf_max6690_o
static void wf_max6690_create(struct i2c_adapter *adapter, u8 addr)
{
struct wf_6690_sensor *max;
- char *name = "u4-temp";
+ char *name = "backside-temp";
max = kzalloc(sizeof(struct wf_6690_sensor), GFP_KERNEL);
if (max == NULL) {
@@ -118,7 +118,6 @@ static int wf_max6690_attach(struct i2c_
struct device_node *busnode, *dev = NULL;
struct pmac_i2c_bus *bus;
const char *loc;
- u32 *reg;
bus = pmac_i2c_adapter_to_bus(adapter);
if (bus == NULL)
@@ -126,16 +125,23 @@ static int wf_max6690_attach(struct i2c_
busnode = pmac_i2c_get_bus_node(bus);
while ((dev = of_get_next_child(busnode, dev)) != NULL) {
+ u8 addr;
+
+ /* We must re-match the adapter in order to properly check
+ * the channel on multibus setups
+ */
+ if (!pmac_i2c_match_adapter(dev, adapter))
+ continue;
if (!device_is_compatible(dev, "max6690"))
continue;
+ addr = pmac_i2c_get_dev_addr(dev);
loc = get_property(dev, "hwsensor-location", NULL);
- reg = (u32 *) get_property(dev, "reg", NULL);
- if (!loc || !reg)
+ if (loc == NULL || addr == 0)
continue;
- printk("found max6690, loc=%s reg=%x\n", loc, *reg);
+ printk("found max6690, loc=%s addr=0x%02x\n", loc, addr);
if (strcmp(loc, "BACKSIDE"))
continue;
- wf_max6690_create(adapter, *reg);
+ wf_max6690_create(adapter, addr);
}
return 0;
@@ -153,6 +159,11 @@ static int wf_max6690_detach(struct i2c_
static int __init wf_max6690_sensor_init(void)
{
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
return i2c_add_driver(&wf_max6690_driver);
}
Index: linux-work/drivers/macintosh/windfarm_pm112.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_pm112.c 2006-02-17 14:38:40.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_pm112.c 2006-03-03 16:24:44.000000000 +1100
@@ -613,7 +613,7 @@ static void pm112_new_sensor(struct wf_s
} else if (!strcmp(sr->name, "slots-power")) {
if (slots_power == NULL && wf_get_sensor(sr) == 0)
slots_power = sr;
- } else if (!strcmp(sr->name, "u4-temp")) {
+ } else if (!strcmp(sr->name, "backside-temp")) {
if (u4_temp == NULL && wf_get_sensor(sr) == 0)
u4_temp = sr;
} else
Index: linux-work/drivers/macintosh/windfarm_cpufreq_clamp.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_cpufreq_clamp.c 2005-11-09 11:49:03.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_cpufreq_clamp.c 2006-03-03 16:42:36.000000000 +1100
@@ -8,6 +8,8 @@
#include <linux/wait.h>
#include <linux/cpufreq.h>
+#include <asm/prom.h>
+
#include "windfarm.h"
#define VERSION "0.3"
@@ -74,6 +76,12 @@ static int __init wf_cpufreq_clamp_init(
{
struct wf_control *clamp;
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
+
clamp = kmalloc(sizeof(struct wf_control), GFP_KERNEL);
if (clamp == NULL)
return -ENOMEM;
Index: linux-work/drivers/macintosh/windfarm_core.c
===================================================================
--- linux-work.orig/drivers/macintosh/windfarm_core.c 2006-02-17 14:38:40.000000000 +1100
+++ linux-work/drivers/macintosh/windfarm_core.c 2006-03-03 16:43:06.000000000 +1100
@@ -35,6 +35,8 @@
#include <linux/platform_device.h>
#include <linux/mutex.h>
+#include <asm/prom.h>
+
#include "windfarm.h"
#define VERSION "0.2"
@@ -465,6 +467,11 @@ static int __init windfarm_core_init(voi
{
DBG("wf: core loaded\n");
+ /* Don't register on old machines that use therm_pm72 for now */
+ if (machine_is_compatible("PowerMac7,2") ||
+ machine_is_compatible("PowerMac7,3") ||
+ machine_is_compatible("RackMac3,1"))
+ return -ENODEV;
platform_device_register(&wf_platform_device);
return 0;
}
^ permalink raw reply
* Re: Linux on PPC
From: David Hawkins @ 2006-03-03 5:10 UTC (permalink / raw)
To: rtos; +Cc: linuxppc-embedded
In-Reply-To: <190edfbd0603021801g5505cab9h8e285fdc7bf476d1@mail.gmail.com>
Hiya,
I'm no expert in this, but here's the basics;
> We have a customized board running on IBM PPC 750. The customer boot
> loader is provided by the vendor. Also, the vendor has provided
> the BSP on vxworks.
The PPC 750 is a fairly old processor, so there will be Linux
support for it. For example, I picked up a couple of Artesyn
PrPMC boards that contain a PPC 750, and this board can run
Linux, though I have not had time to try booting it yet.
If the vendor provided the VxWorks BSP, then hopefully they
also provided you with the physical memory map of the board.
This is what you really need to get another bootloader (eg. U-Boot)
and Linux up-and-running. If the vendor will provide schematics
for the board, that would also help (hey, it never hurts to
ask for them).
> We are planning to use linux on this processor. What are the steps
> involved in booting the board with linux.
> Which linux to be used and what are the procedures involved. I dint come
> across a documents which had these details.
>
> I am new to the linux front. So any help is highly appreciated.
>
Step 1. Get the memory map of the board.
Step 2. Find a PPC 750 port in the Linux source.
For example, in the 2.6 series kernel, the place to start
looking is under arch/ppc/platforms. grep -Ie 750 shows
up some of the PPC 750 based systems.
chestnut.c 750FX/GX evaluation board
katana.c Looks like one too
prpmc750.c Looks like a Motorola board
Look at the comments in the code, look at the memory map
of the reference board versus your custom board. There is
a very good chance that the custom board is based on a
reference design - thats the whole point of them.
Step 3. Build a minimal kernel
Step 4. Boot
Step 5. Purchase a BDI2000 JTAG debugger and use it to figure
out why Step 4 didn't work.
Repeat at Step 3.
When I get time to play with my Artesyn board, I'll go back to
the katana.c file, the grep above had some comments about Artesyn
boards. If it fails to boot, I'll use the BDI2000 to see where it
dies and go from there.
Once you can boot Linux, you might decide that the custom bootloader
on the board is inflexible. The U-Boot bootloader is very nice
and will have support for other 750-based boards, it shouldn't
take too much to port that too. But first, try to get a Linux
kernel booted, even if it has a hard-wired command line.
Also take a look over on the Freescale web site, search for
'porting linux', it'll show up AN2145, AN2222, AN2579, and
a bunch of other application notes. They'll give you an idea
of what it takes to port to a new processor.
> I am new to the linux front. So any help is highly appreciated.
So it depends how much time you have versus how much you
want to spend.
There are also commercial companies that will do the job for you.
If you can come up with the memory map and hardware details of
the board, you could always post a request on this list, and
I am sure there are people reading this list that would
respond. (I'm not one of them though, so I'm not trying to
drum up business ok)
Regards,
Dave
^ permalink raw reply
* Re: Linux on PPC
From: nreddy @ 2006-03-03 5:09 UTC (permalink / raw)
To: rtos; +Cc: linuxppc-embedded
In-Reply-To: <190edfbd0603021801g5505cab9h8e285fdc7bf476d1@mail.gmail.com>
You can easily migrate to linux environment.
1. You can use u-boot as a boot loader.
2. You can choose any standard linux kernel but you may have to do some
R&D on it to port to your board.
Insted you can buy Montavista Linux, so that you can get support also.
And also there are many mailing lists where yo ucan get tremendous help
on linux.
Thanks,
Nagi
> Hi,
>
> We have a customized board running on IBM PPC 750. The customer boot
> loader
> is provided by the vendor.
> Also, the vendor has provided the BSP on vxworks.
>
> We are planning to use linux on this processor. What are the steps
> involved
> in booting the board with linux.
> Which linux to be used and what are the procedures involved. I dint come
> across a documents which had these details.
>
> I am new to the linux front. So any help is highly appreciated.
>
> thanks
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Unsafe pte_update() in do_page_fault() (4xx and Book-E)
From: Eugene Surovegin @ 2006-03-03 3:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Kumar Gala
In-Reply-To: <1141357383.3888.19.camel@localhost.localdomain>
On Fri, Mar 03, 2006 at 02:43:02PM +1100, Benjamin Herrenschmidt wrote:
>
> > If this happens, pte_update() sets _PAGE_HWEXEC bit in just cleared
> > PTE. Sometime later, another page fault happens for this page, but
> > because of that set bit, pte_none() test in handle_pte_fault() fails,
> > and we continue along the wrong path, thinking that this PTE was
> > swapped out to the swap file, and this triggers swap_dup error I
> > mentioned at the beginning.
>
> Can we preempt at that point ? As tehre is no SMP 4xx that I know of
> preempt would be the only cause for such a race ...
Yes, as I mentioned in the original post, I'm running preempt enabled
kernel.
--
Eugene
^ permalink raw reply
* Re: Unsafe pte_update() in do_page_fault() (4xx and Book-E)
From: Benjamin Herrenschmidt @ 2006-03-03 3:43 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, Kumar Gala
In-Reply-To: <20060302202634.GA14387@gate.ebshome.net>
> If this happens, pte_update() sets _PAGE_HWEXEC bit in just cleared
> PTE. Sometime later, another page fault happens for this page, but
> because of that set bit, pte_none() test in handle_pte_fault() fails,
> and we continue along the wrong path, thinking that this PTE was
> swapped out to the swap file, and this triggers swap_dup error I
> mentioned at the beginning.
Can we preempt at that point ? As tehre is no SMP 4xx that I know of
preempt would be the only cause for such a race ...
Ben.
^ permalink raw reply
* Re: Linux on PPC
From: Frank @ 2006-03-03 2:23 UTC (permalink / raw)
To: rtos, linuxppc-embedded
In-Reply-To: <190edfbd0603021801g5505cab9h8e285fdc7bf476d1@mail.gmail.com>
--- rtosrtososrtosgmaigmail> wrote:
> Hi,
>
> We have a customized board running on IBM PPC PPC. The
> customer boot loader
> is provided by the vendor.
> Also, the vendor has provided the BSP BSPvxwovxworks
> We are planning to use linulinuxthis processor. What are the
> steps involved
> in booting the board with linulinux Which linulinuxbe used and
what are the procedures involved. I
> dint come
> across a documents which had these details.
>
> I am new to the linulinuxnt. So any help is highly
> appreciated.
>
> thanks
I recommend using u-boot and the ELDK from denx.de
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ 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