* [PATCH] invalid instructions in kernel mode
From: Fillod Stephane @ 2005-03-31 17:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
Hi,
When CPU has no (classic) FPU, and math emulation is disabled,
fp instructions are not allowed in kernel mode.
This bug has been found with crashme (crash01) of LTP, on a e500 system.
The patch was made against linux 2.6.11.6.
A trivial typo fix has been appended.
Rem: a CONFIG_PPCFPU define could make life easier.
Signed-off-by: Stephane Fillod <fillods@gmail.com>
--- linux/arch/ppc/kernel/align.c 6 Dec 2004 16:18:11 -0000
1.1.1.1
+++ linux/arch/ppc/kernel/align.c 31 Mar 2005 16:33:25 -0000
@@ -333,10 +333,14 @@
}
=20
if (flags & F) {
+#if !(defined(CONFIG_4xx) || defined(CONFIG_8xx) ||
defined(CONFIG_E500)) || defined(CONFIG_MATH_EMULATION)
preempt_disable();
if (regs->msr & MSR_FP)
giveup_fpu(current);
preempt_enable();
+#else
+ return 0;
+#endif
}
=20
/* If we read the operand, copy it in, else get register values
*/
@@ -366,6 +370,8 @@
}
break;
=20
+#if !(defined(CONFIG_4xx) || defined(CONFIG_8xx) ||
defined(CONFIG_E500)) || defined(CONFIG_MATH_EMULATION)
+
/* Single-precision FP load and store require conversions... */
case LD+F+S:
preempt_disable();
@@ -379,6 +385,7 @@
cvt_df(&data.d, &data.f, ¤t->thread.fpscr);
preempt_enable();
break;
+#endif
}
=20
if (flags & ST) {
--- linux/arch/ppc/kernel/misc.S 26 Mar 2005 03:28:36 -0000
1.1.1.2
+++ linux/arch/ppc/kernel/misc.S 31 Mar 2005 16:33:25 -0000
@@ -1096,7 +1096,8 @@
* and exceptions as if the cpu had performed the load or store.
*/
=20
-#if defined(CONFIG_4xx) || defined(CONFIG_E500)
+#if !(defined(CONFIG_4xx) || defined(CONFIG_E500) ||
defined(CONFIG_8xx)) || defined(CONFIG_MATH_EMULATION)
+#if defined(CONFIG_4xx) || defined(CONFIG_E500)
_GLOBAL(cvt_fd)
lfs 0,0(r3)
stfd 0,0(r4)
@@ -1125,6 +1126,7 @@
stfd 0,-4(r5)
blr
#endif
+#endif
=20
/*
* Create a kernel thread
--- linux/arch/ppc/kernel/process.c 26 Mar 2005 03:28:20 -0000
1.1.1.2
+++ linux/arch/ppc/kernel/process.c 31 Mar 2005 16:33:25 -0000
@@ -342,7 +342,7 @@
printk("\n");
#ifdef CONFIG_KALLSYMS
/*
- * Lookup NIP late so we have the best change of getting the
+ * Lookup NIP late so we have the best chance of getting the
* above info out without failing
*/
printk("NIP [%08lx] ", regs->nip);
Best Regards,
--=20
Stephane
^ permalink raw reply
* RE: Linux crashes during memory mapping
From: Atit_Shah @ 2005-03-31 16:36 UTC (permalink / raw)
To: Steven Blakeslee, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 8985 bytes --]
1. SYPCR is DISABLED for our board
2. What do you mean when you say "RAM is correctly mapped" are you talking
about the functioning of RAM or if there is an overlapping between various
regions or some thing else?
The power on self test of RAM through u-boot and RAM test through Code
Warrior have been successful.
3. Sorry I sent in the wrong log_buffer contents, the bd_info is been passed
correctly from u-boot to linux. Below is the log_buffer which says "Oops
Kernel Access of Bad Area"
00177e34: 3c363e4d 656d6f72 79204241 54206d61 <6>Memory BAT ma
00177e44: 7070696e 673a2042 7070696e 673a2042 pping: Bpping: B
00177e54: 622c2042 4154333d 33324d62 2c207265 b, BAT3=32Mb, re
00177e64: 73696475 616c3a20 304d620a 3c343e4f sidual: 0Mb.<4>O
00177e74: 6f70733a 206b6572 6e656c20 61636365 ops: kernel acce
00177e84: 7373206f 66206261 64206172 65612c20 ss of bad area,
00177e94: 7369673a 2031310a 3c343e4e 49503a20 sig: 11.<4>NIP:
00177ea4: 30303030 30303030 20584552 3a203030 00000000 XER: 00
00177eb4: 30303030 3030204c 523a2030 30303030 000000 LR: 00000
00177ec4: 30303020 53503a20 30303030 30303030 000 SP: 00000000
00177ed4: 20524547 533a2063 30313530 30303020 REGS: c0150000
00177ee4: 54524150 3a203030 30302020 20204e6f TRAP: 0000 No
00177ef4: 74207461 696e7465 640a3c34 3e4d5352 t tainted.<4>MSR
00177f04: 3a203030 30303030 30302045 453a2030 : 00000000 EE: 0
00177f14: 2050523a 20302046 503a2030 204d453a PR: 0 FP: 0 ME:
00177f24: 20302049 522f4452 3a203030 0a3c343e 0 IR/DR: 00.<4>
00177f34: 5441534b 203d2063 30313466 3437305b TASK = c014f470[
00177f44: 305d2027 73776170 70657227 204c6173 0] 'swapper' Las
00177f54: 74207379 7363616c 6c3a2030 200a3c34 t syscall: 0 .<4
00177f64: 3e6c6173 74206d61 74682030 30303030 >last math 00000
00177f74: 30303020 6c617374 20616c74 69766563 000 last altivec
00177f84: 20303030 30303030 300a3c34 3e43616c 00000000.<4>Cal
00177f94: 6c206261 636b7472 6163653a 20303030 l backtrace: 000
00177fa4: 30303030 34200a3c 343e4f6f 70733a20 00004 .<4>Oops:
00177fb4: 6b65726e 656c2061 63636573 73206f66 kernel access of
00177fc4: 20626164 20617265 612c2073 69673a20 bad area, sig:
00177fd4: 31310a3c 343e4e49 503a2030 30303030 11.<4>NIP: 00000
00177fe4: 30303020 5845523a 20303030 30303030 000 XER: 0000000
00177ff4: 30204c52 3a203030 30303030 30302053 0 LR: 00000000 S
00178004: 503a2030 30303030 30303020 52454753 P: 00000000 REGS
00178014: 3a206330 31353030 30302054 5241503a : c0150000 TRAP:
00178024: 20303030 30202020 204e6f74 20746169 0000 Not tai
00178034: 6e746564 0a3c343e 4d53523a 20303030 nted.<4>MSR: 000
00178044: 30303030 30204545 3a203020 50523a20 00000 EE: 0 PR:
00178054: 30204650 3a203020 4d453a20 30204952 0 FP: 0 ME: 0 IR
00178064: 2f44523a 2030300a 3c343e54 41534b20 /DR: 00.<4>TASK
00178074: 3d206330 31346634 37305b30 5d202773 = c014f470[0] 's
00178084: 77617070 65722720 4c617374 20737973 wapper' Last sys
00178094: 63616c6c 3a203020 0a3c343e 6c617374 call: 0 .<4>last
001780a4: 206d6174 68203030 30303030 3030206c math 00000000 l
001780b4: 61737420 616c7469 76656320 30303030 ast altivec 0000
001780c4: 30303030 0a3c343e 43616c6c 20626163 0000.<4>Call bac
001780d4: 6b747261 63653a20 30303030 30303034 ktrace: 00000004
001780e4: 200a3c34 3e4f6f70 733a206b 65726e65 .<4>Oops: kerne
001780f4: 6c206163 63657373 206f6620 62616420 l access of bad
00178104: 61726561 2c207369 673a2031 310a3c34 area, sig: 11.<4
00178114: 3e4e4950 3a203030 30303030 30312058 >NIP: 00000001 X
00178124: 45523a20 30303030 30303030 204c523a ER: 00000000 LR:
00178134: 20433031 35303044 30205350 3a203030 C01500D0 SP: 00
00178144: 30303030 30302052 4547533a 20633031 000000 REGS: c01
00178154: 35303030 30205452 41503a20 31303332 50000 TRAP: 1032
00178164: 20202020 4e6f7420 7461696e 7465640a Not tainted.
00178174: 3c343e4d 53523a20 66666666 66666666 <4>MSR: ffffffff
00178184: 2045453a 20312050 523a2031 2046503a EE: 1 PR: 1 FP:
00178194: 2031204d 453a2031 2049522f 44523a20 1 ME: 1 IR/DR:
001781a4: 31310a3c 343e5441 534b203d 20633031 11.<4>TASK = c01
001781b4: 34663437 305b305d 20277377 61707065 4f470[0] 'swappe
001781c4: 7227204c 61737420 73797363 616c6c3a r' Last syscall:
001781d4: 2030200a 3c343e6c 61737420 6d617468 0 .<4>last math
001781e4: 20303030 30303030 30206c61 73742061 00000000 last a
001781f4: 6c746976 65632030 30303030 3030300a ltivec 00000000.
00178204: 3c343eff ffffffc0 1502c0c0 15024361 <4>...........Ca
00178214: 6c6c2062 61636b74 72616365 3a203030 ll backtrace: 00
00178224: 30303030 3034200a 3c343e4f 6f70733a 000004 .<4>Oops:
00178234: 206b6572 6e656c20 61636365 7373206f kernel access o
00178244: 66206261 64206172 65612c20 7369673a f bad area, sig:
00178254: 2031310a 3c343e4e 49503a20 30303030 11.<4>NIP: 0000
00178264: 30303031 20584552 3a203030 30303030 0001 XER: 000000
00178274: 3030204c 523a2043 30313530 30443020 00 LR: C01500D0
00178284: 53503a20 46464646 46434330 20524547 SP: FFFFFCC0 REG
00178294: 533a2063 30313530 30303020 54524150 S: c0150000 TRAP
001782a4: 3a203130 33322020 20204e6f 74207461 : 1032 Not ta
001782b4: 696e7465 640a3c34 3e4d5352 3a206666 inted.<4>MSR: ff
001782c4: 66666666 66662045 453a2031 2050523a ffffff EE: 1 PR:
001782d4: 20312046 503a2031 204d453a 20312049 1 FP: 1 ME: 1 I
001782e4: 522f4452 3a203131 0a3c343e 5441534b R/DR: 11.<4>TASK
001782f4: 203d2063 30313466 3437305b 305d2027 = c014f470[0] '
00178304: 73772720 4c617374 20737973 63616c6c sw' Last syscall
00178314: 3a202d31 30373337 31383034 30200a3c : -1073718040 .<
00178324: 343e6c61 7374206d 61746820 30303030 4>last math 0000
00178334: 30303030 206c6173 7420616c 74697665 0000 last altive
00178344: 63203030 30303030 30300a3c 343effff c 00000000.<4>..
00178354: ffffc015 02c0c015 02000000 00000000 ................
4. Below is our register values:
HRCW 0x0c42020a
IMMR 0xF0000000
SYPCR 0xffff0681
SCCR 0x00000001
RMR 0x00000000
BCR 0x00100000
HID0 0x0000cc88 /*Initial*/
HID0 0x80000008 /*Final*/
# Flash - CS0 ----------------
BR0 0xFe001801
OR0 0xFe000880
# SDRAM - CS1 ----------------
OR1 0xFE002EC0
BR1 0x00000041
PSRT 0x27
MPTPR 0x2500
# cbr refresh
PSDMR 0xC24A24A2
SIUMCR 0x01230200
MSR 0x0000B942
Awaiting prompt reply,
Atit
-----Original Message-----
From: Steven Blakeslee [mailto:BlakesleeS@embeddedplanet.com]
Sent: Thursday, March 31, 2005 6:23 PM
To: Atit_Shah; linuxppc-embedded@ozlabs.org
Subject: RE: Linux crashes during memory mapping
> I do not have any problem with the functioning of U-Boot but
Linux crashes after
> printing "Uncompressing Kernel ... OK" and then it seems that nothing
is happening.
Do you have the SYPCR(serial watch dog timer) disabled?
> 3. The memory map of the VPN Board (MY BOARD) is as folllows:
>
=====================================================================
> Memory Region Size
Address Range
>
======================================================================
> SDRAM 32MByte 0000_0000
-- 01FF_FFFF
> Flash 32MByte FF00_0000
-- FFFF_FFFF
Have you done a full test to make sure your RAM is correctly mapped?
> This is what the console log buffer has shown:
>
=================================================================
> md 0x00177e34
>
> 00177e34: 3c363e6d 73746172 743d303c 363e6d73
<6>mstart=0<6>ms
> 00177e44: 697a653d 303c363e 66737461 72743d30
ize=0<6>fstart=0
> 00177e54: 3c363e66 73697a65 3d303c36 3e696d6d
<6>fsize=0<6>imm
> 00177e64: 723d303c 363e626f 74666c61 673d303c
r=0<6>botflag=0<
> 00177e74: 363e6970 6164643d 303c363e 65616464
6>ipadd=0<6>eadd
> 00177e84: 3d633031 35303032 383c363e 65737065
=c0150028<6>espe
> 00177e94: 643d303c 363e696e 6974663d 303c363e
d=0<6>initf=0<6>
> 00177ea4: 62757366 3d303c36 3e63706d 663d303c
busf=0<6>cpmf=0<
> 00177eb4: 363e6272 67663d30 3c363e73 6363663d
6>brgf=0<6>sccf=
> 00177ec4: 303c363e 76636f3d 303c363e 62617564
0<6>vco=0<6>baud
> 00177ed4: 3d304f6f 70733a20 6b65726e 656c2061 =0Oops: kernel
a
These values do not look correct. Everything is zero.
**************************************************************************
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.
**************************************************************************
[-- Attachment #2: Type: text/html, Size: 18281 bytes --]
^ permalink raw reply
* Re: 440EP FPU patch
From: Tom Rini @ 2005-03-31 16:34 UTC (permalink / raw)
To: Wade Farnsworth; +Cc: linuxppc-embedded Linux list
In-Reply-To: <1112286378.24673.252.camel@rhino.az.mvista.com>
On Thu, Mar 31, 2005 at 09:26:18AM -0700, Wade Farnsworth wrote:
> On Fri, 2005-03-18 at 12:30, Tom Rini wrote:
> > On Fri, Mar 18, 2005 at 01:43:11PM -0500, Jason McMullan wrote:
> > > On Fri, 2005-03-18 at 10:06 -0600, Kumar Gala wrote:
> > > > Can you build your patch for the lopec_defconfig and fix the errors
> > > > associated with enabling altivec.
> > > >
> > > > Looks like you need to include asm/offset.h & asm/page.h in vector.S,
> > > > however there is another build error after that.
> > >
> > > Thanks! That also found a linking bug, fixed in this patch.. Please
> > > double check the call in 'AltiVecUnavalible' in head.S, and the re-load
> > > of 'ctr' at the end of load_up_altivec, as I do not have an AltiVec
> > > machine here.
> >
> > No dice:
> > VFS: Mounted root (nfs filesystem) readonly.
> > Freeing unused kernel memory: 100k init 4k prep
> > floating point used in kernel (task=c03816b0, pc=c000d664)
> > Doing some objdump'ing, that's the start of load_up_altivec.
>
> Hi Jason and Tom,
>
> Has there been any more progress on this patch?
Sadly no. We got to the point where it was reliably crashing on my
LoPEC (7400), but no time to try and fix it. The problem should show up
on any classic PPC box..
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: Overcommit (OOM) problem on embedded device (PPChameleon)
From: David Adair @ 2005-03-31 16:15 UTC (permalink / raw)
To: 'Martin Egholm Nielsen', linuxppc-embedded
In-Reply-To: <424BB36B.1000900@egholm-nielsen.dk>
> > Look in mm/mmap.c and search for overcommit_memory, then do same
> > in the sources for your redhat kernels.
> I'll look into RH kernel to see if it isn't like you say :-)
>
> > Perhaps there's a patch for it floating around somewhere? ;-)
> Now, that would be really nice.
> Though I have no idea of where to look!?
>
Here is what I do. Patch is against BK linuxppc-2.4 version 1.1285
(2.4.28-pre3) but might work.
Burns 5% of the RAM but alternatives all seem worse and I never
have much luck trying to convince my colleagues that
dynamic allocation has no place in an embedded system.
If you find out why RH works it would be interesting ... perhaps
there is a better way.
David
#
# mm/mmap.c
# Add pessimistic overcommit mode similar to 2.6 mode 2.
# This allows malloc aka sbrk() to actually fail before
# process is killed.
# Overloaded sysctl_overcommit_memory to be both enable
# and ratio to avoid making a new sysctl.
#
diff -Nru a/mm/mmap.c b/mm/mmap.c
--- a/mm/mmap.c 2005-03-30 07:15:13 -08:00
+++ b/mm/mmap.c 2005-03-30 07:15:13 -08:00
@@ -45,9 +45,13 @@
__S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111
};
-int sysctl_overcommit_memory;
+int sysctl_overcommit_memory = 98;
+
int max_map_count = DEFAULT_MAX_MAP_COUNT;
+extern unsigned long totalram_pages;
+extern unsigned long totalhigh_pages;
+
/* Check that a process has enough memory to allocate a
* new virtual mapping.
*/
@@ -66,7 +70,7 @@
unsigned long free;
/* Sometimes we want to use more memory than we have. */
- if (sysctl_overcommit_memory)
+ if (sysctl_overcommit_memory == 1)
return 1;
/* The page cache contains buffer pages these days.. */
@@ -91,7 +95,20 @@
free += (dentry_stat.nr_unused * sizeof(struct dentry)) >>
PAGE_SHIFT;
free += (inodes_stat.nr_unused * sizeof(struct inode)) >>
PAGE_SHIFT;
+ /*
+ * Leave the last 3% for root
+ */
+ if (current->euid)
+ free -= free / 32;
+
+ /* Strict mode do not allocate last bit of memory */
+ if (sysctl_overcommit_memory) {
+ pages += (totalram_pages - totalhigh_pages)
+ * (100 - sysctl_overcommit_memory) / 100;
+ }
+
return free > pages;
+
}
/* Remove one vm structure from the inode's i_mapping address space. */
^ permalink raw reply
* Re: 440EP FPU patch
From: Wade Farnsworth @ 2005-03-31 16:26 UTC (permalink / raw)
To: Jason McMullan, Tom Rini; +Cc: linuxppc-embedded Linux list
In-Reply-To: <20050318193045.GM8345@smtp.west.cox.net>
On Fri, 2005-03-18 at 12:30, Tom Rini wrote:
> On Fri, Mar 18, 2005 at 01:43:11PM -0500, Jason McMullan wrote:
> > On Fri, 2005-03-18 at 10:06 -0600, Kumar Gala wrote:
> > > Can you build your patch for the lopec_defconfig and fix the errors
> > > associated with enabling altivec.
> > >
> > > Looks like you need to include asm/offset.h & asm/page.h in vector.S,
> > > however there is another build error after that.
> >
> > Thanks! That also found a linking bug, fixed in this patch.. Please
> > double check the call in 'AltiVecUnavalible' in head.S, and the re-load
> > of 'ctr' at the end of load_up_altivec, as I do not have an AltiVec
> > machine here.
>
> No dice:
> VFS: Mounted root (nfs filesystem) readonly.
> Freeing unused kernel memory: 100k init 4k prep
> floating point used in kernel (task=c03816b0, pc=c000d664)
> Doing some objdump'ing, that's the start of load_up_altivec.
Hi Jason and Tom,
Has there been any more progress on this patch?
Thanks,
Wade Farnsworth
^ permalink raw reply
* Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]
From: Jon Loeliger @ 2005-03-31 15:55 UTC (permalink / raw)
To: Jon Masters
Cc: Linux PPC Embedded list, Sylvain Munaut, Andrei Konovalov,
Jakob Viketoft
In-Reply-To: <424BEDFC.8080300@jonmasters.org>
On Thu, 2005-03-31 at 06:33, Jon Masters wrote:
> Kumar Gala wrote:
>
> |> My intention was to give a device tree structure to the kernel at boot
> |> time via a (pseudo?) pointer in bd_info or similar.
> This got resurrected recently.
Hi!
> | I think this is reasonable. The best device tree would be a flattened
> | OF tree since we are trying to move the world in that direction. Jon
> | Masters around?
>
> Yes, but I've been tied up with worky and magazine stuff again. If
> someone wants to work with me then this might actually happen.
Hi Jon,
I'm here and actively(!) working on it now. Here is the very
rough plan as Kumar and I have discussed it. Please feel free
to comment on it or offer suggestions. Ben has suggested that
I start with the "second step" below. I'd like to do a round
of cleanup first.
So far, I have taken the first step of isolating the references
to the global __res[] variable into one file and replacing all
references to the data in the bd_t structure with a thin, shim
layer of function calls that are nominally into an OF-like
interface. I have done this for all the 85xx and 83xx boards
in my development tree, and am working on the others now.
This step effectively isolates the __res[] references to one
file where a well defined interface can be created to pose as
an OF Device Tree layer (briefly).
As a follow-up second step, I plan on introducing essentially
the same code currently in ppc64 to handle the flat device tree
and provide an interface to that data in exactly the same manner
as the ppc64 currently has. I understand the desire to have the
flat-tree handling be "outside the kernel".
As a third step, the shim layer will be rewritten/augmented to
use the actual OF device tree data where it currently fronts
for the bd_t data.
Finally, as time permits and maintainers allow (read: prod),
the other (not 85xx, not 83xx) boards can have their setup code
converted to use the "real" OF device tree function calls.
When all of that is done, the shim layer can be removed, as needed.
Oh, yeah. Um, also on my plate will be to construct the
original flat-tree blob in U-Boot to be handed to the kernel.
(I'll start with 85xx and 83xx, naturlich.)
We have not yet decided on the layout of that tree to determine
where all the attributes and devices really belong. I will
also discuss with Wolfgang and crew how to generate that tree
over in U-Boot land.
Right?
Thanks,
jdl
^ permalink raw reply
* RE: Problem running Linux 2.6.11 on MPC8272ADS
From: Jon Loeliger @ 2005-03-31 15:36 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: Linux PPC Embedded list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD46730117355F@zch01exm40.ap.freescale.net>
On Thu, 2005-03-31 at 02:22, Li Yang-r58472 wrote:
> Good point.
> There is also IMMR need to be passed from bootloader to kernel. We
> can make more use of the u-boot bd_info mechanism. But it binds ppc
> linux to u-boot boot loader. I don't know if we should make it a
> porting convention.
Hi guys,
So, just for the record here, Kumar and I are moving the ppc32
line away from bd_t towards an OpenFirmware flattened device tree.
That data will still have a place for the IMMR to be passed.
Under another Subject:, I'll describe a brief outline of
The Plan So Far so people can take shots at it. :-)
> Best Regards,
> Leo
Thanks,
jdl
^ permalink raw reply
* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Tom Rini @ 2005-03-31 14:28 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
In-Reply-To: <20050328232355.GA1982@pegasos>
On Tue, Mar 29, 2005 at 01:23:55AM +0200, Sven Luther wrote:
> Hello,
>
> I have been investigating the prep breakage of the sym53c8xx driver on my
> powerstack II in recent kernels, and traced it to the residual data patch,
> or more exactly to the whole prep_pci.c/prep_setup.c patches that where
> introduced between 2.6.9-rc1 and 2.6.9-rc1-bk1. I didn't have time to find
> more details as the patch is not so small, and seems to do many things, and
> linux.bkbits.net seems done right now.
>
> Mmm, after a bit more of investigation, the changeset breaking it is :
>
> # This is a BitKeeper generated diff -Nru style patch.
> #
> # ChangeSet
> # 2004/08/16 10:35:18-07:00 trini@kernel.crashing.org
> # ppc32: On PReP, use residual data for PCI dev -> IRQ, and use it.
> #
> # Signed-off-by: Leigh Brown <leigh@solinno.co.uk>
> # Signed-off-by: Tom Rini <trini@kernel.crashing.org>
> #
> # include/asm-ppc/residual.h
> # 2004/08/16 10:35:09-07:00 trini@kernel.crashing.org +7 -0
> # This adds a function to use the residual data to determine the IRQ
> # for a given PCI device, and changes prep_pcibios_fixup() to use it.
> #
> # arch/ppc/platforms/residual.c
> # 2004/08/16 10:35:09-07:00 trini@kernel.crashing.org +60 -0
> # This adds a function to use the residual data to determine the IRQ
> # for a given PCI device, and changes prep_pcibios_fixup() to use it.
> #
> # arch/ppc/platforms/prep_pci.c
> # 2004/08/16 10:35:09-07:00 trini@kernel.crashing.org +37 -23
> # This adds a function to use the residual data to determine the IRQ
> # for a given PCI device, and changes prep_pcibios_fixup() to use it.
>
> Mmm, i guess this makes sense, since it seems the sym53c8xx doesn'y find its
> irq anymore or something. Tom Rini, or Leigh Brown, do you have any comments
> on this one ?
Well, we'd need to be certain it's this patch. If it's this patch, I
think Leigh was suggesting at the time that the fix would be to fixup
the residual data with the correct information.
But what also went in were changes to specific irq maps, based on what
fixed a given machine for someone else, so one of those changes could
also be it.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Platform bus/ppc sys model - [Fwd: bi_recs and u-boot ppcboot.h]
From: Jon Masters @ 2005-03-31 12:36 UTC (permalink / raw)
To: jakob.viketoft; +Cc: tnt, akonovalov, linuxppc-embedded
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I hope Wolfgang doesn't mind me forwarding this :-) This is what I have
some limited time for at the moment - but work takes priority!
Cheers,
Jon.
- -------- Original Message --------
Subject: bi_recs and u-boot ppcboot.h
Date: Fri, 11 Mar 2005 03:00:18 +0000
From: Jon Masters <jonathan@jonmasters.org>
Organization: World Organi[sz]ation Of Broken Dreams
To: Wolfgang Denk <wd@denx.de>
Hi Wolfgang,
I'm looking at this bi_recs replacement again. Do you have any
particular objection to me extending bd_info (at the end, only if
CONFIG_FAKEOFTREE is selected) to add a pointer to a BLOB of fake OF
device tree?
Assuming not, I'm going to try to figure out how to do this in u-boot.
Do you have a ppc405 board online at the moment with a BDI2000 OOI? I
can't see one on pollux or xpert at the moment - if you've got one spare
that can be made available at some point, please let me know.
( basically, I've got ppcboot on an old CPCI405 here but it's not
trivial to fix if I break it and I don't know much about whether u-boot
supports chaining in to a new u-boot loaded from within itself...but it
probably does, I guess. Bah, it's late, I'm rambling...).
Cheers,
Jon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCS+7NeTyyexZHHxERAsVkAJ9WK/eHANzVdMTiPVRneHVuitt5FgCeOJCE
Oxf9aVCY4OG5+2kgmJfGgAw=
=BF/h
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Platform bus/ppc sys model...
From: Jon Masters @ 2005-03-31 12:33 UTC (permalink / raw)
To: Kumar Gala
Cc: Linux PPC Embedded list, Sylvain Munaut, Andrei Konovalov,
Jakob Viketoft
In-Reply-To: <111d2ae873d1bfee413409dfc4f2f064@freescale.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kumar Gala wrote:
|> My intention was to give a device tree structure to the kernel at boot
|> time via a (pseudo?) pointer in bd_info or similar. Then you would only
|> need to recompile a little bootloader (which is needed for setting up
|> the FPGA anyway) with this structure for every specific card. You could
|> even be shrewd enough to have a single kernel image but several
|> structures to launch several processors on the same chip. Does it sound
|> like a sane solution?
This got resurrected recently. Some of us have been talking privately
about it and I should have time with a board and BDI shortly. The idea
above about the bd_info pointer is precisely what I've been working with
people off list on.
| I think this is reasonable. The best device tree would be a flattened
| OF tree since we are trying to move the world in that direction. Jon
| Masters around?
Yes, but I've been tied up with worky and magazine stuff again. If
someone wants to work with me then this might actually happen.
Cheers,
Jon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCS+38eTyyexZHHxERAhKmAJ9v2k8rvFjB+W9OmXu4P7blHiWIkQCglEFk
AA2fZEsXmpWV0Jj/Z2OCrxA=
=oVje
-----END PGP SIGNATURE-----
^ permalink raw reply
* RE: Linux crashes during memory mapping
From: Steven Blakeslee @ 2005-03-31 12:53 UTC (permalink / raw)
To: Atit_Shah, linuxppc-embedded
> I do not have any problem with the functioning of U-Boot but
Linux crashes after =20
> printing "Uncompressing Kernel ... OK" and then it seems that nothing
is happening.
Do you have the SYPCR(serial watch dog timer) disabled?
=09
> 3. The memory map of the VPN Board (MY BOARD) is as folllows:=20
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> Memory Region Size
Address Range =20
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> SDRAM 32MByte 0000_0000
-- 01FF_FFFF =20
> Flash 32MByte FF00_0000
-- FFFF_FFFF =20
Have you done a full test to make sure your RAM is correctly mapped?
=20
> This is what the console log buffer has shown:=20
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> md 0x00177e34=20
>
> 00177e34: 3c363e6d 73746172 743d303c 363e6d73
<6>mstart=3D0<6>ms=20
> 00177e44: 697a653d 303c363e 66737461 72743d30
ize=3D0<6>fstart=3D0=20
> 00177e54: 3c363e66 73697a65 3d303c36 3e696d6d
<6>fsize=3D0<6>imm=20
> 00177e64: 723d303c 363e626f 74666c61 673d303c
r=3D0<6>botflag=3D0<=20
> 00177e74: 363e6970 6164643d 303c363e 65616464
6>ipadd=3D0<6>eadd=20
> 00177e84: 3d633031 35303032 383c363e 65737065
=3Dc0150028<6>espe=20
> 00177e94: 643d303c 363e696e 6974663d 303c363e
d=3D0<6>initf=3D0<6>=20
> 00177ea4: 62757366 3d303c36 3e63706d 663d303c
busf=3D0<6>cpmf=3D0<=20
> 00177eb4: 363e6272 67663d30 3c363e73 6363663d
6>brgf=3D0<6>sccf=3D=20
> 00177ec4: 303c363e 76636f3d 303c363e 62617564
0<6>vco=3D0<6>baud=20
> 00177ed4: 3d304f6f 70733a20 6b65726e 656c2061 =3D0Oops: kernel
a=20
=09
These values do not look correct. Everything is zero.
^ permalink raw reply
* service outage
From: Stephen Rothwell @ 2005-03-31 11:46 UTC (permalink / raw)
To: ppc64-dev; +Cc: linuxppc-dev, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
Hi all,
There will be a (hopefully short) service disruption tomorrow (Friday
April 1) at 1pm Canberra time (3 am UTC) to these mailing lists and the
ozlabs.org web site while our hosting ISP changes upstream service
provider.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problem running Linux 2.6.11 on MPC8272ADS
From: Eugene Surovegin @ 2005-03-31 11:17 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: Linux PPC Embedded list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD46730117355F@zch01exm40.ap.freescale.net>
On Thu, Mar 31, 2005 at 04:22:26PM +0800, Li Yang-r58472 wrote:
> Good point.
> There is also IMMR need to be passed from bootloader to kernel. We
> can make more use of the u-boot bd_info mechanism. But it binds ppc
> linux to u-boot boot loader. I don't know if we should make it a
> porting convention.
Well, immr is _already_ part of bd_t passed from U-Boot! I was
surprised that none of board ports (some of which are made for U-Boot
only) use this.
In 8248 based board port I'm working on right now, I already defined
CPM_MAP_ADDR as follows:
#define CPM_MAP_ADDR (((bd_t*)__res)->bi_immr_base)
--
Eugene
^ permalink raw reply
* How to read/write in flash memories (MTD)?
From: Garcia Jérémie @ 2005-03-31 9:59 UTC (permalink / raw)
To: linuxppc-dev
L&G,
Although I'm a newbie in linux kernel development, I'm in charge of =
adapting a Montavista LSP to fit our hardware. In our platform, we use 2 =
AMD flash memories (AM29LV) in which one we would like to process =
read/write operations. So I'm looking for a way to do that. I saw that =
at compilation time, there is MTD item which seems to be created for =
that. But I guess activate that will not be enough to reach my =
objective.
Indeed, we are developping an application (in the user-space) which will =
initiate operation on the 2 flash memories. So, how can I access them =
from my application?
Please help me cause I'm getting lost in the linux sources....
NOTE: i'm using a powerPC 405EP
J=E9r=E9mie
^ permalink raw reply
* Re: Overcommit (OOM) problem on embedded device (PPChameleon)
From: Martin Egholm Nielsen @ 2005-03-31 8:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <42416091@webmail>
Hi Per,
> I think your main problem is that the stock 2.4.x kernel doesn't support
> ovecommit_memory type 2 (i believe)...
Doooh! You're so right!
I read the docs on overcommit_memory from 2.6 - stupid me!
> Look in mm/mmap.c and search for overcommit_memory, then do same
> in the sources for your redhat kernels.
I'll look into RH kernel to see if it isn't like you say :-)
> Perhaps there's a patch for it floating around somewhere? ;-)
Now, that would be really nice.
Though I have no idea of where to look!?
Thanks for clearing my mind!
BR,
Martin
>
>
>>===== Original Message From Martin Egholm Nielsen <martin@egholm-nielsen.dk>
>
> =====
>
>>Hi there,
>>
>>I hope this is the place to go...
>>
>>I have a some problems figuring out the OOM-killer and configuring the
>>overcommit_memory parameter. Hope someone here can guide me in the right
>>directions...
>>
>>Specs:
>>I'm having an embedded Linux system running on a PPC405EP (PPChameleon)
>>with 64 megs of RAM, some flash, but (ofcourse) no swap space. It runs a
>>2.4.20 kernel patched with drivers for my device.
>>
>>Problem:
>>I have an application that is killed by the OOM (I guess) when it tries
>>to "use" more memory than present on the system.
>>Bolied down, memory is allocated with "sbrk" and then touch'ed (see
>>test-application below).
>>
>>With "/proc/sys/vm/overcommit_memory" set to 2, I expected that "sbrk"
>>would return "-1L" (0xFFFFFFFF), but it doesn't, hence is
>>terminated/killed by the kernel.
>>
>>However, both my desktop Linux (RH 7.3)/2.4.18-10/i386 and Linux
>>(FC2)/2.6.5/i386 did what I expected:
>>
>># ./exhaust_mem
>>...
>>ffffffff
>>
>>Out of memory
>># #Yeaaaah!
>>
>>Having searched the web, I see that this may be related with the fact
>>that there is no swap enabled on the embedded device.
>>However, I tried disabling the swap (commented in fstab), but the
>>desktop linux still behaves "correct".
>>
>>Can I do anything in order to get it the way I expected?
>>
>>Best regards,
>> Martin Egholm
>>
>>=== exhaust_mem.c ===
>>
>>#include <unistd.h>
>>#include <stdio.h>
>>#define SIZE 1000000
>>
>>int main( int i )
>>{
>> while ( 1 ) {
>> char *v = sbrk( SIZE );
>> char *p;
>>
>> printf( "%x\n\n", v );
>>
>> if ((long)v < 0) {
>> fprintf(stderr, "Out of memory\n");
>> exit(1);
>> } // if
>>
>> for (p = v; p < v + SIZE; ++p) {
>> *p = 42;
>> } // for
>>
>> } // while
>>} // main
>>
>>
>>
>>
>>
>>
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
>
^ permalink raw reply
* RE: Problem running Linux 2.6.11 on MPC8272ADS
From: Li Yang-r58472 @ 2005-03-31 8:22 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Linux PPC Embedded list
Good point.
There is also IMMR need to be passed from bootloader to kernel. We can make more use of the u-boot bd_info mechanism. But it binds ppc linux to u-boot boot loader. I don't know if we should make it a porting convention.
Best Regards,
Leo
> -----Original Message-----
> From: Eugene Surovegin [mailto:ebs@ebshome.net]
> Sent: Thursday, March 31, 2005 11:27 AM
> To: Li Yang-r58472
> Cc: Walter L. Wimer III; Gala Kumar K.-galak; Linux PPC Embedded list
> Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS
>
> On Thu, Mar 31, 2005 at 11:03:00AM +0800, Li Yang-r58472 wrote:
> > Well, it seems to be a historic problem. Freescale BSP was
> > originally ported from u-boot-1.0.0 and linux-2.4.22. So the BCSR
> > was freely chosen as 0xf8000000. Later, we updated them to
> > u-boot-1.1.1 and linux-2.4.26, and make the BCSR consistent to older
> > version. However the sourceforge u-boot-1.1.1 support for
> > MPC8272ADS
> > was committed by Arabella guys, they chose BCSR mapping to
> > 0xf4500000. Kumar's MPC8272 support which is in 2.6.11 source was
> > developed using sourceforge u-boot-1.1.1 seemingly.
> >
> > This might brought up a question that if we need a convention or
> > something to define the recommended memory mapping for PowerPC BSPs.
> > As there are different groups of people around the world developing
> > BSPs for PowerPC platforms, and often the communication between them
> > is very limited.
> >
> > For now using kernel and u-boot released from the same vendor is recommended.
> >
>
> There is trivial solution which will work regardless on which version
> of U-Boot and kernel you are using.
>
> DO NOT hardcode such stuff in TWO DIFFERENT places, do this only in
> one, in this case it should be firmware (e.g. U-Boot).
>
> In kernel just read BRx register for that chip select and use this
> address for accesses from the kernel. This is how I do on all my
> board ports.
>
> No need to establish any artificial conventions on memory map, etc.
>
> --
> Eugene
^ permalink raw reply
* Re: Overcommit (OOM) problem on embedded device (PPChameleon)
From: Martin Egholm Nielsen @ 2005-03-31 6:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <42416091@webmail>
Hi Per,
> I think your main problem is that the stock 2.4.x kernel doesn't support
> ovecommit_memory type 2 (i believe)...
Doooh! You're so right!
I read the docs on overcommit_memory from 2.6 - stupid me!
> Look in mm/mmap.c and search for overcommit_memory, then do same
> in the sources for your redhat kernels.
I'll look into RH kernel to see if it isn't like you say :-)
> Perhaps there's a patch for it floating around somewhere? ;-)
Now, that would be really nice.
Though I have no idea of where to look!?
Thanks for clearing my mind!
BR,
Martin
>
>
>>===== Original Message From Martin Egholm Nielsen <martin@egholm-nielsen.dk>
>
> =====
>
>>Hi there,
>>
>>I hope this is the place to go...
>>
>>I have a some problems figuring out the OOM-killer and configuring the
>>overcommit_memory parameter. Hope someone here can guide me in the right
>>directions...
>>
>>Specs:
>>I'm having an embedded Linux system running on a PPC405EP (PPChameleon)
>>with 64 megs of RAM, some flash, but (ofcourse) no swap space. It runs a
>>2.4.20 kernel patched with drivers for my device.
>>
>>Problem:
>>I have an application that is killed by the OOM (I guess) when it tries
>>to "use" more memory than present on the system.
>>Bolied down, memory is allocated with "sbrk" and then touch'ed (see
>>test-application below).
>>
>>With "/proc/sys/vm/overcommit_memory" set to 2, I expected that "sbrk"
>>would return "-1L" (0xFFFFFFFF), but it doesn't, hence is
>>terminated/killed by the kernel.
>>
>>However, both my desktop Linux (RH 7.3)/2.4.18-10/i386 and Linux
>>(FC2)/2.6.5/i386 did what I expected:
>>
>># ./exhaust_mem
>>...
>>ffffffff
>>
>>Out of memory
>># #Yeaaaah!
>>
>>Having searched the web, I see that this may be related with the fact
>>that there is no swap enabled on the embedded device.
>>However, I tried disabling the swap (commented in fstab), but the
>>desktop linux still behaves "correct".
>>
>>Can I do anything in order to get it the way I expected?
>>
>>Best regards,
>> Martin Egholm
>>
>>=== exhaust_mem.c ===
>>
>>#include <unistd.h>
>>#include <stdio.h>
>>#define SIZE 1000000
>>
>>int main( int i )
>>{
>> while ( 1 ) {
>> char *v = sbrk( SIZE );
>> char *p;
>>
>> printf( "%x\n\n", v );
>>
>> if ((long)v < 0) {
>> fprintf(stderr, "Out of memory\n");
>> exit(1);
>> } // if
>>
>> for (p = v; p < v + SIZE; ++p) {
>> *p = 42;
>> } // for
>>
>> } // while
>>} // main
>>
>>
>>
>>
>>
>>
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
>
^ permalink raw reply
* Linux crashes during memory mapping
From: Atit_Shah @ 2005-03-31 4:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 8419 bytes --]
Hi All,
I am trying to port the EP8248 Linux image (which works perfectly on the
EP8248 board) on the VPN board (In house board) which is mpc8248 based
board.
I do not have any problem with the functioning of U-Boot but Linux crashes
after printing "Uncompressing Kernel ... OK" and then it seems that nothing
is happening.
It would be great if u could help me resolve the issue. The following is how
i have configured my board:
1. The value of the IMMR in HCRW is configured to 0xF0000000 (which is same
as in the ep8248 image). The value of IMAP_ADDR in
linux/arch/ppc/platforms/ep8248.h and u-boot/include/configs/ep8248.h is
0xF0000000
2. The memory map of EP8248 board (REFERENCE BOARD) is :
=====================================================================
Memory Region Size Address Range
=====================================================================
SDRAM 16MByte 0000_0000 -- 07FF_FFFF
Flash 8MByte FF80_0000 -- FFFF_FFFF
3. The memory map of the VPN Board (MY BOARD) is as folllows:
=====================================================================
Memory Region Size Address Range
======================================================================
SDRAM 32MByte 0000_0000 -- 01FF_FFFF
Flash 32MByte FF00_0000 -- FFFF_FFFF
>From the u-boot the parameters passed to the kernel (pointer to a function
which actually starts loading the kernel image) are :
(*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end);
kbd (ptr to board info strcture),
initrd_start (=0, as in our case we dont have any ramdisk),
initrd_end (=0),
cmd_start (Start of command line string),
cmd_end (End of command line string)
4. Board Info Structure defined in u-boot (/include/asm-ppc/u-boot.h) and
Linux (include/asm-ppc/ep8248.h) are the same and is passed correctly from
u-boot to Linux.
By putting some Printk's I had cheacked that control is reaching to the
function mapin_ram(void) in file arch/ppc/mm/pgtable.c
Here it is supposed to map the 32 MB of virtual memory to the Physical
memory.
The control does not leave the for loop in which the memory mapping takes
place.
This is what the console log buffer has shown:
=================================================================
md 0x00177e34
00177e34: 3c363e6d 73746172 743d303c 363e6d73 <6>mstart=0<6>ms
00177e44: 697a653d 303c363e 66737461 72743d30 ize=0<6>fstart=0
00177e54: 3c363e66 73697a65 3d303c36 3e696d6d <6>fsize=0<6>imm
00177e64: 723d303c 363e626f 74666c61 673d303c r=0<6>botflag=0<
00177e74: 363e6970 6164643d 303c363e 65616464 6>ipadd=0<6>eadd
00177e84: 3d633031 35303032 383c363e 65737065 =c0150028<6>espe
00177e94: 643d303c 363e696e 6974663d 303c363e d=0<6>initf=0<6>
00177ea4: 62757366 3d303c36 3e63706d 663d303c busf=0<6>cpmf=0<
00177eb4: 363e6272 67663d30 3c363e73 6363663d 6>brgf=0<6>sccf=
00177ec4: 303c363e 76636f3d 303c363e 62617564 0<6>vco=0<6>baud
00177ed4: 3d304f6f 70733a20 6b65726e 656c2061 =0Oops: kernel a
00177ee4: 63636573 73206f66 20626164 20617265 ccess of bad are
00177ef4: 612c2073 69673a20 31310a3c 343e4e49 a, sig: 11.<4>NI
00177f04: 503a2030 30303030 30303020 5845523a P: 00000000 XER:
00177f14: 20303030 30303030 30204c52 3a203030 00000000 LR: 00
00177f24: 30303030 30302053 503a2030 30303030 000000 SP: 00000
00177f34: 30303020 52454753 3a206330 31353030 000 REGS: c01500
00177f44: 30302054 5241503a 20303030 30202020 00 TRAP: 0000
00177f54: 204e6f74 20746169 6e746564 0a3c343e Not tainted.<4>
00177f64: 4d53523a 20303030 30303030 30204545 MSR: 00000000 EE
00177f74: 3a203020 50523a20 30204650 3a203020 : 0 PR: 0 FP: 0
00177f84: 4d453a20 30204952 2f44523a 2030300a ME: 0 IR/DR: 00.
00177f94: 3c343e54 41534b20 3d206330 31346634 <4>TASK = c014f4
00177fa4: 37305b30 5d202773 77617070 65722720 70[0] 'swapper'
00177fb4: 4c617374 20737973 63616c6c 3a203020 Last syscall: 0
00177fc4: 0a3c343e 6c617374 206d6174 68203030 .<4>last math 00
00177fd4: 30303030 3030206c 61737420 616c7469 000000 last alti
00177fe4: 76656320 30303030 30303030 0a3c343e vec 00000000.<4>
00177ff4: 43616c6c 20626163 6b747261 63653a20 Call backtrace:
00178004: 30303030 30303034 200a3c34 3e4f6f70 00000004 .<4>Oop
00178014: 733a206b 65726e65 6c206163 63657373 s: kernel access
00178024: 206f6620 62616420 61726561 2c207369 of bad area, si
00178034: 673a2031 310a3c34 3e4e4950 3a204330 g: 11.<4>NIP: C0
00178044: 31353030 43302058 45523a20 43303135 1500C0 XER: C015
00178054: 30304138 204c523a 20303330 30303043 00A8 LR: 030000C
00178064: 30205350 3a203030 30333030 30312052 0 SP: 00030001 R
00178074: 4547533a 20633031 35303030 30205452 EGS: c0150000 TR
00178084: 41503a20 63303135 30306330 20202020 AP: c01500c0
00178094: 4e6f7420 7461696e 7465640a 3c343e4d Not tainted.<4>M
001780a4: 53523a20 66666666 66646661 2045453a SR: fffffdfa EE:
001780b4: 20312050 523a2031 2046503a 2031204d 1 PR: 1 FP: 1 M
001780c4: 453a2031 2049522f 44523a20 31310a3c E: 1 IR/DR: 11.<
001780d4: 343e5441 534b203d 20633031 34663437 4>TASK = c014f47
001780e4: 305b305d 20277377 61707065 7227204c 0[0] 'swapper' L
001780f4: 61737420 73797363 616c6c3a 2030200a ast syscall: 0 .
00178104: 3c343e6c 61737420 6d617468 20303030 <4>last math 000
00178114: 30303030 30206c61 73742061 6c746976 00000 last altiv
00178124: 65632030 30303030 3030300a 3c343e43 ec 00000000.<4>C
00178134: 616c6c20 6261636b 74726163 653a2030 all backtrace: 0
00178144: 30303030 30303420 0a3c343e 4f6f7073 0000004 .<4>Oops
00178154: 3a206b65 726e656c 20616363 65737320 : kernel access
00178164: 6f662062 61642061 7265612c 20736967 of bad area, sig
00178174: 3a203131 0a3c343e 4e49503a 20433031 : 11.<4>NIP: C01
00178184: 35303043 30205845 523a2043 30313530 500C0 XER: C0150
00178194: 30413820 4c523a20 30303030 31303332 0A8 LR: 00001032
001781a4: 2053503a 20433030 31333946 30205245 SP: C00139F0 RE
001781b4: 47533a20 63303135 30303030 20545241 GS: c0150000 TRA
001781c4: 503a2063 30313530 30633020 2020204e P: c01500c0 N
001781d4: 6f742074 61696e74 65640a3c 343e4d53 ot tainted.<4>MS
001781e4: 523a2066 66666666 64666120 45453a20 R: fffffdfa EE:
001781f4: 31205052 3a203120 46503a20 31204d45 1 PR: 1 FP: 1 ME
00178204: 3a203120 49522f44 523a2031 310a3c34 : 1 IR/DR: 11.<4
00178214: 3e544153 4b203d20 63303134 66343730 >TASK = c014f470
00178224: 5b305d20 27737727 204c6173 74207379 [0] 'sw' Last sy
00178234: 7363616c 6c3a202d 31303732 33363535 scall: -10723655
00178244: 3638200a 3c343e6c 61737420 6d617468 68 .<4>last math
00178254: 20303030 30303030 30206c61 73742061 00000000 last a
00178264: 6c746976 65632030 30303030 3030300a ltivec 00000000.
00178274: 00000000 00000000 00000000 00000000 ................
1.Is all this information sufficient to help you understand and pin point
our mistake, Is there any thing other than the parameters which are passed
to the kernel from the u-boot that I need to look into.
2. I have a query in the Linux source code. I would like to know why the
value of "ioremap_base = 0xfe000000UL;" in linux/arch/ppc/mm/init.c line 356
has been hard coded and how was this value determined? What is the impact of
this value?
Any pointers, ideas, comments would be of great help. i would be more than
glad to provide you with any further information required to debug the
problem.
Thanks and best regards,
Atit
**************************************************************************
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.
**************************************************************************
[-- Attachment #2: Type: text/html, Size: 15726 bytes --]
^ permalink raw reply
* Re: [PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms including Redwood5
From: Dale Farnsworth @ 2005-03-31 5:18 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050331010747.GA18254@gate.ebshome.net>
On Wed, Mar 30, 2005 at 05:07:47PM -0800, Eugene Surovegin wrote:
> On Wed, Mar 30, 2005 at 05:05:21PM -0700, Dale Farnsworth wrote:
>
> [snip]
>
> > +/* Power up the USB subsection */
> > +static int enable_usb(struct platform_device *pdev)
> > +{
> > + u32 mask;
> > +
> > + mask = 1 << (31 - USB0_IRQ);
> > + mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
> > + mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) & ~mask);
> > + return 0;
> > +}
> > +
> > +/* Power down the USB subsection */
> > +static void disable_usb(struct platform_device *pdev)
> > +{
> > + u32 mask;
> > +
> > + mask = 1 << (31 - USB0_IRQ);
> > + mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) & ~mask);
> > + mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) | mask);
> > +}
>
> Dale, I'm curious, what's going on here :) ?.
>
> How changing polarity and triggering setting could power-down USB
> unit? Some STB funkiness?
No. It's brown paper bag time. Looks bogus to me now, too.
Please ignore the patch. I'll redo it and resubmit.
Thanks Eugene,
-Dale
^ permalink raw reply
* Problem in Viewml why doing make
From: Vijesh VH @ 2005-03-31 3:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <8e78982e050330194058a5daa6@mail.gmail.com>
Hi,
I downloaded the viewml0.23 from site and configured it with
microwindows0.90 and FLNX0.14(FLTK1.0.7). When i gave the command make
all i received the following messages. Can anyone help me in solving
the problem in viewml 0.23 as early as possible.
********************************************************************************
make[1]: Entering directory `/root/viewml/src'
if [ ! -s .build_depends ]; then make -f build_depends.mk force-depends; fi
make[2]: Entering directory `/root/viewml/src'
Generating dependancies for /root/viewml/src...
g++ -M -L/usr/include -INONE/include -I. -I../kdecore -I../kimgio
-I../kdeui -I../jscript -I/root/flnx-0.17 -I/root/flnx-0.17/FL
-I./fltk -I/root/microwindows-0.90/include -I/usr/include/microwin
-I/include -I/include/par -g --permissive -DNANOX -D_NANOX
-I/usr/X11R6/include `/usr/local/bin/libwww-config --cflags` html.cpp
htmlchain.cpp htmlclue.cpp htmldata.cpp htmlfont.cpp htmliter.cpp
htmltable.cpp htmltoken.cpp jscript.cpp htmlview.cpp htmlframe.cpp
htmlobj.cpp debug.cpp htmlform.cpp main.cpp http.cpp http_.cpp
../kdecore/kurl.cpp ../kdeui/kcursor.cpp fltk/qtimer.cpp
fltk/qobject.cpp fltk/qpainter.cpp fltk/qdrawutil.cpp fltk/qfont.cpp
fltk/qrect.cpp fltk/qregexp.cpp fltk/qstring.cpp fltk/kcharsets.cpp
fltk/qcolor.cpp fltk/qpixmap.cpp fltk/qfontinfo.cpp fltk/qwidget.cpp
fltk/history.cpp fltk/qscrollbar.cpp fltk/nxslider.cpp
fltk/nxscrollbar.cpp fltk/nxscroll.cpp >> .build_depends
make[2]: Leaving directory `/root/viewml/src'
make[1]: Leaving directory `/root/viewml/src'
make[1]: Entering directory `/root/viewml/src'
g++ -L/usr/include -INONE/include -I. -I../kdecore -I../kimgio
-I../kdeui -I../jscript -I/root/flnx-0.17 -I/root/flnx-0.17/FL
-I./fltk -I/root/microwindows-0.90/include -I/usr/include/microwin
-I/include -I/include/par -g --permissive -DNANOX -D_NANOX
-I/usr/X11R6/include `/usr/local/bin/libwww-config --cflags` -I.. -c
-o html.o html.cpp
In file included from /usr/include/c++/3.3.3/backward/algo.h:59,
from fltk/qstring.h:4,
from ../kdecore/kurl.h:31,
from html.cpp:24:
/usr/include/c++/3.3.3/backward/backward_warning.h:32:2: warning:
#warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section
17.4.1.2 of the C++ standard. Examples include substituting the <X>
header for the <X.h> header for C++ includes, or <sstream> instead of
the deprecated header <strstream.h>. To disable this warning use
-Wno-deprecated.
In file included from /usr/include/c++/3.3.3/bits/locale_facets.tcc:41,
from /usr/include/c++/3.3.3/locale:47,
from /usr/include/c++/3.3.3/bits/ostream.tcc:37,
from /usr/include/c++/3.3.3/ostream:535,
from /usr/include/c++/3.3.3/iostream:45,
from /usr/include/c++/3.3.3/backward/iostream.h:32,
from /usr/include/c++/3.3.3/backward/iterator.h:33,
from /usr/include/c++/3.3.3/backward/algobase.h:60,
from /usr/include/c++/3.3.3/backward/algo.h:60,
from fltk/qstring.h:4,
from ../kdecore/kurl.h:31,
from html.cpp:24:
/usr/include/c++/3.3.3/cmath:107: error: `acosf' not declared
/usr/include/c++/3.3.3/cmath:110: error: `asinf' not declared
/usr/include/c++/3.3.3/cmath:113: error: `atanf' not declared
/usr/include/c++/3.3.3/cmath:116: error: `atan2f' not declared
/usr/include/c++/3.3.3/cmath:119: error: `ceilf' not declared
/usr/include/c++/3.3.3/cmath:122: error: `coshf' not declared
/usr/include/c++/3.3.3/cmath:125: error: `expf' not declared
/usr/include/c++/3.3.3/cmath:128: error: `floorf' not declared
/usr/include/c++/3.3.3/cmath:131: error: `fmodf' not declared
/usr/include/c++/3.3.3/cmath:134: error: `frexpf' not declared
/usr/include/c++/3.3.3/cmath:137: error: `ldexpf' not declared
/usr/include/c++/3.3.3/cmath:140: error: `logf' not declared
/usr/include/c++/3.3.3/cmath:143: error: `log10f' not declared
/usr/include/c++/3.3.3/cmath:146: error: `modff' not declared
/usr/include/c++/3.3.3/cmath:149: error: `powf' not declared
/usr/include/c++/3.3.3/cmath:152: error: `sinhf' not declared
/usr/include/c++/3.3.3/cmath:155: error: `tanf' not declared
/usr/include/c++/3.3.3/cmath:158: error: `tanhf' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::acos(float)':
/usr/include/c++/3.3.3/cmath:184: error: `acosf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:190: error: `acos' not declared
/usr/include/c++/3.3.3/cmath: In function `long double std::acos(long double)':
/usr/include/c++/3.3.3/cmath:194: error: `::acosl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:200: error: `asin' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::asin(float)':
/usr/include/c++/3.3.3/cmath:204: error: `asinf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::asin(long double)':
/usr/include/c++/3.3.3/cmath:212: error: `::asinl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:218: error: `atan' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::atan(float)':
/usr/include/c++/3.3.3/cmath:222: error: `atanf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::atan(long double)':
/usr/include/c++/3.3.3/cmath:230: error: `::atanl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:236: error: `atan2' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::atan2(float, float)':
/usr/include/c++/3.3.3/cmath:240: error: `atan2f' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::atan2(long double,
long double)':
/usr/include/c++/3.3.3/cmath:249: error: `::atan2l' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:256: error: `ceil' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::ceil(float)':
/usr/include/c++/3.3.3/cmath:260: error: `ceilf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::ceil(long double)':
/usr/include/c++/3.3.3/cmath:268: error: `::ceill' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:274: error: `cos' not declared
/usr/include/c++/3.3.3/cmath:284: error: `cosh' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::cosh(float)':
/usr/include/c++/3.3.3/cmath:288: error: `coshf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::cosh(long double)':
/usr/include/c++/3.3.3/cmath:296: error: `::coshl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:302: error: `exp' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::exp(float)':
/usr/include/c++/3.3.3/cmath:306: error: `expf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::exp(long double)':
/usr/include/c++/3.3.3/cmath:314: error: `::expl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:320: error: `fabs' not declared
/usr/include/c++/3.3.3/cmath:330: error: `floor' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::floor(float)':
/usr/include/c++/3.3.3/cmath:334: error: `floorf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::floor(long double)
':
/usr/include/c++/3.3.3/cmath:342: error: `::floorl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:348: error: `fmod' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::fmod(float, float)':
/usr/include/c++/3.3.3/cmath:352: error: `fmodf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::fmod(long double,
long double)':
/usr/include/c++/3.3.3/cmath:361: error: `::fmodl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:368: error: `frexp' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::frexp(float, int*)':
/usr/include/c++/3.3.3/cmath:372: error: `frexpf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::frexp(long double,
int*)':
/usr/include/c++/3.3.3/cmath:380: error: `::frexpl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:387: error: `ldexp' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::ldexp(float, int)':
/usr/include/c++/3.3.3/cmath:391: error: `ldexpf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::ldexp(long double,
int)':
/usr/include/c++/3.3.3/cmath:400: error: `::ldexpl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:407: error: `log' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::log(float)':
/usr/include/c++/3.3.3/cmath:411: error: `logf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::log(long double)':
/usr/include/c++/3.3.3/cmath:419: error: `::logl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:425: error: `log10' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::log10(float)':
/usr/include/c++/3.3.3/cmath:429: error: `log10f' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::log10(long double)
':
/usr/include/c++/3.3.3/cmath:437: error: `::log10l' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:443: error: `modf' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::modf(float, float*)':
/usr/include/c++/3.3.3/cmath:447: error: `modff' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::modf(long double,
long double*)':
/usr/include/c++/3.3.3/cmath:461: error: `::modfl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:482: error: `pow' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::pow(float, float)':
/usr/include/c++/3.3.3/cmath:486: error: `powf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::pow(long double,
long double)':
/usr/include/c++/3.3.3/cmath:495: error: `::powl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:514: error: `sin' not declared
/usr/include/c++/3.3.3/cmath:524: error: `sinh' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::sinh(float)':
/usr/include/c++/3.3.3/cmath:528: error: `sinhf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::sinh(long double)':
/usr/include/c++/3.3.3/cmath:536: error: `::sinhl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:542: error: `sqrt' not declared
/usr/include/c++/3.3.3/cmath:552: error: `tan' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::tan(float)':
/usr/include/c++/3.3.3/cmath:556: error: `tanf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::tan(long double)':
/usr/include/c++/3.3.3/cmath:564: error: `::tanl' undeclared (first use here)
/usr/include/c++/3.3.3/cmath: At global scope:
/usr/include/c++/3.3.3/cmath:570: error: `tanh' not declared
/usr/include/c++/3.3.3/cmath: In function `float std::tanh(float)':
/usr/include/c++/3.3.3/cmath:574: error: `tanhf' undeclared in namespace `
__gnu_cxx::__c99_binding'
/usr/include/c++/3.3.3/cmath: In function `long double std::tanh(long double)':
/usr/include/c++/3.3.3/cmath:582: error: `::tanhl' undeclared (first use here)
make[1]: *** [html.o] Interrupt
make: *** [viewml] Interrupt
*************************************************************************************************
I think the problem may with the c++include directory that i used.
Help me please.
--
Thanks and Regards,
Vijesh V H
--
Thanks and Regards,
Vijesh V H
^ permalink raw reply
* Re: Problem running Linux 2.6.11 on MPC8272ADS
From: Eugene Surovegin @ 2005-03-31 3:26 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: Linux PPC Embedded list
In-Reply-To: <9FCDBA58F226D911B202000BDBAD4673011732F4@zch01exm40.ap.freescale.net>
On Thu, Mar 31, 2005 at 11:03:00AM +0800, Li Yang-r58472 wrote:
> Well, it seems to be a historic problem. Freescale BSP was
> originally ported from u-boot-1.0.0 and linux-2.4.22. So the BCSR
> was freely chosen as 0xf8000000. Later, we updated them to
> u-boot-1.1.1 and linux-2.4.26, and make the BCSR consistent to older
> version. However the sourceforge u-boot-1.1.1 support for
> MPC8272ADS
> was committed by Arabella guys, they chose BCSR mapping to
> 0xf4500000. Kumar's MPC8272 support which is in 2.6.11 source was
> developed using sourceforge u-boot-1.1.1 seemingly.
>
> This might brought up a question that if we need a convention or
> something to define the recommended memory mapping for PowerPC BSPs.
> As there are different groups of people around the world developing
> BSPs for PowerPC platforms, and often the communication between them
> is very limited.
>
> For now using kernel and u-boot released from the same vendor is recommended.
>
There is trivial solution which will work regardless on which version
of U-Boot and kernel you are using.
DO NOT hardcode such stuff in TWO DIFFERENT places, do this only in
one, in this case it should be firmware (e.g. U-Boot).
In kernel just read BRx register for that chip select and use this
address for accesses from the kernel. This is how I do on all my
board ports.
No need to establish any artificial conventions on memory map, etc.
--
Eugene
^ permalink raw reply
* RE: Problem running Linux 2.6.11 on MPC8272ADS
From: Li Yang-r58472 @ 2005-03-31 3:03 UTC (permalink / raw)
To: Walter L. Wimer III, Kumar Gala, Linux PPC Embedded list
Well, it seems to be a historic problem. Freescale BSP was originally ported from u-boot-1.0.0 and linux-2.4.22. So the BCSR was freely chosen as 0xf8000000. Later, we updated them to u-boot-1.1.1 and linux-2.4.26, and make the BCSR consistent to older version. However the sourceforge u-boot-1.1.1 support for MPC8272ADS was committed by Arabella guys, they chose BCSR mapping to 0xf4500000. Kumar's MPC8272 support which is in 2.6.11 source was developed using sourceforge u-boot-1.1.1 seemingly.
This might brought up a question that if we need a convention or something to define the recommended memory mapping for PowerPC BSPs. As there are different groups of people around the world developing BSPs for PowerPC platforms, and often the communication between them is very limited.
For now using kernel and u-boot released from the same vendor is recommended.
Best Regards,
Leo
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Walter L. Wimer
> III
> Sent: Thursday, March 31, 2005 12:00 AM
> To: Linux PPC Embedded list
> Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS
>
>
> This matched my experience as well.
>
> Does anyone know why U-Boot 1.1.1 from Freescale uses a different BCSR
> address than U-Boot 1.1.1 from Sourceforge?
>
> Any opinions on which address is the "correct" one to use? Kumar asked
> for a patch to fix this, so what do we think the correct fix is?
>
>
>
> Thanks!
>
> Walt
>
>
>
> On Wed, 2005-03-30 at 10:18 +0200, Mike Rapoport wrote:
> > Walter,
> > Thanks for you help. I've discovered several things and now the things
> > seem to work fine.
> > I've used u-boot-1.1.1 that came with the Freescale BSP and it maps BCSR
> > to 0xf8000000. The "regular" u-boot-1.1.1 (from sf.net) maps the BCSR to
> > 0xf4500000 as well as the kernel does (arch/ppc/platforms/pq2ads.h). The
> > difference causes the "hang"-like behaviour when the kernel initializes
> > serial comm and kernel crash afterwards when FCC is initialized.
> >
> > Mike.
> >
> > >Thanks for the data points, Alex.
> > >
> > >I'm using U-Boot 1.1.1 and vanilla kernel.org 2.6.11.4 (actually now
> > >2.6.11.5). My BCSR_ADDR looks the same as what you've listed below, so
> > >I'd guess the difference is with U-Boot... (Another engineer here
> > >installed U-Boot on my board, from, I believe, a binary copy he got from
> > >a Freescale(?) CD... I didn't build U-Boot from source... That's
> > >something I'll need to take a look at...)
> > >
> > >Mike, have you discovered anything further about your problem?
> > >
> > >
> > >
> > >Walt
> > >
> > >
> > >
> > >On Tue, 2005-03-29 at 08:29 +0200, Bastos Fernandez Alexandre wrote:
> > >
> > >
> > >>Hi,
> > >>
> > >>>From "linux/arch/ppc/platforms/pq2ads.h"
> > >>#define BCSR_ADDR ((uint) 0xf4500000)
> > >>>From "u-boot/include/configs/MPC8260ADS.h"
> > >>#define CFG_BCSR 0xF4500000
> > >>So ...
> > >>Which version of u-boot and/or linux tree are you using?
> > >>With linuxppc-2.5 and u-boot 1.2 everything works fine for me.
> > >>Maybe Mike's problem is other. Maybe not. :-)
> > >>
> > >>Best regards,
> > >>Alex
> > >>
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From: Walter L. Wimer III [SMTP:walt.wimer@timesys.com]
> > >>>Sent: Monday, March 28, 2005 6:07 PM
> > >>>To: Mike Rapoport
> > >>>Cc: linuxppc-embedded@ozlabs.org
> > >>>Subject: Re: Problem running Linux 2.6.11 on MPC8272ADS
> > >>>
> > >>>
> > >>>Hi Mike,
> > >>>
> > >>>I had the same "hang" experience. The file arch/ppc/platforms/pq2ads.c
> > >>>contains the following function:
> > >>>
> > >>> void __init
> > >>> m82xx_board_setup(void)
> > >>> {
> > >>> /* Enable the 2nd UART port */
> > >>> *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;
> > >>> }
> > >>>
> > >>>
> > >>>I had to ifdef-out the assignment statement above. It appears that the
> > >>>definition for BCSR_ADDR in the kernel code differs from what U-Boot is
> > >>>using, and that area of memory isn't properly mapped into the kernel
> > >>>address space this early in the boot sequence. As a result, I was
> > >>>getting an Oops() before the console was even enabled (I could see the
> > >>>Oops message by examining the kernel's printk log buffer using a
> > >>>BDI-2000 hardware debugger).
> > >>>
> > >>>
> > >>>
> > >>>Good luck,
> > >>>
> > >>>Walt Wimer
> > >>>TimeSys Corporation
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>On Sun, 2005-03-27 at 11:31 +0200, Mike Rapoport wrote:
> > >>>
> > >>>
> > >>>>Hi,
> > >>>>I'm trying to bring up the Linux 2.6.11 on MPC8272ADS and it seem to
> > >>>>hang up at the very beginning.
> > >>>>I use ads8272_defconfig and then enable console on SCC:
> > >>>>
> > >>>>CONFIG_SERIAL_CPM=y
> > >>>>CONFIG_SERIAL_CPM_CONSOLE=y
> > >>>>CONFIG_SERIAL_CPM_SCC1=y
> > >>>>
> > >>>>
> > >>>>when I boot the kernel from the u-boot the system hangs up right after
> > >>>>the kernel decompression.
> > >>>>
> > >>>>
> > >>>>
> > >>>_______________________________________________
> > >>>Linuxppc-embedded mailing list
> > >>>Linuxppc-embedded@ozlabs.org
> > >>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >>>
> > >>>
> > >
> > >
> > >
> > >
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms including Redwood5
From: Eugene Surovegin @ 2005-03-31 1:07 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-embedded
In-Reply-To: <20050331000521.GA22041@xyzzy>
On Wed, Mar 30, 2005 at 05:05:21PM -0700, Dale Farnsworth wrote:
[snip]
> +/* Power up the USB subsection */
> +static int enable_usb(struct platform_device *pdev)
> +{
> + u32 mask;
> +
> + mask = 1 << (31 - USB0_IRQ);
> + mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
> + mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) & ~mask);
> + return 0;
> +}
> +
> +/* Power down the USB subsection */
> +static void disable_usb(struct platform_device *pdev)
> +{
> + u32 mask;
> +
> + mask = 1 << (31 - USB0_IRQ);
> + mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) & ~mask);
> + mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) | mask);
> +}
Dale, I'm curious, what's going on here :) ?.
How changing polarity and triggering setting could power-down USB
unit? Some STB funkiness?
--
Eugene
^ permalink raw reply
* [PATCH 2.6.10-rc2] ppc32: Call redwood5_platform_add_devices before driver init
From: Dale Farnsworth @ 2005-03-31 0:10 UTC (permalink / raw)
To: linuxppc-embedded
Use arch_initcall to call redwood5_platform_add_devices, ensuring
that platform_add_devices is called before drivers are initialized.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/redwood5.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/redwood5.c
@@ -48,6 +48,7 @@
{
return platform_add_devices(redwood5_devs, ARRAY_SIZE(redwood5_devs));
}
+arch_initcall(redwood5_platform_add_devices);
void __init
redwood5_setup_arch(void)
@@ -76,7 +77,6 @@
printk("\n");
#endif
- device_initcall(redwood5_platform_add_devices);
}
void __init
^ permalink raw reply
* [PATCH 2.6.10-rc2] ppc32: Add usb support to IBM stb04xxx platforms including Redwood5
From: Dale Farnsworth @ 2005-03-31 0:05 UTC (permalink / raw)
To: linuxppc-embedded
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.c
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.c
@@ -11,6 +11,7 @@
#include <linux/init.h>
#include <asm/ocp.h>
+#include <asm/usb.h>
#include <platforms/4xx/ibmstb4.h>
static struct ocp_func_iic_data ibmstb4_iic0_def = {
@@ -72,12 +73,70 @@
.irq = IDE0_IRQ,
.pm = OCP_CPM_NA,
},
- { .vendor = OCP_VENDOR_IBM,
- .function = OCP_FUNC_USB,
- .paddr = USB0_BASE,
- .irq = USB0_IRQ,
- .pm = OCP_CPM_NA,
- },
{ .vendor = OCP_VENDOR_INVALID,
}
};
+
+/* Power up the USB subsection */
+static int enable_usb(struct platform_device *pdev)
+{
+ u32 mask;
+
+ mask = 1 << (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) | mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) & ~mask);
+ return 0;
+}
+
+/* Power down the USB subsection */
+static void disable_usb(struct platform_device *pdev)
+{
+ u32 mask;
+
+ mask = 1 << (31 - USB0_IRQ);
+ mtdcr(DCRN_UIC_PR(UIC0), mfdcr(DCRN_UIC_PR(UIC0)) & ~mask);
+ mtdcr(DCRN_UIC_TR(UIC0), mfdcr(DCRN_UIC_TR(UIC0)) | mask);
+}
+
+static struct usb_hcd_platform_data pd = {
+ .start = enable_usb,
+ .stop = disable_usb,
+};
+
+static struct resource ohci_usb_resources[] = {
+ [0] = {
+ .start = USB0_BASE,
+ .end = USB0_BASE + USB0_SIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = USB0_IRQ,
+ .end = USB0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 dma_mask = 0xffffffffULL;
+
+static struct platform_device ohci_usb_device = {
+ .name = "ppc-soc-ohci",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(ohci_usb_resources),
+ .resource = ohci_usb_resources,
+ .dev = {
+ .dma_mask = &dma_mask,
+ .coherent_dma_mask = 0xffffffffULL,
+ .platform_data = &pd,
+ }
+};
+
+static struct platform_device *ibmstb4_devs[] __initdata = {
+ &ohci_usb_device,
+};
+
+static int __init
+ibmstb4_platform_add_devices(void)
+{
+ return platform_add_devices(ibmstb4_devs, ARRAY_SIZE(ibmstb4_devs));
+}
+arch_initcall(ibmstb4_platform_add_devices);
Index: linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
===================================================================
--- linux-2.5-usb-405.orig/arch/ppc/platforms/4xx/ibmstb4.h
+++ linux-2.5-usb-405/arch/ppc/platforms/4xx/ibmstb4.h
@@ -73,9 +73,9 @@
#define OPB0_BASE 0x40000000
#define GPIO0_BASE 0x40060000
+#define USB0_BASE 0x40010000
+#define USB0_SIZE 0xA0
#define USB0_IRQ 18
-#define USB0_BASE STB04xxx_MAP_IO_ADDR(0x40010000)
-#define USB0_EXTENT 4096
#define IIC_NUMS 2
#define UART_NUMS 3
Index: linux-2.5-usb-405/include/asm-ppc/usb.h
===================================================================
--- /dev/null
+++ linux-2.5-usb-405/include/asm-ppc/usb.h
@@ -0,0 +1,14 @@
+/*
+ * ppc/usb.h:
+ *
+ */
+#ifndef _PPC_USB_H
+#define _PPC_USB_H
+
+struct usb_hcd_platform_data {
+ char *name;
+ int (*start) (struct platform_device *pdev);
+ void (*stop) (struct platform_device *pdev);
+};
+
+#endif /* !(_PPC_USB_H) */
^ 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