* Re: RFC: cpm2_devices.c
From: Kumar Gala @ 2005-06-16 15:53 UTC (permalink / raw)
To: Allen Curtis; +Cc: linuxppc-embedded
In-Reply-To: <c8a775fb36a415f9b45ed713e4c63caa@onz.com>
> So have we answered your question regarding the inclusion of DMA and
> CPM in the platform_device array? If I am reading this correctly, all
> the individual CPM "objects" should be defined in the device structure
> with their physical address location defined. The complete IMMAP
> structure can then be constructed from these objects if required.
Actually, I dont feel that anyone has given a reason why or how they
would use CPM, DMA, SI1, SI2 if they were platform devices.
> Is it possible to add some flags to the IORESOURCE information to
> address the differences in SCC structures between processor types?
> Perhaps something like this could be used to apply the correct
> structure cast in the device driver. Just a thought...
I envisioned this being a field in the platform_data structures for the
devices.
- kumar
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Allen Curtis @ 2005-06-16 15:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <678305db5ee1488bb48a26a4a89c121a@freescale.com>
> If I understand you correctly this is not any different than how we
> handle the TSEC (gianfar) on 85xx. The platform device structure just
> gives us physical address (start & end) and IRQs and we use a
> structure in the driver that maps to the start address.
>
> - kumar
>
So have we answered your question regarding the inclusion of DMA and
CPM in the platform_device array? If I am reading this correctly, all
the individual CPM "objects" should be defined in the device structure
with their physical address location defined. The complete IMMAP
structure can then be constructed from these objects if required.
Is it possible to add some flags to the IORESOURCE information to
address the differences in SCC structures between processor types?
Perhaps something like this could be used to apply the correct
structure cast in the device driver. Just a thought...
-- Allen
>> Having just converted an different SoC part from using offsets to data
>> structures, I have to say that tables/defines of offsets are more of a
>> mess
>> than a data structure. We don't have to define the whole of the
>> IMMAP,
>> but
>> using the data structures for the individual device spaces is quite
>> effective.
>> The advantage of using the data structure is it also conveys the data
>> type
>> size, adding a level error checking. I also dislike io accessor
>> functions/macros,
>> especially on these processor specific devices.
>>
>>
>> Thanks.
>>
>> -- Dan
>
>
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Kumar Gala @ 2005-06-16 15:33 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <0fc7d3f2fe1266cdd0beaf44a71bc27c@embeddededge.com>
Dan,
If I understand you correctly this is not any different than how we
handle the TSEC (gianfar) on 85xx. The platform device structure just
gives us physical address (start & end) and IRQs and we use a structure
in the driver that maps to the start address.
- kumar
> Having just converted an different SoC part from using offsets to data
> structures, I have to say that tables/defines of offsets are more of a
> mess
> than a data structure. We don't have to define the whole of the IMMAP,
> but
> using the data structures for the individual device spaces is quite
> effective.
> The advantage of using the data structure is it also conveys the data
> type
> size, adding a level error checking. I also dislike io accessor
> functions/macros,
> especially on these processor specific devices.
>
>
> Thanks.
>
> -- Dan
^ permalink raw reply
* Re: MPC5200/Lite5200 and ethernet
From: Esben Nielsen @ 2005-06-16 15:24 UTC (permalink / raw)
To: Andrey Volkov; +Cc: linuxppc-embedded
In-Reply-To: <42B181F3.2090901@varma-el.com>
On Thu, 16 Jun 2005, Andrey Volkov wrote:
> Hi Esben
>
> Esben Nielsen wrote:
> > How do I turn on the in chip FEC ethernet controller in MPC5200 in the
> > stock 2.6.12-rc6 kernel? Do I need an extra patch?
> >
> take patch here:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-April/017591.html
>
> But, since bestcomm still not converted to platform_bus/ppc_sys model,
> it will not be included in vanilla 2.6.12 kernel.
>
I managed to get something out of the bitkeeper tree referred to from
http://www.246tnt.com/mpc52xx/
It seems to be based on 2.6.10-rc2 right now - good enough for now.
Is that really the latest version now?
What happens when bitkeeper is gone (very soon now, right?)
To whom do I submit patches?
Esben
> --
> Regards
> Andrey Volkov
>
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Dan Malek @ 2005-06-16 15:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <a38c1fefe53947c6b80ec3d6b4ffd09e@freescale.com>
On Jun 15, 2005, at 12:13 AM, Kumar Gala wrote:
>> 2. I am torn about using numeric IMMR offsets vs. the structure member
>> approach. The good thing is that you can create all the devices in a
>> single table even if they overlay depending on processor. The question
>> is, will the IMMAP structure become obsolete? If not, then you will
>> still need the conditional compiles in immap_cpm2.h.
>
> I'm trying to stay away from basing things on the structure. Since
> the offsets are truly fixed I see not reason to try to make sure that
> the immap structure is always correct for all cases.
Having just converted an different SoC part from using offsets to data
structures, I have to say that tables/defines of offsets are more of a
mess
than a data structure. We don't have to define the whole of the IMMAP,
but
using the data structures for the individual device spaces is quite
effective.
The advantage of using the data structure is it also conveys the data
type
size, adding a level error checking. I also dislike io accessor
functions/macros,
especially on these processor specific devices.
Thanks.
-- Dan
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Kumar Gala @ 2005-06-16 15:02 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <42B11F5B.2050706@intracom.gr>
I'm not sure I follow on what you want done. I done see the
pq2_device.c file changing much once we put it in place. If there is a
little duplication between pq1_device.c, pq2_device.c and
mpc85xx_device.c I'm not to concerned about it since the only
information in there is memory offsets and IRQs.
If the structures for an SCC uart driver are the same for PQ1 and PQ2
then I would expect the SCC uart driver to handle that fact going
forward.
- kumar
On Jun 16, 2005, at 1:42 AM, Pantelis Antoniou wrote:
> Let me hop in here...
>
> Have you thought about breaking up the structures per
> cpm peripheral?
>
> Some registers are unique for each processor family, but
> others are (almost) common to all.
>
> For example SCC parameters & stuff are the same on 8xx/82xx ...
>
> IMHO keeping one definition in the tree for these will make
> keeping them in sync easier.
>
> Then the main header file will be the definitions of the
> unique registers, a number of defines for the structures offsets
> and a list of included files for the common peripherals...
>
> Regards
>
> Pantelis
^ permalink raw reply
* Re: MPC5200/Lite5200 and ethernet
From: Andrey Volkov @ 2005-06-16 13:43 UTC (permalink / raw)
To: Esben Nielsen; +Cc: linuxppc-embedded
In-Reply-To: <Pine.OSF.4.05.10506160040020.28990-100000@da410.phys.au.dk>
Hi Esben
Esben Nielsen wrote:
> How do I turn on the in chip FEC ethernet controller in MPC5200 in the
> stock 2.6.12-rc6 kernel? Do I need an extra patch?
>
take patch here:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-April/017591.html
But, since bestcomm still not converted to platform_bus/ppc_sys model,
it will not be included in vanilla 2.6.12 kernel.
--
Regards
Andrey Volkov
^ permalink raw reply
* RE: 2.4.26 and MPC885 context switching time
From: Steven Blakeslee @ 2005-06-16 14:03 UTC (permalink / raw)
To: Schaefer-Hutter, Peter, linuxppc-embedded
> Therefore i wonder, if there are any known problems with the=20
> MMU on 8xx and 2.4.2x which might explain that?=20
>=20
I did some work on an 885 with Linux 2.4.22. I found that when the
processor was running at 100MHz or higher Linux would die when
decompressing the ramdisk. Below 100MHz it would run fine. I came up
with a hacky fix because I mis-read an errata notice. What I did was
set the ICTRL register to 0x00000001, this fixed the problem. Basically
all this does is slow the processor down considerable. The Linux you
have may be doing the same thing. This could explain the performance
hit you are seeing.
^ permalink raw reply
* [newbie]: mpc8260 kernel opps sig 7 and 11 please help!
From: eagle keeper @ 2005-06-16 13:58 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
since i'm hanged with this problem since 2 weeks ago... and i can't
solve it, i wonder if anyone
of you have any idea to suggest me.
I'm working on an mpc8260 and used ELDK to develop u-boot and kernel.
Actually I'm using ads8260_defoconfig configuration file to make the
kernel image.
I am absolutely a newbie and don't know where to start from. Any hael
would be appreciated.
This is the output I have:
--------------
## Booting image at 00100000 ...
Image Name: mercurio --- 10001 - Thu Jun
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 490783 Bytes =3D 479.3 kB
Load Address: 00200000
Entry Point: 00200000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory BAT mapping: BAT2=3D16Mb, BAT3=3D0Mb, residual: 0Mb
Linux version 2.4.25 (root@mercurio) (gcc version 3.3.3 (DENX ELDK 3.1.1 3.=
3.3-9
)) #2 Thu Jun 16 11:49:57 CEST 2005
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=3D/dev/nfs rw nfsroot=3D141.137.67.254:/provaFS i=
p=3D141.137
.67.253:141.137.67.254:141.137.67.100:255.255.255.0:priscilla::off
Warning: real time clock seems stuck!
Calibrating delay loop... 79.87 BogoMIPS
Memory: 15012k available (848k kernel code, 280k data, 40k init, 0k highmem=
)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
CPM UART driver version 0.01
ttyS0 on SCC1 at 0x8000, BRG7
ttyS1 on SCC2 at 0x8100, BRG1
Serial driver version 5.05c (2001-07-08) with no serial options enabled
Oops: kernel access of bad area, sig: 11
NIP: C007150C XER: 00000000 LR: C0075CAC SP: C0173E90 REGS: c0173de0 TRAP: =
0300
Not tainted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 000003F9, DSISR: 20000000
TASK =3D c0172000[1] 'swapper' Last syscall: 120
last math 00000000 last altivec 00000000
GPR00: 00000000 C0173E90 C0172000 C0173EA0 00000001 00000008 C00D622C 00000=
3F8
GPR08: 00000000 000003F8 00000000 10000000 0000000D 7FFFFFFF 00FF5000 007FF=
F7D
GPR16: 00200000 007FFF00 00FF8A30 00000000 003FF000 00000001 00BC3588 00FFF=
25C
GPR24: 00000000 00123238 C0100000 C0173EA0 00000001 C01137C4 00000000 C00EF=
414
Call backtrace:
00123238 C00FD5F8 C00F75CC C00039D0 C0007FD8
Kernel panic: Attempted to kill init!
<0>Rebooting in 180 seconds..Machine check in kernel mode.
sCaubed fy ( rom1SRR0=3D41:00)
-------------
did you ever verified somewhat like this?
Specially about "sig 11" what is caused by?
Since I believed it was caused by serial driver, when I tried to
disable it I got a very similar error:
Initializing RT netlink socket
...
Machine check in kernel mode.
Caused by (from SRR1=3D49030): Transfer error ack signal
Oops: machine check, sig: 7
...
Thanks in advance, and sorry for wasting your time
Lele
^ permalink raw reply
* Re: jffs2 freezing in gc for long time...
From: David Jander @ 2005-06-16 13:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <WorldClient-F200506161512.AA12150000@t2data.se>
On Thursday 16 June 2005 15:12, Per Hallsmark wrote:
> A hot tip would be to configure either syslog to log to a logserver
> or at least mount a tmpfs filesystem on /var/log.
We do this already.... the old way, with a ramdisk mounted on /var, and the
rw-jffs2 partition mounted on /flash, then /var/log/xxx is a link to a
directory in /flash/log/, where I place "persistent" log files.
/var/log/messages and friends reside on the ramdisk only.
/tmp is a symlink to /var/tmp.
Well, the use of tmpfs is indeed easier, so thanks anyway for the tip.
> Running a syslog could wear out the flash quite quickly, especially
> during the development phases...
That's true, but we need some logfiles (logged via syslogd) to be persistent
and survive reboots at any moment, but we can't afford a system freeze just
because the GC-routine needs to run.
I still need to study syslogd, to see what it does when writing becomes
blocked for a long time. Does syslogd buffer? For how much data? Will I loose
data in the end or will the calling process hang?
If someone has experience with this, and knows the answer to some of these
questions, I'd be glad to hear it.
Greetings,
--
David Jander
^ permalink raw reply
* Re: jffs2 freezing in gc for long time...
From: Per Hallsmark @ 2005-06-16 13:12 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <200506161456.44420.david.jander@protonic.nl>
Hi David,
A hot tip would be to configure either syslog to log to a logserver
or at least mount a tmpfs filesystem on /var/log.
Running a syslog could wear out the flash quite quickly, especially
during the development phases...
While you are at it, mount tmpfs's on /tmp and /var as well.
I believe JFFS2 suits very well in a embedded device, the system
just need to be configured for a such, since a "standard" linux
installation are more outlined for server/desktop usage ;-)
Regards,
Per
-----Original Message-----
From: David Jander <david.jander@protonic.nl>
To: "'linuxppc-embedded@ozlabs.org'" <linuxppc-embedded@ozlabs.org>
Date: Thu, 16 Jun 2005 14:56:43 +0200
Subject: jffs2 freezing in gc for long time...
>
> Hi list,
>
> I have the following situation:
>
> CPU: MPC852T-100MHz
> Flash: 32Mbyte mirror-bit, 15Mbyte jffs2 partition rw-mouted
> Kernel: 2.4.25 (linuxppc_2_4_devel CVS from denx from a month ago or
> so, with
> custom patches not concerning MTD at all). For completeness, it
> contains the
> file fs/jffs2/gc.c version: gc.c,v 1.145 2005/02/09 09:09:01
>
> Sometimes, I get this:
> During boot, mounting is quick, but when starting syslogd, it freezes
> for some
> 20 minutes, then syslogd returns an error (exit!=0) but the daemon
> keeps
> running in background, as well as the garbage collection thread from
> jffs2
> for some additional minutes. During that time, everything like "ls -l"
> on a
> certain directory of the flash partition freezes (status D is ps aux)
> until
> the GC thread has finished.
>
> I can understand that GC has to occur at some time, but is it normal
> that it
> takes THAT long???
>
> Is there a newer version of the MTD driver that does not present these
> symptoms?
>
> If this is supposed to work like that, I would say jffs2 is pretty
> useless for
> any embedded system, so it is not supposed to be like that, right?
> RIGHT??
>
> What am I doing wrong? Is the flash partition too big? Shouldn't I be
> using
> jffs2?
>
> Any advice is appreciated...
>
> Greetings,
>
> --
> David Jander
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* jffs2 freezing in gc for long time...
From: David Jander @ 2005-06-16 12:56 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
Hi list,
I have the following situation:
CPU: MPC852T-100MHz
Flash: 32Mbyte mirror-bit, 15Mbyte jffs2 partition rw-mouted
Kernel: 2.4.25 (linuxppc_2_4_devel CVS from denx from a month ago or so, with
custom patches not concerning MTD at all). For completeness, it contains the
file fs/jffs2/gc.c version: gc.c,v 1.145 2005/02/09 09:09:01
Sometimes, I get this:
During boot, mounting is quick, but when starting syslogd, it freezes for some
20 minutes, then syslogd returns an error (exit!=0) but the daemon keeps
running in background, as well as the garbage collection thread from jffs2
for some additional minutes. During that time, everything like "ls -l" on a
certain directory of the flash partition freezes (status D is ps aux) until
the GC thread has finished.
I can understand that GC has to occur at some time, but is it normal that it
takes THAT long???
Is there a newer version of the MTD driver that does not present these
symptoms?
If this is supposed to work like that, I would say jffs2 is pretty useless for
any embedded system, so it is not supposed to be like that, right? RIGHT??
What am I doing wrong? Is the flash partition too big? Shouldn't I be using
jffs2?
Any advice is appreciated...
Greetings,
--
David Jander
^ permalink raw reply
* Adding RapidIO to Linux
From: Avni Hillel-R58467 @ 2005-06-16 10:44 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'; +Cc: Kardonik Michael-R58108
[-- Attachment #1: Type: text/plain, Size: 293 bytes --]
Hi Matt,
I want to install:
[PATCH][1/3] RapidIO support: core
[PATCH][2/3] RapidIO support: ppc32
[PATCH][3/3] RapidIO support: net driver over messaging
1. What specific version of Linux should I start from?
2. Are there any more patches that are relevant to RIO?
Thanks,
Hillel
[-- Attachment #2: Type: text/html, Size: 1806 bytes --]
^ permalink raw reply
* Re: Error while opennig device file
From: Marcin Dawidowicz @ 2005-06-16 9:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Garcia Jérémie
In-Reply-To: <D4FDDD1349B5AC46B68FC26AD8AF42D6226B38@exnet.3il.fr>
On Thursday 16 of June 2005 10:35, Garcia J=E9r=E9mie wrote:
> static int test_open(struct inode *inode , struct file *file)
> {
> int ret_val =3D 0;
>
> if (Device_open !=3D 0) <------
> return -EBUSY; <------
>
> Device_open++; <------
> printk("%d minor number!\n",MINOR(inode->i_rdev));
> MOD_INC_USE_COUNT;
>
> return ret_val;
> }
>
> Very traditionnal...
>
Have a look on marked lines.
> What error do you get on second open?
> --> I trace the execution of my programm and get the following :
> First opened succeeded, open() return code : 3 =A0 =A0
> Can't open second file, open() return code : -1 , errno =3D 16
>
> Looking in the errno.h, we have :
> #define=A0EBUSY=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A016=A0=A0=A0=A0=A0=A0/* De=
vice or resource busy */
This is what I would expect. You can remove marked lines and try again...
Regards,
Marcin
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Wolfgang Denk @ 2005-06-16 9:33 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <42B11F5B.2050706@intracom.gr>
In message <42B11F5B.2050706@intracom.gr> you wrote:
> Let me hop in here...
>
> Have you thought about breaking up the structures per
> cpm peripheral?
I complained about this a long time ago (when Kumar's patches were
checked in for 2.4.26 which broke compatibility between 8xx and 8260
systems).
> Some registers are unique for each processor family, but
> others are (almost) common to all.
It would indeed be beneficial if common parts used common definitions
and names.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
When you die, the first thing you lose is your life. The next thing
is the illusions. - Terry Pratchett, _Pyramids_
^ permalink raw reply
* RE : RE : Error while opennig device file
From: Garcia Jérémie @ 2005-06-16 9:20 UTC (permalink / raw)
To: Dustin Lang, Eugene Surovegin; +Cc: linuxppc-dev
Ok here we go, I'm sorry for that but it's always the most enormous =
thing that are missed.
Indeed, I do return a EBUSY when more that one process has opened the =
device driver.
So I'm really sorry for disturbing you for that since I had many other =
real hard problems in Linux
before.=20
I think I'm getting Linux-parano=EF...
Tks again and have a nice day
-------- Message d'origine--------
De: Dustin Lang [mailto:dalang@cs.ubc.ca]
Date: mer. 15/06/2005 20:16
=C0: Eugene Surovegin
Cc: Garcia J=E9r=E9mie; linuxppc-dev@ozlabs.org
Objet : Re: RE : Error while opennig device file
=20
Also - does it work from the command line? Do both mknod commands work? =
When you "ls -l /dev/test{1,2}" , what do you get? What happens when =
you=20
"cat /dev/test1" or "echo > /dev/test1" ?
Cheers,
dstn.
>> I'm sorry but this is a "copy to mail" error.
>> Here is the right code:
>>
>> ret_val =3D system("mknod -m 777 /dev/test1 c 122 1");
>> ret_val =3D system("mknod -m 777 /dev/test2 c 122 2");
>>
>> file_desc1 =3D open("/dev/test1", O_RDWR);
>> file_desc2 =3D open("/dev/test2", O_RDWR);
^ permalink raw reply
* Re: sub-module loading (was: Anyone got drivers/mtd/maps/pm828.c?)
From: Clemens Koller @ 2005-06-16 8:47 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linux-mtd, linuxppc-embedded
In-Reply-To: <20050615145434.315a4b94.ajz@cambridgebroadband.com>
Hi, Alex...
good to know, that you made good progress. :-)
I just X-post this to linux-mtd so maybe somebody can have a look
at your issue, too.
I also experienced "problems" with sub-module-loading. Or maybe
I just missed something:
I need to load mtdchar and map_ram separately in order to be
able to probe my mminfo.ko module to access/mess some
SRAM in my FPGA on a MPC8540. I didn't care about that yet,
but maybe there are missing dependencies which can be solved
automagically here. Or is the sub-module loading supposed to
work like this (well, manual) as somebody might want to choose
in between i.e. mtdblock and/or mtdchar?
I'm talking about the Kernel 2.6.11.11 mtd subsystem.
Best greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Alex Zeffertt wrote:
> Hi Clemens,
>
> Thanks for your help. I've done it now (see attached). The
> partitioning is specific to our application but it is easily modified.
>
> I noticed a buggette in the mtd code while doing this. If you build
> everything as a module then the sub-module loading doesn't work
> properly. For example in gen_probe.c it says
>
> #ifdef CONFIG_MTD_CFI_INTELEXT
> case 0x0001:
> case 0x0003:
> return cfi_cmdset_0001(map, primary);
> #endif
>
> where it should really say
>
> #if defined(CONFIG_MTD_CFI_INTELEXT) ||
> defined(CONFIG_MTD_CFI_INTELEXT_MODULE)
> case 0x0001:
> case 0x0003:
> return cfi_cmdset_0001(map, primary);
> #endif
>
> There are several problems like this. In the end I gave up and just
> built everything except the actual mapping driver as kernel resident.
>
> Alex
>
>
> On Wed, 15 Jun 2005 15:18:37 +0200
> Clemens Koller <clemens.koller@anagramm.de> wrote:
>
>
>>Hi, Alex!
>>
>>Hmm, I don't know the PM828 much in detail, but have you
>>tried the "generic" physmap driver which is in the kernel?
>>Just give it the base address and the size, and it should
>>probe the cfi and you are done (well, it was working fine
>>for me on my PM854).
>>Of course, you need to make sure, that your hardware / memory
>>mapping is initialized properly (which happens usually in the
>>boot loader). If it's not, let me know and I can give you
>>some code to mess around with the registers in a kernel module.
>>
>>Best greets,
>>
>>Clemens Koller
>>_______________________________
>>R&D Imaging Devices
>>Anagramm GmbH
>>Rupert-Mayer-Str. 45/1
>>81379 Muenchen
>>Germany
>>
>>http://www.anagramm.de
>>Phone: +49-89-741518-50
>>Fax: +49-89-741518-19
>>
>>
>>Alex Zeffertt wrote:
>>
>>>Hi there,
>>>
>>>I need to get flash partitions working on my PM828 development
>>>board. Has anybody already written a pm828.c? If so I'd appreciate
>>>a look at it.
>>>
>>>TIA,
>>>
>>>Alex
>>>_______________________________________________
>>>Linuxppc-embedded mailing list
>>>Linuxppc-embedded@ozlabs.org
>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
^ permalink raw reply
* RE : RE : Error while opennig device file
From: Garcia Jérémie @ 2005-06-16 8:35 UTC (permalink / raw)
To: Dustin Lang, Eugene Surovegin; +Cc: linuxppc-dev
Hi everybody! I'm gonna give you all the info you asked me:
[Dustin]
>> does it work from the command line? Do both mknod commands work?
--> Yes both mknod seem to work from the command line since they are =
both created
root@10.16.9.232:~# mknod -m 777 /dev/test1 c 122 1
root@10.16.9.232:~# mknod -m 777 /dev/test2 c 122 2 =20
That looks good
>> When you "ls -l /dev/test{1,2}" , what do you get?=20
--> root@10.16.9.232:~# ls -l /dev/test{1,2}
crwxrwxrwx 1 root root 122, 1 Jun 16 2005 /dev/test1
crwxrwxrwx 1 root root 122, 2 Jun 16 2005 /dev/test2
That looks good
>> What happens when you "cat /dev/test1" ?
--> root@10.16.9.232:~# cat /dev/test1
cat: /dev/test1: No such device
That is ok, isn't it?
>> What happens when you "echo > /dev/test1" ? =20
--> root@10.16.9.232:~# echo > /dev/test1
bash: /dev/test1: No such device
That is ok, isn't it?
[Eugene]
>> How does open routine for your device look like?
-->
static int test_open(struct inode *inode , struct file *file)
{
int ret_val =3D 0;
=20
if (Device_open !=3D 0)
return -EBUSY;
=20
Device_open++;
printk("%d minor number!\n",MINOR(inode->i_rdev)); =20
MOD_INC_USE_COUNT;
return ret_val;
}
Very traditionnal...
>> What error do you get on second open?
--> I trace the execution of my programm and get the following :
First opened succeeded, open() return code : 3 =20
Can't open second file, open() return code : -1 , errno =3D 16
Looking in the errno.h, we have :
#define EBUSY 16 /* Device or resource busy */
If tou need more tell me.
Tks again for your help guys!
-------- Message d'origine--------
De: Dustin Lang [mailto:dalang@cs.ubc.ca]
Date: mer. 15/06/2005 20:16
=C0: Eugene Surovegin
Cc: Garcia J=E9r=E9mie; linuxppc-dev@ozlabs.org
Objet : Re: RE : Error while opennig device file
=20
Also - does it work from the command line? Do both mknod commands work? =
When you "ls -l /dev/test{1,2}" , what do you get? What happens when =
you=20
"cat /dev/test1" or "echo > /dev/test1" ?
Cheers,
dstn.
>> I'm sorry but this is a "copy to mail" error.
>> Here is the right code:
>>
>> ret_val =3D system("mknod -m 777 /dev/test1 c 122 1");
>> ret_val =3D system("mknod -m 777 /dev/test2 c 122 2");
>>
>> file_desc1 =3D open("/dev/test1", O_RDWR);
>> file_desc2 =3D open("/dev/test2", O_RDWR);
^ permalink raw reply
* Re: preemptive and low-latency patches for denx's 2.4.25
From: Samuel Osorio Calvo @ 2005-06-16 8:20 UTC (permalink / raw)
To: jjboor; +Cc: linuxppc-embedded
Jon Diekema already sent me the low-latency patch but it's also good to =
have more than one alternative, so this diff would be really great!!!!!
Thanks!!!
Samuel.
Unclassified.
>>> Jaap-Jan Boor <jjboor@aimsys.nl> 06/15/05 03:56PM >>>
I have a patched 2.4.25 kernel with changes from the Denx kernel, the =20
lck1 patchset (O(1) scheduler, preempt and lowlatency patches), linux =20
trace toolkit patches (sort of handcrafted) and proprietary board =20
specific patches.
It's probably incompatible with anything else. I can however make a =20
patch against 2.4.25 vanilla for you.
Jaap-Jan
On 15-jun-2005, at 15:20, Samuel Osorio Calvo wrote:
> Hi all,
>
> Do any of you know where to find these patches for kernel 2.4.25 =20
> coming with ELDK's v.3.1.1?
> I've seen the RTAI patch for it but nothing about preemptive or low-=20
> latency.. Will patches from "standard" distribution's kernels be =20
> compatible?? If so, would you, please, provide a link.....;-)
>
> Thanks a lot,
>
> Samuel.
>
> Unclassified.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org=20
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded=20
>
____
J.G.J. Boor Anton Philipsweg 1
Software Engineer 1223 KZ Hilversum
AimSys bv tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum jjboor at aimsys dot nl
^ permalink raw reply
* More dtc changes
From: David Gibson @ 2005-06-16 7:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-embedded, u-boot-users,
linuxppc-dev list, linuxppc64-dev
I now have a git tree for the device tree compiler up at
http://www.ozlabs.org/~dgibson/dtc/dtc.git
Notable changes since the last tarball release:
- Elementary support for labels. Labels can go on nodes or
properties in the source tree and are exported to assembler output as
usable symbols
- phandle reference support. Cell data (< .. >) can include
references of the form &/path/to/some/node and will be replaced in the
output tree with the output node's phandle. A phandle will be
generated for the target node if it doesn't already have one.
There's a tarball release as well
http://www.ozlabs.org/~dgibson/dtc/dtc.tar.gz
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Pantelis Antoniou @ 2005-06-16 6:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <7e2a8c0e483e5dfdc532c47d20776bbd@freescale.com>
Let me hop in here...
Have you thought about breaking up the structures per
cpm peripheral?
Some registers are unique for each processor family, but
others are (almost) common to all.
For example SCC parameters & stuff are the same on 8xx/82xx ...
IMHO keeping one definition in the tree for these will make
keeping them in sync easier.
Then the main header file will be the definitions of the
unique registers, a number of defines for the structures offsets
and a list of included files for the common peripherals...
Regards
Pantelis
^ permalink raw reply
* Re: 2.4.26 and MPC885 context switching time
From: Dan Malek @ 2005-06-16 1:21 UTC (permalink / raw)
To: Schaefer-Hutter, Peter; +Cc: linuxppc-embedded
In-Reply-To: <8E342283C2100540AAC5D1030970547766F7B1@rcexc.racoms.loc>
On Jun 15, 2005, at 11:43 AM, Schaefer-Hutter, Peter wrote:
> I basically used the two programs from
> http://www.ibm.com/developerworks/linux/library/l-rt9/
That's a fine test, if you run it on various systems and
compare the _relative_ results. There is more than
context switching going on here.
.... there aren't any MMU "problems" with the 8xx, it's
likely to be the most efficient implementation of all
systems that use software to support the MMU. The
processor in general is very sensitive to many system
architecture decisions, especially the system bus
and DRAM configuration. Make certain you really
understand what you have configured and how the
tests you run are affected by that.
Thanks.
-- Dan
^ permalink raw reply
* Re: multicast disabled on 8260_io/fcc_enet.c
From: Dan Malek @ 2005-06-16 1:03 UTC (permalink / raw)
To: Samuel Osorio Calvo; +Cc: linuxppc-embedded
In-Reply-To: <s2b045ef.027@scms1.sc.signaal.nl>
On Jun 15, 2005, at 9:14 AM, Samuel Osorio Calvo wrote:
> Currently I have multicast working just be moving the return
> statement. It seems to work but I guess I did not face yet the
> problems that caused the code to be commented.
> Let's say it works in an unreliable way....
When I wrote the original code I copied the old SCC driver and didn't
have
a function for computing CRCs, so I just placed the return early in the
function.
I believe there is a patch floating around that wrote a CRC function
(or used some
existing one), to compute the filter mask. If the code has a CRC
function call,
then it will likely work. If it doesn't have one, then you are running
on luck. Either
the proper filter bit is set by some random reset bits, or you somehow
get the
right one set. By default, the multicast filter may just catch
everything, forcing
the Linux IP stack to do the filtering at a higher level, not exactly
what you want. :-)
This has been discussed many times in the past.
Thanks.
-- Dan
^ permalink raw reply
* MPC5200/Lite5200 and ethernet
From: Esben Nielsen @ 2005-06-15 22:41 UTC (permalink / raw)
To: linuxppc-embedded
How do I turn on the in chip FEC ethernet controller in MPC5200 in the
stock 2.6.12-rc6 kernel? Do I need an extra patch?
Esben
^ permalink raw reply
* Re: 2.4.26 and MPC885 context switching time
From: Wolfgang Denk @ 2005-06-15 23:38 UTC (permalink / raw)
To: Jaap-Jan Boor; +Cc: Schaefer-Hutter, Peter, linuxppc-embedded
In-Reply-To: <187119B8-515D-4903-AAB5-05BF80215A4D@aimsys.nl>
In message <187119B8-515D-4903-AAB5-05BF80215A4D@aimsys.nl> you wrote:
> I did once ran lmbench on a proprietry 850 based board running at
> 62/31 Mhz using 1 16-bit dram:
>
> Context switching - times in microseconds - smaller is better
> -------------------------------------------------------------
> Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/
> 64K
> ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
> ctxsw
> --------- ------------- ----- ------ ------ ------ ------ -------
> -------
> test Linux 2.4.25- 259.2 234.2 302.6 304.7
>
> This is ~ 3x faster then your 100Mhz 885...
I just ran lmbench on a MPC866 system (CPU at 132 MHz, bus at 66 MHz):
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ------ ------ ------ ------ ------ ------- -------
tqm8xx Linux 2.4.25 5.4500 27.5 30.3 39.0 36.0 37.7 33.5
There is definitely something wrong with Peter's measurements.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Quantum particles: The dreams that stuff is made of.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox