8272ADS and Linux 2.6.12
Hello, We have a MPC8272 Eval Board which came with Linux 2.4 and U-boot. We wanted to move to 2.6. I downloaded the latest 2.6.12 sources and compiled the sources for this platform. The kernel is built, have run the mkimage tool, but the kernel wont boot. It just hangs after decompressing the image. Any ideas ? Anything different that needs to be done for 2.6 ? Or any known issues ? Thanks! ashutosh
mpc8xx and ld.so problem
Wolfgang Denk schreef: >In message <42D5361B.2070402 at chello.nl> you wrote: > > >>It appeard that on my mpc862 target I had also this problem. I am using >>ELDK3.1.1 which includes a 2.4.25 kernel. >> >> > >No, most definitely not. > > > I don't understand this, on /pub/Linux/distributions/eldk/3.1.1/ppc-linux-x86/distribution/common there are the sources of a 2.4.25 kernel. >>Large application (20MB c++, mostly shared-libs) crashes (sigseg) at >>startup BEFORE main() is called. >>Attempts to debug the application also fail: the debugger crashes >>also (sigseg). >> >> > >I bet that this is a FAQ. Your SDRAM initialization is broken. > > This was one of my guesses also. Since this is beyond my knowledge, I had the parametes initialisation parameters compared to an other platform which did not had the problems (rtos based), the same parameters were used. I did not investigate it any further. > > >>I didn't change the C-lib, I took the 2.4.30/arch/ppc/kernel/head_8xx.S >>file and copied this over the 2.4.25 head_8xx.S file. >>In the 2.4.30 version there is a piece of code mentioning the dcbX >>instruction problems. >> >> > >And did this fix the problem completely? I would be a bit surprised. > > > No problem since. >>This driver causes the CPM sometimes to hang when performing a memset, >>can this be caused by the same problem? >> >> > >Yes. When your SDRAM init is broken, strange things will happen. > > > I'll try the kernel with the original atm/utopia to see what happens. >Best regards, > >Wolfgang Denk > > > Thanks, Theo Gjaltema.
linux and sram
In message <20050713153231.GA17534 at mail19d.g19.rapidsite.net> you wrote: > > If we are using U-boot and populate the CFG_SRAM_SIZE and CFG_SRAM_BASE > values, and makes sure this is passed into the kernel. > > Does Linux 2.4.2x+ have any direct support for this? Is it just added into > the regular memory pool? Does it get used for specific tasks? The standard Linux kernel knows nothing about SRAM. > Or is this set aside for custom drivers? Indeed. You need a driver to support SRAM. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Microsoft Multimedia: You have nice graphics, sound and animations when the system crashes.
mpc8xx and ld.so problem
In message <42D5361B.2070402 at chello.nl> you wrote: > > It appeard that on my mpc862 target I had also this problem. I am using > ELDK3.1.1 which includes a 2.4.25 kernel. No, most definitely not. > Large application (20MB c++, mostly shared-libs) crashes (sigseg) at > startup BEFORE main() is called. > Attempts to debug the application also fail: the debugger crashes > also (sigseg). I bet that this is a FAQ. Your SDRAM initialization is broken. > I didn't change the C-lib, I took the 2.4.30/arch/ppc/kernel/head_8xx.S > file and copied this over the 2.4.25 head_8xx.S file. > In the 2.4.30 version there is a piece of code mentioning the dcbX > instruction problems. And did this fix the problem completely? I would be a bit surprised. > This driver causes the CPM sometimes to hang when performing a memset, > can this be caused by the same problem? Yes. When your SDRAM init is broken, strange things will happen. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Work 8 hours, sleep 8 hours; but not the same 8 hours.
UART problem on MPC8272ADS
Hi! Do anyone have 2-nd UART port working on MPC8272ADS? The target boots OK via both UARTs as console, but any attempt to transmit/receive data via the other port have failed. A quick lookup results that ...init_scc is called only in `console` case. After addition of this call to the cpm_uart_startup (just for instance) transmit from the target occur, but with only half of data. I tried various pin settings including working combinations from the old uart driver but with the same result. I guess that 8xx that are also handled by this driver may behave likewise, so any information whether cpm_uart driver works well (or not) on 8xx is also valuable. Any ideas how to solve this or concerning possible reasons of such behavior are greatly appreciated. -- Sincerely, Vitaly
double kernel page table entry for the same physical page?!
Dan, No one intents to make memory corruption in kernel space but it happens sometimes. Say I have a global var in my kernel module which called test-mod, it picks up a physical page allocated by some code with kmalloc and later kfreed(suppose when it does, the whole page gets freed). But then this code forgets a pointer(which maped to this physical page) already freed and modifies the pointer, the write gets thru since that virt address's PTE still valid and points to the physical page currently used by test-mod. So the memory corruption happens. Maybe I miss something in the linux kernel code that prevents this double PTE thing. Ming --- Dan Malek wrote: > > On Jul 13, 2005, at 2:48 PM, ming lei wrote: > > > Why linux kernel does such thing and no one > consider > > it's a problem? > > Because we don't write software that accesses the > memory > from both of those locations, unless it is very > intentional > and necessary. If you are just fishing for ways > software > _could_ do bad things, there are tons of them. It's > our > job to write it so it doesn't :-) > > Thanks. > > > -- Dan > > __ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
mpc8xx and ld.so problem
Hi, It appeard that on my mpc862 target I had also this problem. I am using ELDK3.1.1 which includes a 2.4.25 kernel. The symptoms however were: Large application (20MB c++, mostly shared-libs) crashes (sigseg) at startup BEFORE main() is called. Attempts to debug the application also fail: the debugger crashes also (sigseg). I didn't change the C-lib, I took the 2.4.30/arch/ppc/kernel/head_8xx.S file and copied this over the 2.4.25 head_8xx.S file. In the 2.4.30 version there is a piece of code mentioning the dcbX instruction problems. Has anyone an idea why only this large application failed? busybox_1.0 and more applications work fine. system is a: mcp862/32Mb SDRAM started from u-boot 0.4.1, kernel enhanced with atm/utopia driver. This driver causes the CPM sometimes to hang when performing a memset, can this be caused by the same problem? (CPM stops responding, console buffers are not flused anymore and kernel stops waiting for buffers) Greetings, Theo Gjaltema Yuli Barcohen schreef: >>Marcelo Tosatti writes: >> >> > >Yuli> [...deleted...] > >Jason> Ha. Funny. The glibc powerpc maintainer doesn't want any >Jason> embedded fixes in the mainline. Last I checked, that was for >Jason> 'the tools vendors' to fix. > >Jason> "We won't work around processor bugs" is their philosophy. > >Yuli> [...deleted...] > >Yuli> I investigated the problem a bit when I had trouble with a >Yuli> self-compiled glibc a year or so ago. IIRC, I found bug in the >Yuli> memset code, not in the chip. The code was just wrong for >Yuli> cache line sizes not equal to 32. So memset.S is good for 60x >Yuli> series (PQII included) but for 8xx it fails. > >Marcelo> I suppose you didnt actually use dcbz for userspace memset >Marcelo> on 8xx? > >Standard glibc did. After the fix, it doesn't do it any more on our >systems. > >Yuli> We use dcbX instructions in some kernel drivers and since we >Yuli> never had any problems with those drivers I'm a bit surprised >Yuli> to hear that all 8xx chips have got that bug. > >Marcelo> The problem is that the DAR register is correctly unset (it >Marcelo> comes as NULL IIRC) on pagefaults for the dcbz >Marcelo> instruction. The dcbz instructions you issue are probably >Marcelo> always works on kernel addresses whose pagetables are >Marcelo> present? > >It's not dcbz, it's dcbi/dcbf. And yes, they work on kernel addresses. I >never investigated if the page tables are present or not because there >were no problems. > >Marcelo> Joakim has developed a workaround for the >Marcelo> problem... although I promised him several times to test it >Marcelo> I never managed to get dcbz to work on the kernel copying >Marcelo> functions. :( > >[...patch deleted...] > >Well, if I manage to find time, I'll try it. No timetables though. I'm >not sure if using dcbz in user-space memset is such a great >optimisation. It well can be an example of over-engineering. > > >
double kernel page table entry for the same physical page?!
On Jul 13, 2005, at 2:48 PM, ming lei wrote: > Why linux kernel does such thing and no one consider > it's a problem? Because we don't write software that accesses the memory from both of those locations, unless it is very intentional and necessary. If you are just fishing for ways software _could_ do bad things, there are tons of them. It's our job to write it so it doesn't :-) Thanks. -- Dan
double kernel page table entry for the same physical page?!
I am worried about memory corruption if there are two PTE entries point to the same physical page. Considering this case: vmalloc a page to a virt address V1 and somehow other code uses V0(which is in identy mapping) to modify the same physical page. I checked i386 and looks like they have the same problem. Why linux kernel does such thing and no one consider it's a problem? Thanks Ming --- Dan Malek wrote: > > On Jul 13, 2005, at 1:10 PM, ming lei wrote: > > > Question: does the linux ever touch this section > of > > page table(virt address from PAGE_OFFSET to > > PAGE_OFFSET+A) again? like remove or modify one of > the > > entry? > > Not usually. We used to do it on 8xx for mapping > uncached pages for coherent DMA. > > > Question: For every physical page, it should > already > > be mapped in #1, but vmalloc maps it again to a > virt > > address higher. Does it mean in kernel page table, > we > > may have two PTE entries pointing to the same > physical > > page, even their virt addresses are different? > > Yep. > > > Last question: > > If this is true, is this platform implemention > > specific? Does i386 implemention have same > situation? > > Other architectures will do the same, yes. The > level to which they do this will vary depending upon > architectural features we have to hide/expose to > other functions. > > One potential problem that arises is you have to be > careful about the virtual address access path to > these > pages. All processors will behave errantly if you > access the same physical page, but with different > attributes, through the different VAs. How they > behave > will depend upon the attributes. If the PTEs have > different cache modes or page sizes, it's usually > a big problem. If they just share different write > permissions, it's usually OK. These problems > usually > arise when device driver writers either don't > understand > the mapping issues or try something that may work > on one architecture but not on another. > > > -- Dan > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
double kernel page table entry for the same physical page?!
On Jul 13, 2005, at 1:10 PM, ming lei wrote: > Question: does the linux ever touch this section of > page table(virt address from PAGE_OFFSET to > PAGE_OFFSET+A) again? like remove or modify one of the > entry? Not usually. We used to do it on 8xx for mapping uncached pages for coherent DMA. > Question: For every physical page, it should already > be mapped in #1, but vmalloc maps it again to a virt > address higher. Does it mean in kernel page table, we > may have two PTE entries pointing to the same physical > page, even their virt addresses are different? Yep. > Last question: > If this is true, is this platform implemention > specific? Does i386 implemention have same situation? Other architectures will do the same, yes. The level to which they do this will vary depending upon architectural features we have to hide/expose to other functions. One potential problem that arises is you have to be careful about the virtual address access path to these pages. All processors will behave errantly if you access the same physical page, but with different attributes, through the different VAs. How they behave will depend upon the attributes. If the PTEs have different cache modes or page sizes, it's usually a big problem. If they just share different write permissions, it's usually OK. These problems usually arise when device driver writers either don't understand the mapping issues or try something that may work on one architecture but not on another. -- Dan
UART problem on MPC8272ADS
On Wed, Jul 13, 2005 at 10:05:23PM +0400, Vitaly Bordug wrote: > Hi! > Do anyone have 2-nd UART port working on MPC8272ADS? > > The target boots OK via both UARTs as console, but any attempt to > transmit/receive data via the other port have failed. > A quick lookup results that ...init_scc is called only in `console` > case. After addition of this call to the cpm_uart_startup (just for > instance) transmit from the target occur, but with only half of data. I > tried various pin settings including working combinations from the old > uart driver but with the same result. > > I guess that 8xx that are also handled by this driver may behave > likewise, so any information whether cpm_uart driver works well (or > not) on 8xx is also valuable. > > Any ideas how to solve this or concerning possible reasons of such > behavior are greatly appreciated. I had some problems with multiple UARTs (SMC and SCC) on 8248-based custom board. It was due to completely brain-damaged BRG allocation in cpm2_io/uart.c. I had to hack it to make SCC UART working along with SMC one. -- Eugene
double kernel page table entry for the same physical page?!
1. In PPC MMU_init sets up kernel page table for all the physical pages available(say size is A) to the virt address starting from PAGE_OFFSET to (PAGE_OFFSET+A). Question: does the linux ever touch this section of page table(virt address from PAGE_OFFSET to PAGE_OFFSET+A) again? like remove or modify one of the entry? 2. In VMALLOC, say we have virt address B(B>PAGE_OFFSET+A), sets up the page table entry for this B to any one of the physical pages. Question: For every physical page, it should already be mapped in #1, but vmalloc maps it again to a virt address higher. Does it mean in kernel page table, we may have two PTE entries pointing to the same physical page, even their virt addresses are different? Last question: If this is true, is this platform implemention specific? Does i386 implemention have same situation? Thanks, Ming Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
linux and sram
Everyone, If we are using U-boot and populate the CFG_SRAM_SIZE and CFG_SRAM_BASE values, and makes sure this is passed into the kernel. Does Linux 2.4.2x+ have any direct support for this? Is it just added into the regular memory pool? Does it get used for specific tasks? Or is this set aside for custom drivers? Thanks, Russell McGuire
About MPC8245 software reboot
Hi,all
Most of MPC8245 kernel port are using watchdog reset manner to get software
reboot.
I notice that every implement of whaterverplatform_restart() always enter
dead loop and then wait for WDT reset.. My idea is, if there has possible to
implement a software restart function in kernel. Like Uboot doing reset
command.
Because in my case,the WDT on my customize MPC8245 board has a long timeout
period, about 30 seconds.
So,
I had to try to replace platform_restart() with do_reset() which found in
Uboot.
But I got thease, I guess something wrong in memory map.
sh-2.05a# reboot
INIT: Switching to runlevel: 6
Broadcast message from root (console) Thu Dec 4 00:01:21 2003...
The system is going down for reboot NOW !!
INIT: Sending processes the TERM signal
DEBUG: first run the kill scripts
DEBUG:now run the start scripts
Starting killall: [ OK ]
/etc/rc6.d/S01reboot: enable: kill: not a shell builtin
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Unmounting proc file system:
Please stand by while rebooting the system...
Restarting system.
U-Boot 1.1.2 (Jan 25 2005 - 14:55:00) [svm]
CPU: MPC8245 Revision 1.1 at 299.999 MHz: 16 kB I-Cache 16 kB D-Cache
Board: SVM_SC8245 Local Bus at 99.999 MHz
I2C: ready
DRAM: Scan SDRAM memory
64 MB
Top of RAM usable for U-Boot at: 0400
Reserving 460k for U-Boot at: 03f8c000
Reserving 128k for malloc() at: 03f6c000
Reserving 56 Bytes for Board Info at: 03f6bfc8
Reserving 48 Bytes for Global Data at: 03f6bf98
Stack Pointer at: 03f6bf78
New Stack Pointer is: 03f6bf78
Now running in RAM - U-Boot at: 03f8c000
FLASH: 512 kB
PCI Scan: Found Bus 0, Device 22, Function 0
PCI Config: I/O=0x8000, Memory=0x8000, Command=0x7
00 16 10ec 8139 0200 0b
PCI Scan: Found Bus 0, Device 23, Function 0
PCI Config: I/O=0x8100, Memory=0x8100, Command=0x7
00 17 8086 1209 0200 0c
PCI Scan: Found Bus 0, Device 24, Function 0
00 18 8086 1209 0200 0e
In: serial
Out: serial
Err: serial
U-Boot relocated to 03f8c000
DOC: No DiskOnChip found
Net: Bad trap at PC: fffc, SR: 1000, vector=800
NIP: FFFC XER: LR: 1288 REGS: 03f6bd00 TRAP: 0800 DAR:
MSR: 1000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 0048 03F6BDF0 FF1F 03F6C1E8 0006
01F3F7E0
GPR08: 03FCF1D8 BFFBF000 03FECC8C 000E 10019924 03FF2000
0408C000
GPR16: 9032 0001
C0005E28
GPR24: 03F6BF98 03F6BFC8 0002 0002 03F6C1E8 03F6BF98 03FF2788
03F6C1E8
Call backtrace:
Exception in kernel pc fffc signal 0
Exception in kernel pc fffc signal 0
then Uboot restart again.
U-Boot 1.1.2 (Jan 25 2005 - 14:55:00) [svm]
CPU: MPC8245 Revision 1.1 at 299.999 MHz: 16 kB I-Cache 16 kB D-Cache
Board: SVM_SC8245 Local Bus at 99.999 MHz
..
In the meantime,if I re-power the board,it's running okay. I guess MMU not
fully reset. Platform_restart() maybe needs more jobs to do.
Here is my implement,
static void sc8245_restart(char *cmd){
ulong msr, addr;
/* Interrupts and MMU off */
__asm__ ("mtspr81, 0");
/* Interrupts and MMU off */
__asm__ __volatile__ ("mfmsr%0":"=r" (msr):);
msr &= ~0x1030;
__asm__ __volatile__ ("mtmsr%0"::"r" (msr));
/*
* Trying to execute the next instruction at a non-existing address
* should cause a machine check, resulting in reset
*/
addr = 0xfff00100;
((void (*)(void)) addr) ();
return 1;
}
I do not have idea to get it settle. I knew you guys are very kind,so
,please help.
Thank you in advanced.
--
John Zhan.
help: FCC_ENET OF MPC8250?
Hi, I use a device, like SMARTBITS, to test the Ethernet rate of mpc8250. The kernel is linux-2.4.20 with CONFIG_FCC_LXT971 and CONFIG_USE_MDIO, and do 'cat "1">/proc/sys/net/ipv4/ip_forward'. If the rate of sending IP packet been set too high, for example 100 Mbps Full Duplex and each packet is 1514 Bytes. Later, the kernel print '... Memory squeeze, dropping packet' on uart. Stop sending IP packet and do 'cat /proc/meminfo', the *MemFree* become small. Try again, the *MemFree* become smaller, just look like some allocated memory (skbuf) do not be free. Final, the kernel break down, because all memory have been used. Q. How can I do to let kernel do not break down? Is it a kernel promblem? PS: I use linux-2.6.5 on mpc8250 for the same test, and get the same result. I change some code in file skbuff.c, use a memory pool that I created instead of allocating *skb* from *MemFree*, and do the same test. Final, the kernel can not transmit any IP packet, beacuse all space in the pool been used, but do not break down. Thanks for your reading. e-mail: gqben at sina.com gqbenjamin at 163.com gqbenjamin at 21cn.com -- vgo http://vgo.21cn.com ??4G?? http://mail.21cn.com/huodong/0504/mail/ ??!! http://qipai.g.21cn.com ?? http://super.21cn.com/ ?? http://y.21cn.com/club/ http://pas.21cn.com/ ??2005 http://callme.21cn.com
[PATCH] ppc32: fix destroy_context() race condition
On Tue, 2005-07-12 at 10:23 -0400, Guillaume Autran wrote:
> Fix for a race condition when a task gets preempted by another task
> while executing the destroy_context(...) in a FEW_CONTEXTS environment.
> mm->context == NO_CONTEXT but the context_map may indicate all contexts
> are in use.
> The solution to this problem is to disable kernel preemption while
> destroying a MMU context.
>
> Signed-off-by: Guillaume Autran
Acked-by: Benjamin Herrenschmidt
>
> ---
>
> diff -Nru a/include/asm-ppc/mmu_context.h b/include/asm-ppc/mmu_context.h
> --- a/include/asm-ppc/mmu_context.h 2005-06-17 15:48:29.0 -0400
> +++ b/include/asm-ppc/mmu_context.h 2005-07-05 08:58:46.0 -0400
> @@ -149,6 +149,7 @@
> */
> static inline void destroy_context(struct mm_struct *mm)
> {
> + preempt_disable();
> if (mm->context != NO_CONTEXT) {
> clear_bit(mm->context, context_map);
> mm->context = NO_CONTEXT;
> @@ -156,6 +157,7 @@
> atomic_inc(&nr_free_contexts);
> #endif
> }
> + preempt_enable();
> }
>
> static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
>
>
>
>
>
help: FCC_ENET OF MPC8250?
On Wed, 13 Jul 2005 10:42:52 +0800 (CST) gqbenjamin at 21cn.com wrote: > Hi, > > I use a device, like SMARTBITS, to test the Ethernet rate of mpc8250. The > kernel is linux-2.4.20 > with CONFIG_FCC_LXT971 and CONFIG_USE_MDIO, and do 'cat > "1">/proc/sys/net/ipv4/ip_forward'. > > If the rate of sending IP packet been set too high, for example 100 Mbps Full > Duplex and each > packet is 1514 Bytes. Later, the kernel print '... Memory squeeze, dropping > packet' on uart. Stop > sending IP packet and do 'cat /proc/meminfo', the *MemFree* become small. > > Try again, the *MemFree* become smaller, just look like some allocated memory > (skbuf) do not be > free. > > Final, the kernel break down, because all memory have been used. It sounds to me like the problem may be that fcc_enet_rx() is consuming all the memory. This function is called in interrupt context and spins round the rx buffer descriptor ring until it finds an empty buffer descriptor. There is no check to stop it going round more than once and each time it finds a BD it does a dev_alloc_skb(). It is possible that you are receiving data at a high enough rate that fcc_enet_rx() never exits. What is more likely is that there isn't enough time between rx interrupts for the CPU to tx all the queued packets. > > Q. How can I do to let kernel do not break down? Is it a kernel promblem? > This is just a guess, but... it may help to move fcc_enet_rx() from the interrupt handler to a bottom half. If you do this you should also ensure that it cannot process the rx buffer descriptor ring more than once per call. This may give the CPU *more* chance to tx queued packets by lowering the rx priority a little. I don't know if this would work but I'd be interested to find out. Alex
MPC5200 Rev. B
Does anyone know where to locate the BAPI V2.2. I could only find 2.1 in the current development kernel. Matthew Berry MKS Instruments, Inc. 1321 Rutherford Lane, Suite 200 Austin, Texas 78753 Office: (512) 719-8048 Main: (512) 719-8000 x8048 Cell: (512) 203-7186 Fax: (512) 719-8096
