Disabling data cache
On Tue, Apr 01, 2003 at 05:34:34PM -0800, kas turi wrote: > > Hi > We have a custom made board and we are running 8250 > processor. We are using DMA to transmit and receive > data between peripheral and memory. The data is > getting corrupted while transmitting and receiving. We > are suspecting it might be due to data cache being > enabled. So I disabled data cache in the routine > enable_cache in the file arch/ppc/kernel/head.S. I > rebuilt the kernel and when I run on my board it hangs > after printing "Now booting the kernel". I would like > to know why the kernel is not booting up. I have > enclosed the console output: Sure, you are hitting a number of places in early init where the kernel uses dcbz. You need to "fix" those areas and hack the BAT setting to cache inhibit the DBATs that map lowmem. If you search the list archives, I recall an old email describing what somebody did in detail to run with dcache disabled on a classic PPC core. Regards, -- Matt Porter porter at cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux support for MPC859T processor
Honestly, I don't know my guess is close to non to a small handful... But I am truely a novice when it comes to CPU/board bringup.. (I've assisted in it, but my expertise and history is in userspace development.) The things that can take massive amounts of time on these new processors/boards are hardware bugs (cpu and board) as well as device drivers for new on chip devices. I have seen more then one engineer going bald due to hardware bugs, especially a board that the customer said "But it runs VxWorks, why doesn't it run Linux?"... --Mark Dmytro Bablinyuk wrote: > Not a lot of our people experienced in PPC assembler (including myself). > Actually not a lot experienced with PPC at all. > Roughly, from your point of you, how major changes in the kernel could > be? Just your subjective opinion. > >> On userspace basis.. the 860 and the 859 are fully compatable.. The >> need for >> 859T changes may be in the kernel. So anyone who sells/supports an >> 860 based >> system can support your needs for application level. (That includes >> MontaVista.) >> >> The linux kernel of course is a different level of complexity. >> >>> We are trying to find a linux supplier who supports Motorola MPC859T >>> processor (actually it will be processor from Motorola but our custom >>> board). >> >> > > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Linux support for MPC859T processor
On userspace basis.. the 860 and the 859 are fully compatable.. The need for 859T changes may be in the kernel. So anyone who sells/supports an 860 based system can support your needs for application level. (That includes MontaVista.) The linux kernel of course is a different level of complexity. --Mark Dmytro Bablinyuk wrote: > > We are trying to find a linux supplier who supports Motorola MPC859T > processor (actually it will be processor from Motorola but our custom > board). > We have contacted MontaVista and we discovered that the nearest > processor they support is MPC860. > Also we discovered that: > > An MPC860 based board might be suitable for initial S/W development > purposes as the chip is very similar to the MPC859T we intend to use. > There are 7 variants of the '860 with different cache sizes and serial > communications capabilities. > The main differences between the '860 and the '859T that I am aware of are: > > 1.The '860 runs at approximately half the speed of the '859T. > 2.The clocking generator for the 860 would require a different > configuration to the the '859 as a consequence of above. > 3.The '860 has an internal RTC function whereas the '859T does not. > 4.The '859T has a dedicated 10/100Mbps ethernet MAC whereas the '860 > has to use the serial communication controllers for ethernet operations. > The available ethernet speeds depend on the particular variant of the '860. > Note some of the '860 variants include a dedicated 10/100Mbps ethernet MAC. > 5. The '859T core operates off a lower voltage (1.8V) for power > saving whereas the '860 core runs off a 3.3V supply. > Consequently the '860 draws approximately 2x the power of the '859T. > > Apart from the differing core voltages the '860 and '859T appear to be > pin compatible > > * Could somebody please give me an advice on how much S/W work might be > involved in the future to port linux from '860 to '859T based on 1-5 > (see above) > > * Can you suggest (based on above) any of 7 variants of the '860 > > Thank you > > > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
kernel hangs after printing "Calibrating delay loop ..." on mpc860
> Joakim Tjernlund wrote: > > > Every now and then my kernel gets stuck after printing "Calibrating delay > > loop ..." > > and I have to press the reset button to recover. > > > Someone else has experienced this on a 8260 board. This board did not have > > a RTC > > and the fix was to add a set_tb(0,0) early in > > arch/ppc/kernel/time.c/time_init > > The RTC is only used to keep track of time of day. It plays no role in > calibrating or timing anything. The time_init function makes an attempt > to synchronize the RTC second boundary with the decrementer. > > > Our board has a RTC but it gets initialized very late(after the Calibrating > > delay loop stuff). > > Then you are likely to simply see the "Warning: real time clock seems stuck!" > message early in setup. Nope, I set the ppc_md.get_rtc_time to NULL. > > > Either one of us can't understand why this would fix the problem and since > > I can't > > repeat the problem at will I can't verify if a set_tb(0,0) will fix > > anything. > > We also do this on 4xx. > > > Can anybody explain why(or why not) a set_tb(0,0) will make a difference? > > I think the problem is the function tb_delta() returns an 'int', while > the rest of the arithmetic is unsigned. If you happen to get the tbl to > wrap before you get the first decrementer interrupt, I suspect the arithmetic > in these functions goes awry. The 'set_tb()' ensures the tbl doesn't wrap > around. OK, thanks for the explanation. I guess this could happen to anyone then(regardless if RTC is there or not)? Me thinks it's a good idea to do a set_tb(0,0) for 8xx also. > > > -- Dan > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Disabling data cache
Hi We have a custom made board and we are running 8250 processor. We are using DMA to transmit and receive data between peripheral and memory. The data is getting corrupted while transmitting and receiving. We are suspecting it might be due to data cache being enabled. So I disabled data cache in the routine enable_cache in the file arch/ppc/kernel/head.S. I rebuilt the kernel and when I run on my board it hangs after printing "Now booting the kernel". I would like to know why the kernel is not booting up. I have enclosed the console output: Transfering control to linux (at address 00400040) loaded at : 00400040 0040b340 relocated to : 0040 0040b300 board data at: 007FFE40 007FFEF8 relocated to: 0040B148 0040B200 image at: 0040B340 004B6026 avail ram:004B7000 0400 Linux/PPC load: console=ttyS0,9600 root=/dev/mtdblock/1 Uncompressing linux Now booting the kernel Also I would like to understand what is the use of ESE bit in SIUMCR. Should this bit be always enabled whenever data cache is enabled. Any help is appreciated. Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
does in_be32{twi, isync} cause a bus error?
I noticed that in_be32 in 2.4.21 has been changed from 2.4.17 kernel.
In io.h in 2.4.17,
extern inline unsigned in_be32(volatile unsigned *addr)
{
unsigned ret;
__asm__ __volatile__("lwz%U1%X1 %0,%1; eieio" : "=r" (ret) : "m" (*addr));
return ret;
}
whereas io.h in 2.4.21 is,
extern inline unsigned in_be32(volatile unsigned *addr)
{
unsigned ret;
__asm__ __volatile__("lwz%U1%X1 %0,%1;\n"
"twi 0,%0,0;\n"
"isync" : "=r" (ret) : "m" (*addr));
return ret;
}
and with this in_be32, I get "data machine check in kernel mode" and the kernel
oops sending "SIGBUS" to the process.
Oops: machine check, sig: 7
NIP: C500A0A4 XER: LR: C500A090 SP: C39B7EE0 REGS: c39b7e30 TRAP: 0200
Not tainted
MSR: 9030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c39b6000[111] 'a.out' Last syscall: 3
last math last altivec
PLB0: bear= 0x acr= 0x besr= 0x
PLB0 to OPB: bear= 0x4006 besr0= 0x03c0 besr1= 0x
GPR00: C500A090 C39B7EE0 C39B6000 0056 1030 0001 0030 C019
GPR08: 22DC C501 C500D000 48000868 10019824
GPR16: 9032 039B7F40 C00049B0
GPR24: C0004720 10001240 3002A7CC 0FFEA818 7D28 0004 7D28 05050505
Call backtrace:
C500A090 C500A1F0 C0038BAC C000477C 1A38 100010F0 0FED5FDC
can someone explain me why this change was made and suggest me what I should do
to work around this problem? ("don't use 'in_be32', just dereference the
pointer and eieio")
any help would be GREATLY appreciated...
Q-ha Park
- Original Message -
From: "Q-ha Park" <[EMAIL PROTECTED]>
To:
Sent: Friday, March 21, 2003 12:48 PM
Subject: kernel oops when trying to read/write the ioremapped GPIO address.
>
> Hi,
> I have a 405 based custom board (STB04), and I've been using the
> 2.4.17-mvl21 kernel that came with mvista
> preview kit.
>
> I wrote a gpio driver that gives userland apps to control gpio ports. (no, i
> didn't use the IBM OCP gpio driver) It
> simply ioremaps the gpio's physical address and read and write registers by
> calling in_be32, out_be32. is this
> something i shouldn't do? anyways, it worked well with 2.4.17 kernel.
>
> however, with the kernel version 2.4.21-pre4, it oops on calling in_be32 or
> out_be32. the same once happened with
> the kernel 2.4.2 that also came with the monta vista preview kit.
>
> right before the kernel oops, it gives a message, "Data machine check in
> kernel mode", which i didn't see before.
> and NIP is at ">>NIP; c300a0a4 <[gpio_driver-dbg]__module_license+38/13c>"
> after examining the output of ksymoops. i
> don't know why it's at "__module_license"
>
> not only that this driver doens't work, also a couple of other drivers (not
> all) don't work (causing oops) anymore
> after the kernel is upgraded to 2.4.21-pre4 from 2.4.17. it's funny that
> other drivers that failed to be insmoded
> are failed at __module_license..
>
> hmmm, i'm clueless as to why this happens.. can someone help me with this?
>
> your help would be greatly appreciated.
>
> thanks in advance.
>
>
> Q-ha Park
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
kernel hangs after printing "Calibrating delay loop ..." on mpc860
Hi List Every now and then my kernel gets stuck after printing "Calibrating delay loop ..." and I have to press the reset button to recover. Someone else has experienced this on a 8260 board. This board did not have a RTC and the fix was to add a set_tb(0,0) early in arch/ppc/kernel/time.c/time_init Our board has a RTC but it gets initialized very late(after the Calibrating delay loop stuff). Either one of us can't understand why this would fix the problem and since I can't repeat the problem at will I can't verify if a set_tb(0,0) will fix anything. Can anybody explain why(or why not) a set_tb(0,0) will make a difference? Kernel is linuxppc_dev, 2.4.20 Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ibm_ocp_enet.c
On Tue, Apr 01, 2003 at 01:33:36PM -0800, Khai Trinh wrote: > > Hi folks, > > I am reading through the PPC ethernet driver source > trying to locate the receive routine a ethernet > packets from the PHY. All I saw was the > ppc405_enet_start_xmit(). Where is the receive one? > > Would someone knowledgable in PPC ethernet driver give > me a pointer or two? ppc405_eth_rxeob() -> ppc405_rx_clean() -- Matt Porter porter at cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ibm_ocp_enet.c
Hi folks, I am reading through the PPC ethernet driver source trying to locate the receive routine a ethernet packets from the PHY. All I saw was the ppc405_enet_start_xmit(). Where is the receive one? Would someone knowledgable in PPC ethernet driver give me a pointer or two? Thanks, --Khai Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
kernel hangs after printing "Calibrating delay loop ..." on mpc860
Joakim Tjernlund wrote: > Every now and then my kernel gets stuck after printing "Calibrating delay > loop ..." > and I have to press the reset button to recover. > Someone else has experienced this on a 8260 board. This board did not have a > RTC > and the fix was to add a set_tb(0,0) early in arch/ppc/kernel/time.c/time_init The RTC is only used to keep track of time of day. It plays no role in calibrating or timing anything. The time_init function makes an attempt to synchronize the RTC second boundary with the decrementer. > Our board has a RTC but it gets initialized very late(after the Calibrating > delay loop stuff). Then you are likely to simply see the "Warning: real time clock seems stuck!" message early in setup. > Either one of us can't understand why this would fix the problem and since I > can't > repeat the problem at will I can't verify if a set_tb(0,0) will fix anything. We also do this on 4xx. > Can anybody explain why(or why not) a set_tb(0,0) will make a difference? I think the problem is the function tb_delta() returns an 'int', while the rest of the arithmetic is unsigned. If you happen to get the tbl to wrap before you get the first decrementer interrupt, I suspect the arithmetic in these functions goes awry. The 'set_tb()' ensures the tbl doesn't wrap around. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
dcbz works on 862 everywhere!
> The current implementation relies on TLB Miss always setting EPN > (and other hardware assist registers) correctly, and TLB Error > relies on DAR being set correctly. Everything works fine until > you get a TLB Error on a dcbz/dcbt that doesn't properly update DAR. > In this case EPN isn't set correctly either. I just want to point out(again) that TLB Miss caused by most of the dcxx(dcbf, dcbi, dcbst, dcbz) instructions that end up in the slow path(DataAccess) don't work with the current impl. since DAR isn't set. The code fragment below will fix that(from my earlier patch). This won't affect the fast path at all since it all of it can be in the slow path. + /* Copy 20 msb from EPN to DAR since the dcxx instructions fails +* update the DAR when they cause a DTLB Miss. +*/ + mfspr r21, MD_EPN + rlwinm r21, r21, 0, 0, 19 + mfspr r20, DAR + rlwinm r20, r20, 0, 20, 31 + or r20, r20, r21 + mtspr DAR, r20 It is hard to end up in slow path for kernel space addresses, but it's not impossible I guess. Comments? Jocke ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
powerpc-elf compiler build errors
Hi! I want to make a cross toolchain for powerpc-elf target,but encounter some errors. My host is cygwin on windows2000. My directory hierarchy: /src--binutils |--gcc |--newlib-1.9.0 |--build-binutils |--build-gcc |--build-newlib |--install My steps: 1. export TARGET=powerpc-elf export PREFIX=/src/install export PATH=$PREFIX/bin:$PATH 2. cd build-binutils $ ../binutils/binutils-2.11.2/configure --target=$TARGET --prefix=$PREFIX $ make all install 2>&1 | tee make.log $ cd .. 3. cd build-gcc ../gcc/gcc-2.95.3/configure --target=$TARGET --prefix=$PREFIX \ --with-newlib --without-headers --with-gnu-as \ --with-gnu-ld --disable-shared --enable-languages=c make all-gcc install-gcc 2>&1 | tee make.log cd .. 4. cd build-newlib ../newlib-1.9.0/configure --target=$TARGET --prefix=$PREFIX make all install 2>&1 | tee make.log cd .. 5. cd build-gcc && rm -rf * ../gcc/gcc-2.95.3/configure --target=$TARGET --prefix=$PREFIX \ --with-gnu-as --with-gnu-ld --enable-languages=c,c++ make all install 2>&1 | tee make.log The result: /src/build-gcc/gcc/xgcc -B/src/build-gcc/gcc/ -B/src/install//powerpc-elf/bin/ -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../gcc/gcc-2.95.2/libiberty/../include ../../../gcc/gcc-2.95.2/libiberty/vsprintf.c -o pic/vsprintf.o /src/build-gcc/gcc/xgcc -B/src/build-gcc/gcc/ -B/src/install//powerpc-elf/bin/ -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../gcc/gcc-2.95.2/libiberty/../include ../../../gcc/gcc-2.95.2/libiberty/vsprintf.c ../../../gcc/gcc-2.95.2/libiberty/vsprintf.c: In function `vsprintf': ../../../gcc/gcc-2.95.2/libiberty/vsprintf.c:47: structure has no member named `_flag' ../../../gcc/gcc-2.95.2/libiberty/vsprintf.c:47: `_IOWRT' undeclared (first use in this function) ../../../gcc/gcc-2.95.2/libiberty/vsprintf.c:47: (Each undeclared identifier is reported only once ../../../gcc/gcc-2.95.2/libiberty/vsprintf.c:47: for each function it appears in.) ../../../gcc/gcc-2.95.2/libiberty/vsprintf.c:47: `_IOSTRG' undeclared (first use in this function) ../../../gcc/gcc-2.95.2/libiberty/vsprintf.c:48: structure has no member named `_ptr' ../../../gcc/gcc-2.95.2/libiberty/vsprintf.c:49: structure has no member named `_cnt' make[1]: *** [vsprintf.o] Error 1 make[1]: Leaving directory `/src/build-gcc/powerpc-elf/libiberty' make: *** [all-target-libiberty] Error 2 I have found some clues to attack the error information at your CrossGCC Faq, which says the following: " When building for powerpc-eabi, the complete gcc build step will fail due to a reported error building libiberty. To finish building gcc, do this after the failure: $ make CFLAGS="-O2 -myellowknife" install 2>&1 | tee make2.log The problem here is that the powerpc-eabi crosscompiler doesn't come with a "default" build target, the way other versions of gcc do. By selecting ?\myellowknife, we tell gcc to use the yellowknife target's linker scripts during building. This doesn't affect anything in the end, because the step that fails is merely testing that the compiler works?? without the ?\m, it won't. " But when I try the above method, the make says cannot find the "-myelloknife" option. I think the reason maybe it is for powerpc-eabi only. What's wrong on earth with my steps? Any recommendation will be much appreciated! thanks in advance! __ === ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
