MPC8xx: resolution of gettimeofday() ?
Eugene, >>> Usually on PPC we use timebase to interpolate time between Decrementer >>> interrupts. In this case gettimeofday resolution is determined by >>> timebase resolution which is quite high (megahertz range). >> Sorry. I don't understand. What do you mean with "timebase"? Is there a >> second timer/counter? > > PowerPC has a facility called timebase. This is 64-bit counter which > can be accessed using special instructions (mftb, mftbu on 32-bit PPC). > Counter resolution depends on particular chip implementation, some > use core clock, other use bus clock... > > It's similar to the time-stamp counter in Intel CPUs (accessed > with rdtsc instruction). Thanks very much for clearing this! > Please, refer to PPC arch manuals for more information. Also, if you > really interested in how gettimeofday() is implemented, why don't you > look at the source code yourself? I tried. But it's not obvious. Not for me anyway. -- Steven
MPC8xx: resolution of gettimeofday() ?
Eugene, >> what is the resolution of gettimeofday() for an MPC8xx? >> >> IIUC then the "decrementer" is used to generate the timer interrupts every >> 10ms. >> >> This decrementer runs at cpuclk/16. Thus with 80MHz CPU clock has a >> resolution of 16/80MHz = 200ns and overflows every 5 ticks. >> >> But is this decrementer used to update xtime? >> Will gettimeofday() have a resolution of 200ns? >> >> How about linux 2.4 where xtime is a "struct timeval" rather then "struct >> timespec"? >> > > Usually on PPC we use timebase to interpolate time between Decrementer > interrupts. In this case gettimeofday resolution is determined by > timebase resolution which is quite high (megahertz range). Sorry. I don't understand. What do you mean with "timebase"? Is there a second timer/counter? -- Steven
MPC8xx: resolution of gettimeofday() ?
Hi all,
what is the resolution of gettimeofday() for an MPC8xx?
IIUC then the "decrementer" is used to generate the timer interrupts every 10ms.
This decrementer runs at cpuclk/16. Thus with 80MHz CPU clock has a
resolution of 16/80MHz = 200ns and overflows every 5 ticks.
But is this decrementer used to update xtime?
Will gettimeofday() have a resolution of 200ns?
How about linux 2.4 where xtime is a "struct timeval" rather then "struct
timespec"?
This trivial test programm
struct timeval first, next;
double diff;
gettimeofday(&first, NULL);
do {
gettimeofday(&next, NULL);
} while (first.tv_usec == next.tv_usec &&
first.tv_sec == next.tv_sec);
diff = ((double) next.tv_sec - (double) first.tv_sec) * 1e6;
diff += (double) (next.tv_usec - first.tv_usec);
printf ("Resolution gettimeofday() = %g ?s\n", diff);
says it's between 13 - 16 ?s on a linux-2.4.20. Could that be? how does this
relate to the decrementer frequency?
Thanks a million!
--
Steven
gdb-6.3 for mpx8xx?
Hi there, has someone successfully built gdb-6.3 for mpx8xx processors? Thanks. -- Steven
Embedded linux port for PowerPC ?
Mukund JB. wrote: > Hello all, > > This is my first visit to the mailists. > > I have assigned to port Embedded Linux to PowerPC Board. > > > > Where do I get the Embedded Linux kernel & Source code for PowerPC? > > Can you provide me with some documents related to porting Embedded Linux > to PowerPC Board? Start reading http://www.denx.de/twiki/bin/view/DULG/Manual and http://penguinppc.org/ -- Steven
linux 2.4.27 for 8xx?
Hi there, is the vanilla kernel 2.4.27 from kernel.org considered stable for MPC8xx systems? Or do I still have to go for the trees on ppc.bkbits.net ? Thanks. -- Steven
ATAG for MAC address???
Wolfgang Denk wrote: > In message <40EA6996.1010402 at imc-berlin.de> you wrote: > >>could we introduce an ATAG_MAC or ATAG_ETH_MAC so we can pass the MAC >>address for the ethernet controller from the boot loader to the linux kernel >>using the ATAG mechanism? >> >>I don't want to pass "MAC=..." as a commandline though. > > > Linux does not use any ATAGs on PowerPC. > > Wrong list? Stupid mail client! Sorry! Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ATAG for MAC address???
Hi there, could we introduce an ATAG_MAC or ATAG_ETH_MAC so we can pass the MAC address for the ethernet controller from the boot loader to the linux kernel using the ATAG mechanism? I don't want to pass "MAC=..." as a commandline though. Thanks! -- Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
problem with queue_task() and mark_bh()...
Hi, >> queue_task( &( lp->task ), &tq_immediate ); >> mark_bh( IMMEDIATE_BH ); I've put some printks in my kernel. Now I can see that the task is successfully queued, that mark_bh() is called and the tasklet_hi_schedule() calls __tasklet_hi_schedule(). But the function immediate_bh() in kernel/timer.c (which should then call run_task_queue(&tq_immediate)) is never called. Any ideas? Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
problem with queue_task() and mark_bh()...
Hi,
I wrote:
> I have a problem with queue_task() and mark_bh().
> ...
> At a later point (namely in the interrupt service rountine this happens:
>
> /* If we have interrupts pending, then put them on a system task queue.*/
> if( events == HCF_INT_PENDING ) {
> /* Schedule the ISR handler as a bottom-half task in the
> * tq_immediate queue
> */
> printk( "Schedule the ISR handler %#lx...\n", lp->task.routine);
>
> queue_task( &( lp->task ), &tq_immediate );
> mark_bh( IMMEDIATE_BH );
> }
>
> The problem is now that the queued task lp->task (i.e. wl_isr_handler)
> never get's called! And thus the driver does not work.
When I call run_task_queue(&tq_immediate) right after mark_bh(IMMEDIATE_BH)
then it works.
But I though "run_task_queue(&tq_immediate)" gets called by the kernel
(after every timer interrupt)...
--
Steven Scholz
imc Measurement & Control imc Me?systeme GmbH
Voltastr. 5 Voltastr. 5
13355 Berlin13355 Berlin
Germany Deutschland
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8xx and wireless HERMES-II () ???
Scott Stickeler wrote: > I'd be very interested in what you find out. I am working on a project where I > want to do the exact same thing. I'll stay tuned :). After fixing some minor bugs the HERMES-II is working with my MPC8xx. I still have some minor problems though. Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
kfree_skb on hard IRQ ???
Steven Scholz wrote: > And what means > > alloc_skb called nonatomically from interrupt c00eb8d0 > kernel BUG at skbuff.c:174! > Oops: Kernel Mode Software FPU Emulation, sig: 8 > NIP: C00E065C XER: LR: C00E065C SP: C016BC80 REGS: c016bbd0 TRAP: > 1000Not tainted > MSR: 1032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 > TASK = c0169fa0[0] 'swapper' Last syscall: 120 > last math last altivec > ... > Kernel panic: Aiee, killing interrupt handler! > In interrupt handler - not syncing > <0>Rebooting in 10 seconds.. BTW the backtrace shows 0xc00dd374 -- 0xc00dd2f4 + 0x0080 alloc_skb 0xc00e85e8 -- 0xc00e85c0 + 0x0028 rtmsg_ifinfo 0xc00e8bb4 -- 0xc00e8b50 + 0x0064 rtnetlink_event 0xc001c200 -- 0xc001c1c0 + 0x0040 notifier_call_chain 0xc00e1668 -- 0xc00e15b0 + 0x00b8 dev_close 0xc00e3b84 -- 0xc00e3b60 + 0x0024 unregister_netdevice 0xc00b396c -- 0xc00b394c + 0x0020 unregister_netdev 0xc39c320c -- 0xc01afe08 + 0x3813404 _end 0xc39c5bbc -- 0xc01afe08 + 0x3815db4 _end 0xc39a8b60 -- 0xc01afe08 + 0x37f8d58 _end 0xc39a8c80 -- 0xc01afe08 + 0x37f8e78 _end 0xc39b4dac -- 0xc01afe08 + 0x3804fa4 _end 0xc0003844 -- 0xc00036b4 + 0x0190 ppc_irq_dispatch_handler 0xc0003924 -- 0xc00038e8 + 0x003c do_IRQ The irq comes from unplugging the WLAN pcmcia card without calling "cardctl eject" before (which btw worked for every other wlan card so far). Ideas? Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
kfree_skb on hard IRQ ???
Steven Scholz wrote: > > Hi there, > > my HERMES-II drivers causes a lot of > > Warning: kfree_skb on hard IRQ c38c2168 > > messages. > > What do they mean? And what means alloc_skb called nonatomically from interrupt c00eb8d0 kernel BUG at skbuff.c:174! Oops: Kernel Mode Software FPU Emulation, sig: 8 NIP: C00E065C XER: LR: C00E065C SP: C016BC80 REGS: c016bbd0 TRAP: 1000Not tainted MSR: 1032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c0169fa0[0] 'swapper' Last syscall: 120 last math last altivec ... Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing <0>Rebooting in 10 seconds.. ??? Thanks a million! -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
kfree_skb on hard IRQ ???
Steven Scholz wrote: > > Hi there, > > my HERMES-II drivers causes a lot of > > Warning: kfree_skb on hard IRQ c38c2168 > > messages. > > What do they mean? Is it enough to just replace dev_kfree_skb() with dev_kfree_skb_irq() ??? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
kfree_skb on hard IRQ ???
Hi there, my HERMES-II drivers causes a lot of Warning: kfree_skb on hard IRQ c38c2168 messages. What do they mean? A grep on kernel sources brought me drivers/net/smc9.c: . 12/15/00 Christian Jullien fix "Warning: kfree_skb on hard IRQ" drivers/net/smc9194.c: . 12/15/00 Christian Jullien fix "Warning: kfree_skb on hard IRQ" drivers/net/hamradio/yam.c: * OK1ZIA 2.09.01 Fixed "kfree_skb on hard IRQ" net/core/skbuff.c: printk(KERN_WARNING "Warning: kfree_skb on hard IRQ %p\n", but I don't know how they fixed that... Thanks! -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
problem with queue_task() and mark_bh()...
Hi there,
I have a problem with queue_task() and mark_bh().
In a driver for the wireless HERMES-II chipset I found the code snippets
/* Register the ISR handler information here... */
lp->task.routine = (void (*)(void *))wl_isr_handler;
lp->task.data = lp;
printk("wl_isr_handler is @ %#lx\n", lp->task.routine);
At a later point (namely in the interrupt service rountine this happens:
/* If we have interrupts pending, then put them on a system task queue.*/
if( events == HCF_INT_PENDING ) {
/* Schedule the ISR handler as a bottom-half task in the
* tq_immediate queue
*/
printk( "Schedule the ISR handler %#lx...\n", lp->task.routine);
queue_task( &( lp->task ), &tq_immediate );
mark_bh( IMMEDIATE_BH );
}
The problem is now that the queued task lp->task (i.e. wl_isr_handler) never
get's called! And thus the driver does not work.
If I call the function directly using
lp->task.routine(lp);
instead of queue_task() and mark_bh() the function wl_isr_handler() gets
called and the driver works.
Any idea why queue_task() and mark_bh() do not work as expected?
How could I debug this problem?
(The two printk's show the same address.)
I am using linuxppc-2.4.25 from DENX CVS.
Thanks a million!!!
--
Steven Scholz
imc Measurement & Control imc Me?systeme GmbH
Voltastr. 5 Voltastr. 5
13355 Berlin13355 Berlin
Germany Deutschland
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8xx and wireless HERMES-II () ???
Hi there, I am trying to get a "proxim ORiNOCO PC Card" to work on my MPC8xx board with PCMCIA CS. Since it has a HERMES-II chipset I can't use the orinoco driver. So I went for Agere's wl_lkm_718_release.tar.gz. After inserting the card I get Wireless, HCF failure: "Command buffer size insufficient" :-( But funny enough I found the lines /***/ / Motorola Power PC 800 family ***/ /***/ /* known users: LH at I */ #if defined I_MPC8XX ... /***/ / MPC860 */ /***/ /* known users: RR */ #if defined CPU #if CPU == PPC860 in the include/hcf/hcfcfg.h. So of course now I wonder who might "LH at I" and "RR" be and if they realy use this driver in an MPC8xx environment. Any hints are mostly welcome !!! Thansk a million! -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
O(1) scheduler for PPC?
Jaap-Jan Boor wrote: > On Thu, 25 Mar 2004, Steven Scholz wrote: >> >>is the backport of Ingo Molnar's O(1) scheduler in the official linux-2.4.2x >>tree and is it available for the PPC? > > an up-to-date patch together with the preemptible kernel and low-latency > patches for 2.4.25 are available here: > > http://www.plumlocosoft.com/kernel Thanks a lot. But it looks like the recent "full patch against 2.4.25" found at http://www.plumlocosoft.com/kernel/patches/2.4/2.4.25/2.4.25-lck1/patch-2.4.25-lck1.bz2 still got the problems mentioned ages ago in http://lists.linuxppc.org/linuxppc-dev/200212/msg00032.html Maybe Eric Hustvedt could merge these trivials into his patch set. Thanks a million, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IDE, PCMCIA and MAX_HWIFS... ?
Hi there, if I have one IDE interface on my embedded PPC board and I might use a PC Card HDD in the PCMCIA socket, then do I have to override the define MAX_HWIFS with 1 or 2 ? So do I need some kind of a place holder for the IDE interface that might appear via PCMCIA Card service? Thanks a million. -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
O(1) scheduler for PPC?
Hi there, is the backport of Ingo Molnar's O(1) scheduler in the official linux-2.4.2x tree and is it available for the PPC? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
uncached user space mapping with mmap() ???
Jon Masters wrote: > | Is it always better to map only the small part I am going to use? > > Of course it is always best to map only the small range that you are > going to use and there will not necessarily be only one TLB mapping (I > am here referring to your comments on ARM Linux Kernel List) etc. etc. > However here especially I am inclined to repeat what they said on the > other list - these figures are so close that they might differ for other > reasons and so on. Did you repeat this in a controlled way many times? Yes. The thruput is calculated after repeating the loop 1000 times (Retries = 1000). > You will need to answer the questions Russell King posted in order for > us to work through this and figure out where the difference lies. I am just about to do it. -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
uncached user space mapping with mmap() ???
Hi there,
thanks very much for all your help.
I used the stuff St?phane suggested. But I have to ask again about
mapping of huge memory areas:
Let's say the peripheral has 32 MB address range staring at BASE. At
address GRAM 1MB of external SDRAM is located.
I use a simple test loop
p = (unsigned short *)
ioremap(base + GRAM, 32MB);
START ();
while (Retries--) {
for (i = 0; i < Size; i++) {
pData[i] = *p;
}
}
STOP ();
When I map only the the GRAM I get a throughput of
IoremapTest...8.0 s => 2049.4 kW/s
But when I map the whole address range
p = (unsigned short *)
ioremap(BASE, imcdevif_iosize);
and move the pointer
p += GRAM;
before entering the test loop I only get
IoremapTest...8.4 s => 1944.8 kW/s
How is that???
Is it always better to map only the small part I am going to use?
Thanks a million!
--
Steven Scholz
imc Measurement & Control imc Me?systeme GmbH
Voltastr. 5 Voltastr. 5
13355 Berlin13355 Berlin
Germany Deutschland
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
uncached user space mapping with mmap() ???
Fillod Stephane wrote: >>And: Can I mmap() 32MB of peripheral memory into user space? > > I don't see any reason why you would not be able to. Don't know. Maybe the number of entries in the translation tables are limited... -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
uncached user space mapping with mmap() ???
Fillod Stephane wrote: >>I am trying to access a hardware timer implemented in an FPGA from >>user space. I implemented a simple mmap() functionality (taken from >>Runbini's Linux Device Driver) > > Please refer to "11.13. Accessing peripherals from user space" > in the excellent FAQ from DENX's TWiki at : > > http://www.denx.de/twiki/bin/view/PPCEmbedded/DeviceDrivers#Section_Accessin > gPeripheralsFromUserSpace > > There's no need to implement kernel side stuff. /dev/mem is enough. Oh! Nice. Thanks a million! It actually works (on my ARM board!) So why will people need their own mmap() driver if this kind of things can be done via /dev/mem ??? And: Can I mmap() 32MB of peripheral memory into user space? -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
uncached user space mapping with mmap() ???
Hi there,
I am trying to access a hardware timer implemented in an FPGA from
user space. I implemented a simple mmap() functionality (taken from
Runbini's Linux Device Driver)
int simple_remap_mmap(struct file *filp, struct vm_area_struct *vma)
{
unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
if (offset >= __pa(high_memory) || (filp->f_flags & O_SYNC)) {
vma->vm_flags |= VM_IO;
}
vma->vm_flags |= VM_RESERVED;
if (remap_page_range(vma->vm_start, offset,
vma->vm_end-vma->vm_start, vma->vm_page_prot))
return -EAGAIN;
return 0;
}
I just learned that
> getting an uncached user space mapping is architecture dependent.
> On ARM, however, passing pgprot_noncached(vma->vm_page_prot) to
> remap_page_range() will alter the page protections such that the
> mapping will be uncached.
How could I do this on an MPC8xx?
Thanks a million!
--
Steven Scholz
imc Measurement & Control imc Me?systeme GmbH
Voltastr. 5 Voltastr. 5
13355 Berlin13355 Berlin
Germany Deutschland
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
EXT_DIRECT IDE Mode
> Steve, > > We have decided to move to a newer kernel (2.4.20 or greater). > As a simple check, would you please give me a list of files with the > CONFIG_IDE_EXT_DIRECT #ifdef so I can get a bit of assurance that I have > the support in the kernel before making the move. #~> grep -r -l CONFIG_IDE_EXT_DIRECT linux-2.4.21/* linux-2.4.21/drivers/ide/ppc/mpc8xx.c linux-2.4.21/drivers/ide/Config.in Good luck, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
EXT_DIRECT IDE Mode
DavidHo, > I'm using a variant of the 2.4.18 kernel from timesys. > > The kernel is compiled with those settings. (in your email) > > I had to add a call to m8xx_ide_init in m8xx-setup.c at the end of > platform_init. > > I can only find these defines in ide-m8xx.c. I am thinking there must be > more to it than the one file. Hmm. 2.4.18 is pretty old. I don't know if there's support for MPC8xx IDE! CONFIG_IDE_EXT_DIRECT was introduced long (!) after CONFIG_IDE_8xx_PCCARD and CONFIG_IDE_8xx_DIRECT. Did you add the code for IDE_EXT_DIRECT yourself? Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
EXT_DIRECT IDE Mode
DavidHo at nanometrics.ca wrote: > My application needs a compactflash and a 1.8" disk drive connected to the > MPC852T. Since the compact flash has already taken up the only PCMCIA > slot, the disk drive is directly attached to the PPC bus so I need to > enable EXT_DIRECT for the disk drive. Ok. > I haven't been able to make linux call the ide_init_hwif function. I > looked at how ide.c works and it looks like it enables IDE interfaces on > the PCI first (ide_default_io_base returns non-zero). I haven't yet been > able to find out where it call my function. > > Would you be able to tell me how you got this mode working. I do if you tell me which kernel version you tried. I guess you have CONFIG_BLK_DEV_MPC8xx_IDE=y # CONFIG_IDE_8xx_PCCARD is not set # CONFIG_IDE_8xx_DIRECT is not set CONFIG_IDE_EXT_DIRECT=y in your .config file? Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ELDK and suse 9.0
Kate, > I have user eldk a lot with Redhat 9 but after they discontinued it, i > decided to change to > suse 9 but looks a like that least standard eldk 2.1.0 install does not > work with suse9 Wolfgang Denk wrote on the U-Boot mailings list: > This is a known problem which will be fixed in ELDK-3.0 (due to be out soon). > > You have two options: > > 1) Install on an older SuSE or on a RedHat system and copy the files > 2) download the file ftp://ftp.denx.de/pub/tmp/ELDK-update-2.2.0.tar.bz2 >Then change into the source tree with the ELDK files and perform >the following operations: > > bash$ rm RPMS/rpm-4.0.3-1.03b_2.i386.rpm \ > RPMS/rpm-build-4.0.3-1.03b_2.i386.rpm \ > RPMS/rpm-devel-4.0.3-1.03b_2.i386.rpm \ > tools/usr/lib/rpm/rpmpopt-4.0.3 > bash$ tar jxf /tmp/ELDK-update-2.2.0.tar.bz2 > >Then build the ISO image as documented, and try again. > > > Best regards, > > Wolfgang Denk Both ways work. I am using ELDK-2.2 on SuSE 9. Good luck, Steven -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland fon: +49 30 467090-0Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Cross Compiler running under Win32
Dan Kegel wrote: > Steven Scholz wrote: > >> does someone know of a cross compiler (producing code for let's say >> MPC8xx) that >> is running natively under win32 (Windows2000/XP) without stuff like >> CYGWIN? >> >> I'am just wondering. >> Apparently MVISTA released their new "DevRocket" which is supposed to >> run under >> WindowsXP. So I assume they have cross compilers for "30 processors >> from 8 >> architectures" running under Windows... > > They could well be using cygwin for the compilers; they charge > enough that the licensing fee for cygwin is peanuts, I bet. > > But what's wrong with using Cygwin? I think Cygwin is much too much overhead for just compiling a small application. I was told that I could take just the GCC package from Cygwin without installing all of it. "licensing fee for cygwin" ??? So it's not free? Could we just take the GCC package and the DLL and distribute it together with our software and install it on our costumers Windows PCs? We have to be able to generate and (cross-)compile code on our costumers PCs that is than transfered to our devices and executed. -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland fon: +49 30 467090-0Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Preemptive Kernel and MPC8xx ???
Marius Groeger wrote: > AFAIK, you can pretty much drop the low-latency patch in favor of > using the lock-breaking patch. It is also available from Robert Love > at the cited home page. Rob Love wrote me: >>Is it correct that your lock-break does basicly the same as Andrew Morton's >>low-latency patches? Where is the big difference? > > Yes, basically the same thing. Lock-break is a version of low-latency > that is "optimized" for use with the preemptive kernel. > > You might as well just use low-latency, as Andrew is keeping that more > up to date. And that's what I noticed when looking and the download pages... That leaves three options: > (a) Use only preempt-kernel > (b) Use only low-latency > (c) Use preempt-kernel + low-latency Right? -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland fon: +49 30 467090-0Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Cross Compiler running under Win32
Hi there, does someone know of a cross compiler (producing code for let's say MPC8xx) that is running natively under win32 (Windows2000/XP) without stuff like CYGWIN? I'am just wondering. Apparently MVISTA released their new "DevRocket" which is supposed to run under WindowsXP. So I assume they have cross compilers for "30 processors from 8 architectures" running under Windows... Thanks. -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland fon: +49 30 467090-0Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Preemptive Kernel and MPC8xx ???
Hi, > On Mon, 24 Nov 2003, Jaap-Jan Boor wrote: > >>Yes I do on 2.4.20 and 2.4.22 from kernel.org. So far all seems >>to work but didn't do any measurements on it. >>(I both use the preempt and low-latency patches) Have you writting your own device drivers? How did you make them preemptable? Marius Groeger wrote: > AFAIK, you can pretty much drop the low-latency patch in favor of > using the lock-breaking patch. It is also available from Robert Love > at the cited home page. How about homemade device drivers when using the lock-breaking patch? Thanks! -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland fon: +49 30 467090-0Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Preemptive Kernel and MPC8xx ???
Hi,m is somebody actually using the preemptive kernel patches ... >>> >>>Yes I do on 2.4.20 and 2.4.22 from kernel.org. So far all seems >>>to work but didn't do any measurements on it. >> >>So you're using vanilla 2.4.22 on your MPC8xx board!? > > yes, am I stupid? NO! I nerver said that! I just didn't know that vanilla 2.4.22 from kernel.org is now stable enough w.r.t. MPC8xx. >>Could you please give me a link to find the mentioned "low-latency patches". > > it comes from Andrew Morton's page > http://www.zip.com.au/~akpm/linux/schedlat.html Thanks a million. Good luck, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Preemptive Kernel and MPC8xx ???
Hi, >> is somebody actually using the preemptive kernel patches ... >> > Yes I do on 2.4.20 and 2.4.22 from kernel.org. So far all seems > to work but didn't do any measurements on it. So you're using vanilla 2.4.22 on your MPC8xx board!? > (I both use the preempt and low-latency patches) Sound interessting. Could you please give me a link to find the mentioned "low-latency patches". Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
oops in i2c-rpx.c !
Hi there, the attached trival patch fixes a problem when using i2c-rpx.c without applying the "microcode relocation patch". Thanks. BTW: Why is this driver not in linuxppc-2.4 but in linuxppc_2_4_devel? -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland fon: +49 30 467090-0Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576 -- next part -- An embedded and charset-unspecified text was scrubbed... Name: i2c-rpx.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20031123/77e085a4/attachment.txt
Preemptive Kernel and MPC8xx ???
Hi there, is somebody actually using the preemptive kernel patches that can be found at http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/ on MPC8xx boards? If so which kernel version? Thanks a million! Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx memory mapped 16550A uart garbage
Lokesh, > I did measure the bit width and that is around 104us, which is correct. > Anything else? Hmm. I suppose you tried sending only character again and again and verified that your board is indeed sending this character over the lines by looking at the scope... Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx memory mapped 16550A uart garbage
Lokesh Kumar wrote: > Hi, > I got the serial.c from DENX linuxppc_2.4._devel tree which has support for > 16550A as memory mapped uart, and am using it as a module. I made > modifications to match my board. When I start it, it correctly recognizes > that I have a 16550A and at correct IRQ. However, when I open and send > something through the port (I just do cat>/dev/ttySe0), I get garbage on the > other side. My 16550 has a crystal of 3.6864MHz and the processor runs at > 49MHz. I thought that this kind of garbage problem is generally due to baud > rate not set correctly. I see the divisor correctly calculated as > 3686400/16/9600 = 24 and being sent to 16550. What else could I be doing > wrong? Did you verify the baudrate using a scope to measure the bittime? Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx memory mapped 16550 extrenal uart driver
Lokesh Kumar wrote: > I got the serial.c from DENX and am using it as a module. When I start it, > it correctly recognizes that I have a 16550A serial and at correct IRQ. > However, when I open and send something through the port, I get garbage on > the other side. My 16550 has a crystal of 3.6864MHz and the processor runs > at 49MHz. I thought that this kind of garbage problem is generally due to > baud rate not set correctly. I see the divisor correctly calculated as > 3686400/16/9600 = 24 and being sent to 16550. What else could be wrong? Hmm. No idea. Sorry. Did you try this? Send one character over and over again over you serial line and use a scope to measure the bit time. Just to make sure that timing is correct. Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Status of MPC5200 ???
Wolfgang Denk wrote: >>I wonder to which extend Motorola's MPC5200 is supported by now. >>... >>Which compiler do I need to use its floating point capabilities in an user >>land >>application? > > > We use the ppc_82xx packages from our ELDK for development. ELDK-2.1.1 that is!? Using gcc 2.95.4? -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland fon: +49 30 467090-0Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx memory mapped 16550 extrenal uart driver
Hi Lokesh, > Does anybody know of a driver for an external 16550 memory mapped uart > driver for an mpc855 based board? Any help is appreciated? Have a look at linuxppc_2_4_devel at DENX CVS between LABEL_2003_03_11_2055 and LABEL_2003_03_11_2110. This extension (for our board called DAB4K) makes it possible to use the standard linux serial driver with an external, memory mapped 16C752B dual uart. This one is recocnized by linux as two ST16654: ... Serial driver version 5.05c (2001-07-08) with no serial options enabled ttyS00 at 0xc3071000 (irq = 6) is a ST16654 ttyS01 at 0xc3071080 (irq = 8) is a ST16654 ... We then use ~ # ls -l /dev/ttyS*e crw-r--r--1 root root 204, 64 Mar 12 2003 /dev/ttyS0e crw-rw1 root root 204, 65 Sep 29 13:19 /dev/ttyS1e to access them. Works fine. Thanks to DENX. Hope this helps! -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland fon: +49 30 467090-0Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Status of MPC5200 ???
Hi there, I wonder to which extend Motorola's MPC5200 is supported by now. I know www.denx.de has a tree in its CVS server. Is everything supported yet? What about BitKeeper? Will there be support for this processor in the 2.4 series? Which compiler do I need to use its floating point capabilities in an user land application? Thanks a million! -- Steven Scholz imc Measurement & Control imc Me?systeme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin13355 Berlin Germany Deutschland fon: +49 30 467090-0Tel: 030 / 467090-0 fax: +49 30 4631576 fax: 030 / 4631576 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC823 and LCD?
Dan, >> Ok. So we could move the code into a drivers/video/lcd823.c (or >> mpc823fb.c), put your Copyrigth back in and make it available to all >> MPC823 boards. > > How different are these drivers? You mentioned Wolfgang's version > is "more generic"? Am I not sure. I'll have a look though. > I know lots of people have touched this driver > since the beginning of time, and I think Scott Anderson actually > made it look pretty :-) :o) > I think if the driver remains LCD only, > we need to keep that as part of the name (like lcd823fb.c). If someone > merges the LCD and YUV video into one driver, then call it something > like mpc823fb.c Good point. I think we should keep it seperated. > I don't care so much about the copyright update > as the loss of the history of people that have worked on it. :o) Ok. As I said I'll have a look. Cheers, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC823 and LCD?
Dan Malek wrote: >> Is this driver in any way special to RPX boards? >> Or could we make it available to other MPC823 boards as well? > > > H.interesting how the driver I wrote becomes MV copyrighted... > Oh well. :-( > There isn't anything uniqe to the RPX boards in the driver, only > the LCD type. The original one had some backlight/touchscreen > stuff in it, but I see that is gone now. Ok. So we could move the code into a drivers/video/lcd823.c (or mpc823fb.c), put your Copyrigth back in and make it available to all MPC823 boards. Ok? Objections? > The lcd driver is for an LCD screen, the video driver is for YUV > mode composite/S-Video output. Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC823 and LCD?
Steven, >> 1. Has someone a working driver for linux > 2.4.20? > check out drivers/video/rpxfb.c Thanks for that hint. Is this driver in any way special to RPX boards? Or could we make it available to other MPC823 boards as well? IIRC the lcd823.c driver in DENX kernel is quite generic. Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC823 and LCD?
Hi there, two questions about MPC823 and LCD: 1. Has someone a working driver for linux > 2.4.20? 2. what's the difference between lcd823.c and video823.c in linux-2.4.4 from DENX? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BOOT_TARGET pImage & uImage ???
Tom Rini wrote: > On Mon, Sep 15, 2003 at 12:16:29PM +0200, Steven Scholz wrote: > > >>is the there any particular reason why the BOOT_TARGETS "pImage" and >>"uImage" for >>the famous boot loader PPCBoot and its successor U-Boot are still not >>supported. >>Neither by linux_2_4_devel. Nor by the vanilla. > > > For a third time: > http://www.geocrawler.com/archives/3/8358/2002/11/0/10241415/ I have to admit that I don't understand what you're describing there. I am afraid nobody else did. Otherwise someone would realized it by now... Sorry though. Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems w/ CONFIG_BLK_DEV_MPC8xx_IDE
Tom, So which is the BK tree to use: linuxppc_2_4_devel or linuxppc-2.4 ??? > > Aside from possible changes to match upstream subsystem rewrites (such > as IDE) there hasn't been any changes in linuxppc-2.4 specific to 8xx > that didn't happen in 2_4_devel. > >>http://www.penguinppc.org/dev/kernel.shtml calls linuxppc_2_4_devel the >>"old PPC development tree" !? > > That's correct. It's becoming more of a pain to maintain or own set of > trees to track 2.4 when Marcelo uses BK as well. I suppose we need both trees. Otherwise you would have got rid of one. Right? :o) Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems w/ CONFIG_BLK_DEV_MPC8xx_IDE
Tom, >>I just noticed that I might have used the wrong source tree. >> >>So which is the BK tree to use: >> >>linuxppc_2_4_devel or linuxppc-2.4 ??? > > > It depends on where what you want to use exists. If something is in > _devel and not in linuxppc-2.4, patches to move features over one at a > time would be happily reviewed. ??? So which is the most recent? http://www.penguinppc.org/dev/kernel.shtml calls linuxppc_2_4_devel the "old PPC development tree" !? Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems w/ CONFIG_BLK_DEV_MPC8xx_IDE
Hubert Figuiere wrote: > On Mon, 2003-09-15 at 13:31, Steven Scholz wrote: > > >>The BK linuxppc_2_4_devel tree has another problem as well: >> >>drivers/ide/idedriver.o: In function `probe_hwif': >>drivers/ide/idedriver.o(.text+0x11a30): undefined reference to >>`wait_hwif_ready' >>drivers/ide/idedriver.o(.text+0x11a30): relocation truncated to fit: >>R_PPC_REL24 >>wait_hwif_ready >> >>ide-probe.c contains a call for wait_hwif_ready(), which is not defined. >>This function exisists in the vanilla source though! >> >>I supposed something went wrong while merging/syncing the IDE changes from the >>official tree... > > > Change 'wait_hwif_ready' by 'ide_wait_hwif_ready' in both ide-probe.c > and ide.c Ok. This obviously fixes it. I just noticed that I might have used the wrong source tree. So which is the BK tree to use: linuxppc_2_4_devel or linuxppc-2.4 ??? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems w/ CONFIG_BLK_DEV_MPC8xx_IDE
Steven Scholz wrote: > I just noticed that the vanilla 2.4.22 does not compile with > CONFIG_BLK_DEV_MPC8xx_IDE: > > drivers/ide/idedriver.o: In function `ide_timer_expiry': > drivers/ide/idedriver.o(.text+0xaa30): undefined reference to > `ide_ack_intr' > drivers/ide/idedriver.o(.text+0xaa30): relocation truncated to fit: > R_PPC_REL24 > > It's the same for the BK trees. The BK linuxppc_2_4_devel tree has another problem as well: drivers/ide/idedriver.o: In function `probe_hwif': drivers/ide/idedriver.o(.text+0x11a30): undefined reference to `wait_hwif_ready' drivers/ide/idedriver.o(.text+0x11a30): relocation truncated to fit: R_PPC_REL24 wait_hwif_ready ide-probe.c contains a call for wait_hwif_ready(), which is not defined. This function exisists in the vanilla source though! I supposed something went wrong while merging/syncing the IDE changes from the official tree... Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
BOOT_TARGET pImage & uImage ???
Hi, is the there any particular reason why the BOOT_TARGETS "pImage" and "uImage" for the famous boot loader PPCBoot and its successor U-Boot are still not supported. Neither by linux_2_4_devel. Nor by the vanilla. Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems w/ CONFIG_BLK_DEV_MPC8xx_IDE
Hi there, I just noticed that the vanilla 2.4.22 does not compile with CONFIG_BLK_DEV_MPC8xx_IDE: drivers/ide/idedriver.o: In function `ide_timer_expiry': drivers/ide/idedriver.o(.text+0xaa30): undefined reference to `ide_ack_intr' drivers/ide/idedriver.o(.text+0xaa30): relocation truncated to fit: R_PPC_REL24 It's the same for the BK trees. The attached patch fixes that. Please apply and forward it. Thanks a million, Steven -- next part -- An embedded and charset-unspecified text was scrubbed... Name: MPC8xx_IDE.fix Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20030915/a28ac991/attachment.txt
large file support?
Wolfgang Denk wrote: > In message <3F290506.3060304 at imc-berlin.de> you wrote: > >>I reckon my app does not support large files. Since after writing 2GB >>to a file > > > Did you build it with the required options, like #defining > _FILE_OFFSET_BITS as 64 ? Nope! But good point! :o) And I just got these lines: Fillod Stephane wrote: > Recent kernel and glibc are fine. > > Pass O_LARGEFILE to the second open() arg, and compile > with "-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" should do it. and rebuilt my application. But the test (with my app) will take a while... Thanks! Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
large file support?
I wrote: > how could I find out if the kernel and the glibc I am using will > correctly supprot large files (>2GB)? I reckon my app does not support large files. Since after writing 2GB to a file ~ # ls -lh /mnt/intern/HDD_STRESS/2003-07-31\ 12-27-34\ \(1\)/ -rw-r--r--1 root root 1.0G Jul 31 13:57 K001_G0.raw -rw-r--r--1 root root 1.0G Jul 31 13:57 K002_G0.raw -rw-r--r--1 root root 2.0G Jul 31 13:57 V001_G0.raw ~ it claims "disk full" although ~ # df -h FilesystemSize Used Available Use% Mounted on /dev/mtdblock06.9M 5.1M 1.8M 74% / /dev/shm 7.1M 24.0k 7.1M 0% /var /dev/hda1 9.2G 4.0G 4.7G 46% /mnt/intern Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
large file support?
Wolfgang Denk wrote: > In message <3F28EFD6.3070803 at imc-berlin.de> you wrote: > >>how could I find out if the kernel and the glibc I am using will >>correctly supprot large files (>2GB)? > > > char buf[4096]; > for (;;) > write (fd, buf, sizeof(buf)); > :o) But what will happen if I (or my application) have no large file support, i.e. is the failure deterministic? And will it be obvious? Just by do "ls -l" :-) Thanks anyway! Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
large file support?
Hi there, how could I find out if the kernel and the glibc I am using will correctly supprot large files (>2GB)? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems rebuilding the DENX ELDK
Dear Wolfgang, >>I made it once to rebuild the ELDK under a modified SuSE 8.0. But I >>can't do it again. I just can't remember what I did. But as long as I > > I still have the description you sent me back then. Shall I forward > it to you? :-) :o) Then it should be in my Sent-Mail folder... I'll have a look. > I think we will have an initial test version before the end of next > week. I can keep you posted, if you like. Yes. Please. Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems rebuilding the DENX ELDK
Dear Wolfgang, > Dear Steven, > > in message <3F1F8738.3040209 at imc-berlin.de> you wrote: > >>I am trying to rebuild the great DENX's ELDK from scratch. >>My host is a SuSE 8.2 system. >>The first obstacle is that some packages won't build with recent >>automake/autoconf version. So I got some old versions built and >>installed them on my system. >> >>Now the first step - build the RPM - works. I do get a rpm binary in >>/opt/eldk/build/ppc-2003-07-23/work/bin > > > Just a note: if this is not really urgent, you might just want to > wait a bit. We're working on the next release of the ELDK, which will > be based on YD-3.0, which contains rpm-4.1 > > I guess we will have to validate this release with a SuSE system, > too. Jippieh!!! I test! I test! :o) I made it once to rebuild the ELDK under a modified SuSE 8.0. But I can't do it again. I just can't remember what I did. But as long as I am not able to rebuild it I can't update my build host to a more recent SuSE version... :-( So I think I can wait (how long?). But any idea about my original question? I'd love to understand this whole automake/autoconf/rpm stuff? I suppose the times of handwriten/optimized Makefiles are gone... Forever... ;-) Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems rebuilding the DENX ELDK
Hi there,
I am trying to rebuild the great DENX's ELDK from scratch.
My host is a SuSE 8.2 system.
The first obstacle is that some packages won't build with recent
automake/autoconf version. So I got some old versions built and
installed them on my system.
Now the first step - build the RPM - works. I do get a rpm binary in
/opt/eldk/build/ppc-2003-07-23/work/bin
But the next step - build the target RPM from eldt - fails:
The log shows:
+ CFLAGS=-O2 -march=i386 -mcpu=i686
+ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
'--infodir=${prefix}/share/info' '--mandir=${prefix}/share/man'
--enable-shared=no --enable-static=yes --with-target-arch=ppc
creating cache ./config.cache
...
Finding Provides: (using
/opt/eldk/build/ppc-2003-07-23/work/usr/lib/rpm/find-provides)...
PreReq: /bin/sh /bin/sh rpmlib(CompressedFileNames) <= 3.0.4-1
Requires(interp): /bin/sh /bin/sh
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
Requires(pre): /bin/sh
Requires(post): /bin/sh
Conflicts: patch < 2.5
Processing files: rpm-devel-4.0.3-1.03b_3
Executing(%doc): /bin/sh -e
/opt/eldk/build/ppc-2003-07-23/work/var/tmp/rpm-tmp.42006
+ umask 022
+ cd /opt/eldk/build/ppc-2003-07-23/work/usr/src/denx/BUILD
+ cd rpm-4.0.3
+
DOCDIR=/opt/eldk/build/ppc-2003-07-23/work/var/tmp/rpm-root/usr/share/doc/rpm-devel-4.0.3
+ export DOCDIR
+ rm -rf
/opt/eldk/build/ppc-2003-07-23/work/var/tmp/rpm-root/usr/share/doc/rpm-devel-4.0.3
+ /bin/mkdir -p
/opt/eldk/build/ppc-2003-07-23/work/var/tmp/rpm-root/usr/share/doc/rpm-devel-4.0.3
+ cp -pr apidocs
/opt/eldk/build/ppc-2003-07-23/work/var/tmp/rpm-root/usr/share/doc/rpm-devel-4.0.3
+ exit 0
Finding Provides: (using
/opt/eldk/build/ppc-2003-07-23/work/usr/lib/rpm/find-provides)...
PreReq: rpmlib(CompressedFileNames) <= 3.0.4-1
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
Requires: rpm = 4.0.3
Processing files: rpm-build-4.0.3-1.03b_3
Finding Provides: (using
/opt/eldk/build/ppc-2003-07-23/work/usr/lib/rpm/find-provides)...
PreReq: rpmlib(CompressedFileNames) <= 3.0.4-1
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
Requires: rpm = 4.0.3
Processing files: popt-1.6.3-1.03b_3
Finding Provides: (using
/opt/eldk/build/ppc-2003-07-23/work/usr/lib/rpm/find-provides)...
PreReq: rpmlib(CompressedFileNames) <= 3.0.4-1
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
error: /opt/eldk/build/ppc-2003-07-23/work/var/tmp/rpm-tmp.62141:
Fseek failed: Invalid argument
I am confused! 3.0.4 is the version of rpm that comes with SuSE 8.2.
But I thought ELDK builds the rpm with "--enable-static=yes". So why
is he asking for "rpmlib(CompressedFileNames) <= 3.0.4-1" ???
Thanks a million!
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xx SCC's as uart
Eli Brin wrote: >> So you want to use the modem without hw flow control (RTS/CTS) ? > No, it depends on mgetty. > > I think that mgetty need hw flow control (RTS/CTS) to monitor the DCD line. ??? I am not sure if I understand. > > I can rewire (short) the RTS/CTS on each side (modem and 8xx), and connect > only DCD. Sure. If you don't care if data gets lost... Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xx SCC's as uart
Eli Brin wrote: > Dear Steven, > > I tested linuxppc_2_4_devel-2.4.20-2002_12_04.tar.bz2 snapshot from Denx > ftp. > I will get the version you referred me to. > > Regarding the hardware handshake, we will connect an SCC to a modem chip, > and my tests show I need the DCD line from the modem so that mgetty (in > autoppp mode) will detect disconnections. It didn't detect disconnections > without the modem handshake (DCD drop). > > We will try to get it working Tx.Rx only. > So you want to use the modem without hw flow control (RTS/CTS) ? Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xx SCC's as uart
Eli Brin wrote: > Hello, > > I have noticed, in kernel 2.4.20, that SCC1 and SCC4 cannot be configured as > uarts. > > Also, the configuration for RTS,CTS,DCD and DTR are missing. > > Comparing 8xx_io/uart.c file to the 2.4.4 version of uart.c shows that all > the code to support the above has been removed, although both show driver > 0.3. > > Our target will use all SCC's as uarts with hardware handshake. So I will > need to put this back into uart.c and the config.in files. > > Is there a reason for this feature (SCC1 and SCC4 as uarts are part of the > 8xx ability) being removed ? They haven't been removed! This feature just never made it into the official BitKeeper tree. Have a look at linuxppc_2_4_devel in the DENX CVS. Especialy between the labels LABEL_2003_03_11_2045 and LABEL_2003_03_11_2055! BTW: Make sure you understood the "hardware handshake" done by the MPC8xx! MPC8xx CTS/RTS have a different meaning than you might expect when dealing with real UARTS! Basicly the only support flow control in one direction! So a device can throttle the MPC. But the MPC can _not_ stop the device from sending more! Hope this helps. Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
DENX ELDK Kernel
Wolfgang Denk wrote: >>never stopped me before! Basically, the answer is yes - at least I >>have been using the ELDK with a linux-2.4.20 kernel (from kernel.org). >>The key point to remember is that you should always compile user >>applications against the Linux include files that glibc (and all the >>rest of the target ELDK apps) are built against - Do NOT compile your >>user applications against the newer Linux kernel. > > > 10 of 10 points :-) Stupid question (TM): If I'd built the ELDK from scratch and used Linux-2.4.20 include files to build "glibc (and all the rest of the target ELDK apps)" I should build my "applications against the newer Linux kernel"! Shouldn't I? And in general: shouldn't I used a glibc that "matches" the kernel version? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC8xx EXT_DIRECT IDE
Zhu jiangbo schrieb: > > I have read the mail listed below on the "lists.linuxppc.org" > website. It looks like you are the right expert who can help me > solving my problem. The embedded linux can't detect my SANDISK CF > card. I choosed the EXT_DIRECT mode (CF's TRUE IDE mode), but now > I am not sure if my design is right. Would you please send me the > schematics and documents about MPC8xx IDE? If you don't need a real PCMCIA slot on your board it would be much easier to use 8xx_DIRECT instead of EXT_DIRECT!!! I had to go for EXT_DIRECT since I do need both - PCMCIA slot for let's say WLAN Cards and IDE for a 2.5" HDD. So what do you think? Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Question about MPC8xx PCMCIA
Hi there, I do have some problems with PCMCIA cards on my MPC855T based board. In fact there are two: 1. I do get some "cs: socket 0 timed out during reset". But they become rare now. (So this shouldn't be the issue right now.) 2. Some cards (96MB Flash Card from SimpleTech and SiliconTech" are "sometimes" not recognized correctly. I get cardmgr[367]: socket 0: Anonymous Memory cardmgr[367]: executing: 'modprobe memory_cs' instead of cardmgr[62]: socket 0: ATA/IDE Fixed Disk cardmgr[62]: product info: "STI", "Flash 5.0" cardmgr[62]: manfid: 0x0007, 0x function: 4 (fixed disk) The reason for that is that the CIS is not read correctly. I do expierence the same problems with an TQM860L (STK), linux-2.4.20 (from DENX) and pcmcia-cs-3.2.4 (with m8xx patches from DENX ELDK). I know this "sometimes" does not help much. But I am here to ask some general questions: 1. Why do we power up the card as early as in hardware_enable()? IMHO this is the task of cardmgr! 2. In hardware_enable() we're wait quiet a while for the card to come up. But a) cs.c is responsible for a vcc_settle delay and b) later insertions are _not_ effected by this anyway. So it's only for one time while system startup... !? Should we do that everytime voltage_set() gets called? But then again cs.c is responsible for vcc_settle... 3. Most implementaions of voltage_set() in m8xx_pcmcia.c first switch the power off and then switch it back on. Fair enough. BUT every- time m8xx_set_socket() gets called, the power is switched off and on again. Even if the vcc state didn't changed! So it's switched off and on without good reason _and_ without time to settle! I can't imagine that this is feature... So I think voltage_set() should only switch powers if something changed. 4. Someone wrote in m8xx_set_socket() : /* The CxOE signal is connected to a 74541 on the ADS. I guess most other boards used the ADS as a reference. I tried to control the CxOE signal with SS_OUTPUT_ENA, but the reset signal seems connected via the 541. If the CxOE is left high are some signals tristated and no pullups are present -> the cards act wierd. So right now the buffers are enabled if the power is on. */ Well. "The PCMCIA Developer's Guide" states on page 55 "After the socket controller enables power to the socket, there is at least a 300mS delay until output signals are enabled ... All socket controller output signals, including RESET, are in a tristate mode until the end of the 300mS delay." So if I change if(state->Vcc || state->Vpp) M8XX_PGCRX(_slot_) &= ~M8XX_PGCRX_CXOE; to if(state->flags & SS_OUTPUT_ENA) M8XX_PGCRX(_slot_) &= ~M8XX_PGCRX_CXOE; /* active low (as it would be correct) then the above mentioned FLASH CARDS indeed act wiered... .-( I hope that someone out there finds time and wants to share his thoughts with me. Thanks a million and have a nice weekend! Cheers, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
8xx FEC: test for fep->link ???
Hi there,
the (old) version of arch/ppc/8xx_io/fec.c I have contains
if (!fep->link) {
/* Link is down or autonegotiation is in progress. */
return 1;
}
in fec_enet_start_xmit().
The recent BitKeeper version does _not_ test this.
Why? Is it not nessessary anymore? Because of the introduced
start/stop_mii_queue() maybe???
Thanks a million,
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
jffs2 partition on a TQM860L???
Wolfgang Denk schrieb:
> In message <3EDDB269.1080609 at imc-berlin.de> you wrote:
>
>>I do use your linuxppc_2_4_devel tree. But still I don't know how to
>>configure one big JFFS2 partition that spawns over two flash banks!
>
>
> Just type "make TQM860L_config ; make oldconfig".
>
>
>>Or maybe I don't understand the difference betwenn the two sturcts:
>>
>>/* partition definition for first flash bank
>> * also ref. to "drivers\char\flash_config.c"
>> */
>>static struct mtd_partition tqm8xxl_partitions[] = {
>>...
>>
>>/* partition definition for second flahs bank */
>>static struct mtd_partition tqm8xxl_fs_partitions[] = {
>
>
> You must be confusing source versions. In the linuxppc_2_4_devel tree
> there is just one declaration for tqm8xxl_partitions[].
>
> tqm8xxl_fs_partitions[] was only used in older versions of our tree.
>
> Best regards,
>
> Wolfgang Denk
>
Oh! I see. Apparently while updating to a newer MTD version this file
was overwritten with an older version!
Thanks again!
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
jffs2 partition on a TQM860L???
Hi there, I want to use JFFS2 as root fs on a TQM860L with 8MB flash. This flash is seperated into two flash banks each 4MB. (How) can I define one big jffs2 partition (in ./drivers/mtd/maps/tqm8xxl.c) that contains sectors from both flash banks? Thanks a million, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ELDK and Red Hat Linux 9 ???
Hi there, is someone using the (precompiled) ELDK under RH9 ? Or has somebody succcessfully build the ELDK "from scratch" on RH9? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
execve inside irq?
I wrote:
>
> Wojciech Kromer schrieb:
>
>>
>> anyone knows ho to call execve inside irq
>>
>> i just want to execve("/sbin/poweroff") in case of pressing power
>> button on my board
>
>
> Since I did not find a better solution yet I start a new kernel thread
> that takes care of poweroff when getting the power button interrupt.
> In this new thread I then send a SIGUSR1 to init, but you could
> probably call "execve("/sbin/poweroff") " as well.
Of course I meant SIGUSR2. (Busybox') init powers down then...
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
execve inside irq?
Wojciech Kromer schrieb:
>
> anyone knows ho to call execve inside irq
>
> i just want to execve("/sbin/poweroff") in case of pressing power
> button on my board
Since I did not find a better solution yet I start a new kernel thread
that takes care of poweroff when getting the power button interrupt.
In this new thread I then send a SIGUSR1 to init, but you could
probably call "execve("/sbin/poweroff") " as well.
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
JFFS2 on the Host
Cedric, > it's ok. But How can I make a full Binary Image of my > flash partition (good size) on my host and after > transfer it on the target at the right > place with my loader (u-boot for example) ?? I am not sure if I understand your question. But if you want to know how to create a flash image that you can burn onto your target then my answer will be: 1. Create a root file system directory structure on your host. (e.g. use SELF from www.denx.de) 2. Run mkfs.jffs2 on this directory (make sure you use the correct endianess) to create the flash image 3. Burn the resulting image onto your target using BDI2000 or U-Boot... Hope this helps! Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I2C RTC causes boot delay...
Joakim Tjernlund schrieb: >>I wrote, >> >> >>>I have an I2C RTC connected to my MPC855T to substitute the internal one. >>> >>>I noticed that between >>> >>> Verifying Checksum ... OK >>> Uncompressing Kernel Image ... OK >>> >>>and the next lines printed while booting "nothing" happens for THREE >>>seconds. >>> >>>I reckon that is has something to do with not having an external 32kHz >>>clock on the MPC. But I can't find the place in the sources! >> >>I migth have found it: >> >>Is it ok and enough to set >> >> ppc_md.set_rtc_time = NULL; >> ppc_md.get_rtc_time = NULL; >> >>in platform_init()? And then later - when I2C is initialized - set it >>to the appropriate I2C RTC functions? > > > Yes, that's it. If your kernel ever hangs after printing out > "calibrating delay loop ...", try adding a set_tb(0,0) somewhere in > m8xx_setup.c, > to see if it fixes it. Thanks Jocke! > You may also want to add an "I2C reset sequence" in your firmware/kernel > if your I2C clock gets stuck and don't respond(can happen if reset/power down > while > reading the RTC). Look in u-boot for details. Yeah. I know. I should put into PPCBoot/U-Boot. But in the docs it says it's only for SOFT_I2C aka bitbang! So a) can I toggle the pins using GPIO and still use HARD_I2C? or b) can I use SOFT_I2C in PPCBoot and CPM I2C (8xx-algo) under linux? Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I2C RTC causes boot delay...
I wrote, > I have an I2C RTC connected to my MPC855T to substitute the internal one. > > I noticed that between > >Verifying Checksum ... OK >Uncompressing Kernel Image ... OK > > and the next lines printed while booting "nothing" happens for THREE > seconds. > > I reckon that is has something to do with not having an external 32kHz > clock on the MPC. But I can't find the place in the sources! I migth have found it: Is it ok and enough to set ppc_md.set_rtc_time = NULL; ppc_md.get_rtc_time = NULL; in platform_init()? And then later - when I2C is initialized - set it to the appropriate I2C RTC functions? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I2C RTC causes boot delay...
Hi there, I have an I2C RTC connected to my MPC855T to substitute the internal one. I noticed that between Verifying Checksum ... OK Uncompressing Kernel Image ... OK and the next lines printed while booting "nothing" happens for THREE seconds. I reckon that is has something to do with not having an external 32kHz clock on the MPC. But I can't find the place in the sources! Could someone please give me a hint where to look. Can I just skipped this part then for my board. Or do I realy need an external 32kHz for running linux? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] arch/ppc/8xx_io/enet.c, version 3
Hi there, has someone actually ported Jocke's patch to 8xx FEC !? Any benchmarks? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
was: FEC on MPC860T & race condition
Tom Rini schrieb:
> On Fri, Feb 07, 2003 at 08:37:05AM +0100, Steven Scholz wrote:
>
>>Tom Rini wrote:
>>
>>>...
>>>Okay. Moving along the process, I have a comment:
>>>
>>>
>>>
>>>>@@ -2285,6 +2278,39 @@
>>>>fep->old_status = 0;
>>>>#endif /* CONFIG_USE_MDIO */
>>>>
>>>>+#ifdef CONFIG_USE_MDIO
>>>>+# ifndef PHY_INTERRUPT
>>>>+# error Want to use MII, but PHY_INTERRUPT not defined!
>>>>+# endif
>>>>+ /* before requesting the irq, we should wait until PHY is discovered
>>>>+* to avoid race conditions
>>>>+*/
>>>>+ while (!fep->phy_id_done) {
>>>>+ udelay(5);
>>>>+ }
>>>
>>>
>>>I believe this is wrong, in that trying to udelay() here is a bad idea.
>>>I don't have the time right now, but I suspect google, or #kernelnewbies
>>>might be able to suggest a more appropriate way of waiting here.
>>>
>>>Or perhaps classes have fried my mind, and this is correct.
>>
>>No. I bet you're right.
>>But can you make any suggestion on how to wait for some I/O to become ready?
>
>
> How about what Dan mentioned, with a function pointer and whatnot?
As I admitted in my mail to Dan, I am not sure if I understand excactly what
mean...
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
was: FEC on MPC860T & race condition
Tom Rini wrote:
>...
> Okay. Moving along the process, I have a comment:
>
>
>>@@ -2285,6 +2278,39 @@
>> fep->old_status = 0;
>> #endif /* CONFIG_USE_MDIO */
>>
>>+#ifdef CONFIG_USE_MDIO
>>+# ifndef PHY_INTERRUPT
>>+# error Want to use MII, but PHY_INTERRUPT not defined!
>>+# endif
>>+ /* before requesting the irq, we should wait until PHY is discovered
>>+ * to avoid race conditions
>>+ */
>>+ while (!fep->phy_id_done) {
>>+ udelay(5);
>>+ }
>
>
> I believe this is wrong, in that trying to udelay() here is a bad idea.
> I don't have the time right now, but I suspect google, or #kernelnewbies
> might be able to suggest a more appropriate way of waiting here.
>
> Or perhaps classes have fried my mind, and this is correct.
No. I bet you're right.
But can you make any suggestion on how to wait for some I/O to become ready?
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
was: FEC on MPC860T & race condition
Dan Malek schrieb: > Tom Rini wrote: > >> I believe this is wrong, in that trying to udelay() here is a bad idea. > > > I agree. All of the MII communcation is interrupt driven. This is easy > and the way everything should work on the 8xx. The link interrupt is > more challenging because the interrupt from that depends upon the phy > type and the board design. The link interrupts are either real interrupts > or managed with a timed thread. > > If you need to wait before installing the link interrupt (which I still > don't understand why), this should be done as part of the phy discovery > interrupt. For example, add an indirect function pointer and if it isn't > NULL, call it at that time to do anything that must wait until the phy > is discovered and initialized. I understand what you mean. And certanly you're right. I moved the request_irq into 3 but my board still hanges from time to time. At a different place in a different way though. I have to admit that I don't understand this mii_queue stuff. Please, Dan, would you please give me a small hint! I assume by "add an indirect function pointer" you mean "add something to mii_queue"... Is that right? Thanks! Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
was: FEC on MPC860T & race condition
I wrote: >>I just hab a look at arch/ppc/8xx_io/fec.c in the recent linuxppc_2_4 and >>could find this problem fixed! The MII irq is still requested very early >>without waiting for the PHY to discovered! Damn it!!! Stupid fingers. I meant to write "could NOT find this problem fixed" ! > So linuxppc_2_4 has a partial fix then is what you're saying? Around > what lines? I'm interested to see why _devel doesn't have this. So IHMO there is neither in recent linuxppc_2_4_devel nor in linuxppc_2_4 a fix for the mentioned problem. I'll attach my patch. It is not configurable since I think it won't break anything. If you need or wish something like CONFIG_FEC_FIX_RACE or CONFIG_FEC_LATE_ENABLE_PHY I could do that! Regards, Steven -- next part -- An embedded and charset-unspecified text was scrubbed... Name: fec8xx_fix_race.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20030204/6d07ed47/attachment.txt
was: FEC on MPC860T & race condition
Tom Rini schrieb: > On Fri, Jan 31, 2003 at 10:16:25AM +0100, Steven Scholz wrote: > >>Dan Malek wrote: >> >>>Steven Scholz wrote: >>> >>> >>>>You, Laurent, told us about a race condition. >>>>You, Dan, first claimed, it was already fix but mentioned later that >>>>the patch >>>>was somehow lost. >>> >>> >>>IIRC, it was the usual problem of having it fixed in only one of the >>>two 2.4 trees. I ensured both trees were made up to date. >> >>There is still no fix in linuxppc_2_4_devel! > > > Um, but there is in linuxppc_2_4 ? Is that a question or a statement? I just hab a look at arch/ppc/8xx_io/fec.c in the recent linuxppc_2_4 and could find this problem fixed! The MII irq is still requested very early without waiting for the PHY to discovered! Cheers, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
was: FEC on MPC860T & race condition
Dan Malek wrote: > Steven Scholz wrote: > >> You, Laurent, told us about a race condition. >> You, Dan, first claimed, it was already fix but mentioned later that >> the patch >> was somehow lost. > > > IIRC, it was the usual problem of having it fixed in only one of the > two 2.4 trees. I ensured both trees were made up to date. > There is still no fix in linuxppc_2_4_devel! >> Now I have this problem as well and realised that in 2.4.20 the >> "mii_link_interrupt interrupt handler is still registered before the >> PHY chip is initialized". > > The link interrupt is board design and PHY dependent. I don't think there > is any one "right" way to initialize this interrupt handler. If you have > something that isn't working to your liking, we may have to extend the > MII logic in some way to accomodate this. Keep in mind that the existing > driver is likely working with other boards, and you don't want to break > those configurations. There is a race condition! Lucky you if you never see it! :o) But fair enough. If more people had this problem, the fix would be in the trees by now. How about adding something like CONFIG_FEC_LATE_ENABLE_PHY or so. Of course with a help text in Documentation/Configure.help so that people having that problem could easily enable that. And for the rest (although this might be the majority) everythings stays as it it. Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
was: FEC on MPC860T & race condition
Hi there, in October 2001 (!) there were two threads, one was "FEC on MPC860T & race condition" and the other was "Problem using FEC on a860T" You, Laurent, told us about a race condition. You, Dan, first claimed, it was already fix but mentioned later that the patch was somehow lost. Now I have this problem as well and realised that in 2.4.20 the "mii_link_interrupt interrupt handler is still registered before the PHY chip is initialized". Are there any plans to fix that? Laurent, did you fix taht for your board properly or just as a work around? Thanks a million, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I2C RTC with MPC8xx?
Keith Outwater schrieb: > Hi Stephen - > > I am successfully using a DS1337 RTC with PPCBoot/U-Boot and a > linux-2.4.4-10-06 kernel from the Denx FTP site. I haven't gotten around > to submitting it, but let me know if you want the patch. I actually wouldn't mind! :o) I guess it's not to hard to put it onto 2.4.20. Yesterday I received a file from Jocke. I would be more than happy to compare them. Maybe Wolfgang is putting that on his 2.4.20 CVS someday! BTW I think I'll need the DS1307. Hope it's only a differnt pinout. It has a dedicated battery pin and no irq output. Is the driver or linux using RTC interrupts? Thanks a million, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I2C RTC with MPC8xx?
Wolfgang Denk schrieb: > In message <3E37CB15.50307 at imc-berlin.de> you wrote: > >>what do I have to do to use an I2C RTC (like Dallas DS1337) within LinuxPPC? > > Use drivers/i2c/i2c-algo-8xx.c and add your own version of > drivers/i2c/i2c-ds1337.c ? Hmm. But there must be at least one excample!? Someone must have done that before!? After all I don't want to reinvent the wheel... (Ooh, how much I love that phrase!) :o) >>I know there're drivers for PPCBoot / U-Boot. > > > There are also drivers for Linux. I bet there are drivers for Linux! How else should all the people using PPCBoot/U-Boot and I2C RTCs on MPC8xx platforms access them from Linux... But where could I find one? Isn't LWMON using an I2C RTC? But I just can't find the driver... Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
I2C RTC with MPC8xx?
Hi there, what do I have to do to use an I2C RTC (like Dallas DS1337) within LinuxPPC? I know there're drivers for PPCBoot / U-Boot. But how could I access them from Linux? drivers/char/rtc_8xx.c is not suitable. Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
problems with MPC8xx internal RTC !?
Hi there, I am using an MPC855T, external clocked with 16 MHz. Using the internal PLLs it runs at 80MHz/40Mhz. An 32.768KHZ crystal is connected to clock the MPCs internal RTC. A battery is there as well. All seems to be fine. But I realized that the RTC runs too fast. It seems to be releated to systems restarts. It tested. After 25 reboots the RTC is already SIX seconds ahead!!! rdate: Wed Jan 29 10:03:58 2003 date:Wed Jan 29 10:04:04 CET 2003 hwclock: Wed Jan 29 10:04:04 2003 0.00 seconds Any ideas? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
how to halt m8xx?
xiaogeng_jin at agilent.com schrieb: > Hi, > > I found that in m8xx the halt function is the same as the restart function > because m8xx_halt() just calls m8xx_restart() in m8xx_setup.c. If I just want > to halt the m8xx system but not to restart it automatically, what should I > do? Set a few registers and wait for ever? THanks for your thoughts. How about a while(1); ??? It worked fo me! Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
gcc-3.2 and MPC8xx
Hi there, I read that MontaVista released a 3.0 with gcc 3.2. Does it make sense to switch from 2.95.3/4 to gcc 3.2 for MPC8xx PowerPC? Are there any big advantages when building u-boot, kernel, drivers, busybox and multithreaded applications? Thanks a million, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[PATCH] m8xx_setup.c and PCMCIA
Dan Malek wrote: > Well, _almost_ isn't good enough :-) Fair enough! > I hope some of the more PCMCIA literate folks speak up here, because I > think placing IO_BASE into the mix, and certainly io_block_mapping it > is quite wrong. It may be necessary for your board, but it certainly > isn't something that is going to work on many others. All you need is > an 860 with a Tundra PCI bridge and all of these patches will fail to work. Well, that's why "&& !defined(CONFIG_PCI)"... Or? Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Definitions for c_cflag etc. in termbits.h???
Steven Scholz wrote: > > Hi there, > > I am playing around with UARTs and got completly confused when looking at > ./include/asm-ppc/termbits.h: > > E.g. the DEFINEs of c_iflags appear to me as decimal values!? > > /* c_iflag bits */ > #define IGNBRK 001 Thanks to you all! Of course it's octal. It's friday! Sorry for the noise! Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Definitions for c_cflag etc. in termbits.h???
Hi there, I am playing around with UARTs and got completly confused when looking at ./include/asm-ppc/termbits.h: E.g. the DEFINEs of c_iflags appear to me as decimal values!? /* c_iflag bits */ #define IGNBRK 001 #define BRKINT 002 #define IGNPAR 004 #define PARMRK 010 #define INPCK 020 #define ISTRIP 040 #define INLCR 100 #define IGNCR 200 #define ICRNL 400 #define IXON0001000 #define IXOFF 0002000 #define IXANY 0004000 #define IUCLC 001 #define IMAXBEL 002 So how could code like ./arch/ppc/8xx_io/uart.c: if (I_BRKINT(info->tty) || I_PARMRK(info->tty)) or ./arch/ppc/8xx_io/uart.c:#define RELEVANT_IFLAG(iflag) (iflag & (IGNBRK|BRKINT|IGNPAR|PARMRK|INPCK)) possibly work? Shouldn't that be hex values as in ./include/asm-sparc64/termbits.h: /* c_iflag bits */ #define IGNBRK 0x0001 #define BRKINT 0x0002 #define IGNPAR 0x0004 #define PARMRK 0x0008 #define INPCK 0x0010 #define ISTRIP 0x0020 #define INLCR 0x0040 #define IGNCR 0x0080 etc. ??? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
request_irq, MPX8xx, IDE, PCMCIA, ...
Hi there,
last year ide-cs was working on MPC8xx platforms.
It was necessary to define
define ide_request_irq(irq,hand,flg,dev,id)
request_8xxirq((irq),(hand),(flg),(dev),(id))
in the board specific header file.
I just relalised that on December 16 code in ide-probe was changed!!!
- if (ide_request_irq(hwif->irq, &ide_intr, sa, hwif->name,
hwgroup)) {
+ if (request_irq(hwif->irq,&ide_intr,sa,hwif->name,hwgroup)) {
Now it crashes with a "Kernel panic: request_irq".
What is the status of the request_8xxirq() vs request_irq() stuff?
BTW: Is the patch changing IN_BYTE() to hwif->INB() etc. working on MPC8xx
platforms?
Thanks a million,
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Using ioctl from with the kernel ???
Stephan Linke wrote: > > Hi Steve, > > If you realy like to do so you can call the LEDDRIVER_ioctl() function > directly with some dummy parameter (the one of you LED driver, not the one > from user space wich is to be called using an file descriptor). But I would > prefer to move the functionality into some extra function and call these > function from LEDDRIVER_ioctl() and from OTHERDRIVER_change_led() (like > Stefano suggested). Many thanks to you both. I'll try that! Good luck, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Using ioctl from with the kernel ???
Hi Stephan, > Your right IOCTL is not applicable for this. You can simply call the driver > functions directly. If these functions are called different from different > context(s) (like your driver and the IOCTL function) you have to add some > protection mechanism. (The code is not reentrant right?) You may try > spin_lock() for this job (linux/spinlock.h). If you are calling the > functions from interrupt contect too some extra protection is required... Thanks for your reply. But how could I call the ioctl handler of the driver? I would need some (dummy) inode... Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Using ioctl from with the kernel ???
Hi there, I use a device driver (/dev/status_led from DENX) to manipulate some frontpanel LEDs from user space via some ioctls. Now I'd like to access them from the kernel space. How can I do that? AFAIK I can't use fopen and ioctl... Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ELDK 2.0, glibc and kernel 2.4.20???
> >Hi guys, Hi Wolfgang, > > > >I am using ELDK 1.0 for development. Thanks for that great tool chain! > > > >Now I want to switch from 1.0 to version 2. > > > >Do I have to rebuild the glibc comming with the ELDK 2.0 to use it with > a > >2.4.19/20 kernel instead of the 2.4.4 that comes with this kit? > > This is normally not necessary. So far we have not realized any problems > > with 2.4.19 kernels. BTW: it?s the same dilemma with ELDK 1.0. > I know. I did once. And I don't want to do it again! :o) Let's say I want to use the O_DIRECT feature with files. Of course O_DIRECT is not defined in 2.4.4 but in 2.4.19. So would it be enough to define the flag O_DIRECT in my application? Since all that glibc does is passing the flags to the kernel while opening a file, doesn't it? Cheers, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ELDK 2.0, glibc and kernel 2.4.20???
Hi guys, Hi Wolfgang, I am using ELDK 1.0 for development. Thanks for that great tool chain! Now I want to switch from 1.0 to version 2. Do I have to rebuild the glibc comming with the ELDK 2.0 to use it with a 2.4.19/20 kernel instead of the 2.4.4 that comes with this kit? Thanks, Steven ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
