* 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: MPC5200/Lite5200 and ethernet
From: Andrey Volkov @ 2005-06-16 16:00 UTC (permalink / raw)
To: Esben Nielsen; +Cc: Sylvain Munaut, linuxppc-embedded
In-Reply-To: <Pine.OSF.4.05.10506161721010.24601-100000@da410.phys.au.dk>
Esben Nielsen wrote:
> 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?
AFAIK almost all patches from http://www.246tnt.com/mpc52xx/ now in
vanilla kernel. Except, bestcomm, certainly :(.
> What happens when bitkeeper is gone (very soon now, right?)
>
> To whom do I submit patches?
Quotation from linux/MAINTAINERS :) :
LINUX FOR POWERPC EMBEDDED MPC52XX
P: Sylvain Munaut
M: tnt@246tNt.com
W: http://www.246tNt.com/mpc52xx/
W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
L: linuxppc-embedded@ozlabs.org
S: Maintained
>
> Esben
>
--
Regards
Andrey Volkov
P.S. Sylvain, what did you planned do with bk/git problem?
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Allen Curtis @ 2005-06-16 16:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <e763199be1cca62d14cf4d0011b5f6e0@freescale.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.
>
Think about the breaking up of the immap structure into little pieces
with offsets defined in platform_devices.... This is how I read the
previous conversation.
>> 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.
>
Then you envision a device specific structure for each platform_device,
even if the sole purpose is to convey version information? Ok...
- Allen
^ permalink raw reply
* Re: MPC5200/Lite5200 and ethernet
From: Grant Likely @ 2005-06-16 17:35 UTC (permalink / raw)
To: avolkov; +Cc: linuxppc-embedded
In-Reply-To: <42B1A214.404@varma-el.com>
On 6/16/05, Andrey Volkov <avolkov@varma-el.com> wrote:
> AFAIK almost all patches from http://www.246tnt.com/mpc52xx/ now in
> vanilla kernel. Except, bestcomm, certainly :(.
FEC is missing too.
Is anybody even working on bestcomm at the moment?
Cheers,
g.
^ permalink raw reply
* RFC cpm2_devices DPRAM resource
From: Allen Curtis @ 2005-06-16 17:45 UTC (permalink / raw)
To: Ppc Embedded
Slightly different question than the current thread:
Should the DPRAM appear as it's own platform_device?
Option 1) Specify the portion of the DPRAM used by each device with
that platform_device definition. (current)
Option 2) Define the whole DPRAM region as its own platform_device
entry. Move the device DPRAM information to the device specific
platform structure.
Would this help with a general dpalloc() implementation? It would
reduce the number of ioremap() regions.
Another thought.
^ permalink raw reply
* Re: RFC cpm2_devices DPRAM resource
From: Kumar Gala @ 2005-06-16 17:58 UTC (permalink / raw)
To: Allen Curtis; +Cc: Ppc Embedded
In-Reply-To: <ecc06b51023e6ebd23d075aa3948749e@onz.com>
On Jun 16, 2005, at 12:45 PM, Allen Curtis wrote:
> Slightly different question than the current thread:
>
> Should the DPRAM appear as it's own platform_device?
> Option 1) Specify the portion of the DPRAM used by each device with
> that platform_device definition. (current)
>
> Option 2) Define the whole DPRAM region as its own platform_device
> entry. Move the device DPRAM information to the device specific
> platform structure.
>
> Would this help with a general dpalloc() implementation? It would
> reduce the number of ioremap() regions.
Well, we already have an allocator for general dpram memory. I'm not
really sure how this would help beyond reducing the fact that we may
ioremap() regions more than once. I think the better solution there is
to look at the patches that have been made to ioremap() to return the
same virtual addresses if you are remapping a region of physical memory
that already has a mapping.
- kumar
^ permalink raw reply
* Re: RFC cpm2_devices DPRAM resource
From: Allen Curtis @ 2005-06-16 18:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: Ppc Embedded
In-Reply-To: <1278c2c53202b80080519cca60bb438f@freescale.com>
>> Slightly different question than the current thread:
>>
>> Should the DPRAM appear as it's own platform_device?
>> Option 1) Specify the portion of the DPRAM used by each device with
>> that platform_device definition. (current)
>>
>> Option 2) Define the whole DPRAM region as its own platform_device
>> entry. Move the device DPRAM information to the device specific
>> platform structure.
>>
>> Would this help with a general dpalloc() implementation? It would
>> reduce the number of ioremap() regions.
>
> Well, we already have an allocator for general dpram memory. I'm not
> really sure how this would help beyond reducing the fact that we may
> ioremap() regions more than once. I think the better solution there
> is to look at the patches that have been made to ioremap() to return
> the same virtual addresses if you are remapping a region of physical
> memory that already has a mapping.
>
I guess my thought regarding the dpalloc() statement is that those
functions could query the platform_device structure to find the region
they are managing. Make them a little more general.
^ permalink raw reply
* Re: MPC5200/Lite5200 and ethernet
From: Andrey Volkov @ 2005-06-16 18:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc05061610352d56cd49@mail.gmail.com>
Grant Likely wrote:
> On 6/16/05, Andrey Volkov <avolkov@varma-el.com> wrote:
>
>>AFAIK almost all patches from http://www.246tnt.com/mpc52xx/ now in
>>vanilla kernel. Except, bestcomm, certainly :(.
>
> FEC is missing too.
>
> Is anybody even working on bestcomm at the moment?
It may be Dale Farnsworth or smb. quietly in Freescale.
>
> Cheers,
> g.
>
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: RFC: cpm2_devices.c
From: Dan Malek @ 2005-06-16 19:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <678305db5ee1488bb48a26a4a89c121a@freescale.com>
On Jun 16, 2005, at 11:33 AM, Kumar Gala wrote:
> 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.
Yes, that's correct. However, some of the other devices may be more
challenging, since the set up SCC ports involves accessing multiple
areas of the CPM (parameter ram, device control, BRGs, serial mux,
TDM, etc), for example. This is why I created the whole immap structure
in the first place. With a single pointer to it, plus knowing the usage
of the device, I could easily get to all of the necessary spaces.
Using the resource reservation isn't always appropriate either, because
there are lots of shared registers or device spaces in the CPM. It
may keep you from multiply using a specific SCC, but there are many
other places requiring configuration that are more likely to be
improperly configured by other drivers.
Also, I'm not a fan of the gfar_read/write functions because I never
know their implementation :-) They use the in/out macros which I
never know if they are for PCI IO or not. We aren't using any
pipeline synchronization, which we may need. By the way, I do like
using separate synchronization, not hidden in the in/out functions.
Thanks.
-- Dan
^ permalink raw reply
* Re: RFC cpm2_devices DPRAM resource
From: Dan Malek @ 2005-06-16 19:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: Ppc Embedded
In-Reply-To: <1278c2c53202b80080519cca60bb438f@freescale.com>
On Jun 16, 2005, at 1:58 PM, Kumar Gala wrote:
> Well, we already have an allocator for general dpram memory. I'm not
> really sure how this would help beyond reducing the fact that we may
> ioremap() regions more than once. I think the better solution there
> is to look at the patches that have been made to ioremap() to return
> the same virtual addresses if you are remapping a region of physical
> memory that already has a mapping.
I agree. Specifically for 85xx, we have to make sure we have CAMs
mapping
these spaces and ioremap() will reuse them.
-- Dan
^ permalink raw reply
* Re: RFC cpm2_devices DPRAM resource
From: Dan Malek @ 2005-06-16 19:41 UTC (permalink / raw)
To: Allen Curtis; +Cc: Ppc Embedded
In-Reply-To: <ecc06b51023e6ebd23d075aa3948749e@onz.com>
On Jun 16, 2005, at 1:45 PM, Allen Curtis wrote:
> Should the DPRAM appear as it's own platform_device?
No.
> Option 1) Specify the portion of the DPRAM used by each device with
> that platform_device definition. (current)
You mean the parameter space? That's different from DPRAM.
> Option 2) Define the whole DPRAM region as its own platform_device
> entry. Move the device DPRAM information to the device specific
> platform structure.
How is this any different from using the dpalloc() as it is today?
The problem is that for the few standard devices we publicly support in
Linux it is easy to think of DPRAM as a "general" resource. However,
for
more challenging devices and implementation, there are sometimes
specific
regions of DPRAM that must be used with various additional restrictions.
For many of the "real world" devices I have done, drivers would manage
their own, well known, DPRAM areas. It isn't something that is easy
to generalize or configure in advance.
Thanks.
-- Dan
^ permalink raw reply
* map_page() and pinned TLB entries
From: Marcelo Tosatti @ 2005-06-16 14:47 UTC (permalink / raw)
To: Dan Malek, linux-ppc-embedded
Hi Dan,
So we've got rid of direct pte manipulators similar to what was done in v2.4.
Such patch for v2.6 is in the 8xx tree I posted previously, you've also seen
it here in the list.
Remaining problem is that map_page() is going to flush the TLB for the
addresses being created. Obviously there is a collision with the 4kb
PTE's, which thrases the 8Mbyte entry.
So what I have done internally is to simply comment out the
flush_HPTE() call in map_page(), which does the trick.
What would be an elegant way of dealing with this? We can insert
a conditional there such that only addresses not covered
by other mappings (in this case the 8Mbyte entry) get flushed.
Any better ideas?
diff -Nur --exclude-from=/home/marcelo/excl /mnt/test2/tslinux_mv21/linux-2.6/arch/ppc/mm/pgtable.c linux-2.6/arch/ppc/mm/pgtable.c
--- /mnt/test2/tslinux_mv21/linux-2.6/arch/ppc/mm/pgtable.c 2005-05-16 13:19:47.000000000 -0300
+++ linux-2.6/arch/ppc/mm/pgtable.c 2005-06-16 15:52:32.000000000 -0300
@@ -299,8 +299,8 @@
if (pg != 0) {
err = 0;
set_pte(pg, pfn_pte(pa >> PAGE_SHIFT, __pgprot(flags)));
- if (mem_init_done)
- flush_HPTE(0, va, pmd_val(*pd));
+ // if (mem_init_done)
+// flush_HPTE(0, va, pmd_val(*pd));
}
spin_unlock(&init_mm.page_table_lock);
return err;
^ permalink raw reply
* Re: RFC cpm2_devices DPRAM resource
From: Allen Curtis @ 2005-06-16 20:07 UTC (permalink / raw)
To: Dan Malek; +Cc: Ppc Embedded
In-Reply-To: <33f285d9677314c043e77908198a3e0e@embeddededge.com>
>> Should the DPRAM appear as it's own platform_device?
>
> No.
>
>> Option 1) Specify the portion of the DPRAM used by each device with
>> that platform_device definition. (current)
>
> You mean the parameter space? That's different from DPRAM.
>
>> Option 2) Define the whole DPRAM region as its own platform_device
>> entry. Move the device DPRAM information to the device specific
>> platform structure.
>
> How is this any different from using the dpalloc() as it is today?
>
> The problem is that for the few standard devices we publicly support in
> Linux it is easy to think of DPRAM as a "general" resource. However,
> for
> more challenging devices and implementation, there are sometimes
> specific
> regions of DPRAM that must be used with various additional
> restrictions.
> For many of the "real world" devices I have done, drivers would manage
> their own, well known, DPRAM areas. It isn't something that is easy
> to generalize or configure in advance.
>
Time for code.
- Allen
^ permalink raw reply
* Re: More dtc changes
From: Jon Loeliger @ 2005-06-16 20:49 UTC (permalink / raw)
To: David Gibson
Cc: linuxppc-dev list, u-boot-users, linuxppc64-dev,
linuxppc-embedded@ozlabs.org
In-Reply-To: <20050616070816.GE31347@localhost.localdomain>
On Thu, 2005-06-16 at 02:08, David Gibson wrote:
> I now have a git tree for the device tree compiler up at
> http://www.ozlabs.org/~dgibson/dtc/dtc.git
Very Cool!
And, um, rats. So, I'm the victim of an aggressive
and anti-social IT Firewall poo-poolicy.... Or maybe I
am just being dumb and haven't Googled up the Right Magic.
Is there a way to set an HTTP Proxy definition, flag,
parameter, environment variable, or other doo-dad that
will help me cg-pull/git-http-pull through my firewall?
Alternatively, any chance we can convert it to, or add,
an rsync tree?
> There's a tarball release as well
> http://www.ozlabs.org/~dgibson/dtc/dtc.tar.gz
If not, I'll have to be doing the tarball thing...
Thanks,
jdl
^ permalink raw reply
* Re: map_page() and pinned TLB entries
From: Dan Malek @ 2005-06-16 21:13 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050616144739.GA1559@logos.cnet>
On Jun 16, 2005, at 10:47 AM, Marcelo Tosatti wrote:
> What would be an elegant way of dealing with this? We can insert
> a conditional there such that only addresses not covered
> by other mappings (in this case the 8Mbyte entry) get flushed.
I'd like to make _tlbie() a macro on 8xx that simply tests the VA
and doesn't invalidate anything in the pinned space. Of course,
the code shouldn't be doing this anyway, and I think this
should be treated as a bug if it happens. If the Linux VM
thinks it needs to be doing this, pinned space isn't going to work.
The _tlbie() is an exported symbol, I suspect for MOL, so
we have to accommodate that.
Thanks.
-- Dan
^ permalink raw reply
* Re: More dtc changes
From: Jerry Van Baren @ 2005-06-16 21:15 UTC (permalink / raw)
To: Jon Loeliger
Cc: linuxppc64-dev, linuxppc-dev list, linuxppc-embedded@ozlabs.org,
u-boot-users, David Gibson
In-Reply-To: <1118954956.25372.71.camel@cashmere.sps.mot.com>
Jon Loeliger wrote:
> On Thu, 2005-06-16 at 02:08, David Gibson wrote:
>
>>I now have a git tree for the device tree compiler up at
>>http://www.ozlabs.org/~dgibson/dtc/dtc.git
>
>
> Very Cool!
>
> And, um, rats. So, I'm the victim of an aggressive
> and anti-social IT Firewall poo-poolicy.... Or maybe I
> am just being dumb and haven't Googled up the Right Magic.
>
> Is there a way to set an HTTP Proxy definition, flag,
> parameter, environment variable, or other doo-dad that
> will help me cg-pull/git-http-pull through my firewall?
>
> Alternatively, any chance we can convert it to, or add,
> an rsync tree?
>
>
>>There's a tarball release as well
>>http://www.ozlabs.org/~dgibson/dtc/dtc.tar.gz
>
>
> If not, I'll have to be doing the tarball thing...
>
> Thanks,
> jdl
It ain't efficient and it is pull-only, but it works:
$ mkdir test
$ cd test
test$ ll
total 0
$ cg-clone http://www.ozlabs.org/~dgibson/dtc/dtc.git
defaulting to local storage area
17:13:12
URL:http://www.ozlabs.org/%7Edgibson/dtc/dtc.git/refs/heads/master
[41/41] -> "refs/heads/origin" [1]
progress: 40 objects, 59841 bytes
FINISHED --17:13:25--
Downloaded: 951 bytes in 1 files
New branch: 81f2e89c7551ef44a6203ab1cbb8228d09202572
Cloned (origin http://www.ozlabs.org/~dgibson/dtc/dtc.git available as
branch "origin")
Cloned to dtc/ (origin http://www.ozlabs.org/~dgibson/dtc/dtc.git
available as branch "origin")
$ ll dtc/
total 116
-rw-r--r-- 1 vanbaren cideas 446 2005-06-16 17:13 comment-test.dts
-rw-r--r-- 1 vanbaren cideas 17992 2005-06-16 17:13 COPYING
-rw-r--r-- 1 vanbaren cideas 4776 2005-06-16 17:13 data.c
-rw-r--r-- 1 vanbaren cideas 4896 2005-06-16 17:13 dtc.c
-rw-r--r-- 1 vanbaren cideas 4704 2005-06-16 17:13 dtc.h
-rw-r--r-- 1 vanbaren cideas 2989 2005-06-16 17:13 dtc-lexer.l
-rw-r--r-- 1 vanbaren cideas 2890 2005-06-16 17:13 dtc-parser.y
-rw-r--r-- 1 vanbaren cideas 19400 2005-06-16 17:13 flattree.c
-rw-r--r-- 1 vanbaren cideas 2324 2005-06-16 17:13 fstree.c
-rw-r--r-- 1 vanbaren cideas 15506 2005-06-16 17:13 livetree.c
-rw-r--r-- 1 vanbaren cideas 559 2005-06-16 17:13 Makefile
-rw-r--r-- 1 vanbaren cideas 707 2005-06-16 17:13 test.dts
drwxr-xr-x 2 vanbaren cideas 4096 2005-06-16 17:13 tests
-rw-r--r-- 1 vanbaren cideas 566 2005-06-16 17:13 TODO
-rw-r--r-- 1 vanbaren cideas 3000 2005-06-16 17:13 treesource.c
$ du -s *
1368 dtc
gvb
^ permalink raw reply
* Re: More dtc changes
From: Jon Loeliger @ 2005-06-16 21:36 UTC (permalink / raw)
To: Jerry Van Baren
Cc: linuxppc64-dev, linuxppc-dev list, linuxppc-embedded@ozlabs.org,
u-boot-users, David Gibson
In-Reply-To: <42B1EBFC.4020105@smiths-aerospace.com>
On Thu, 2005-06-16 at 16:15, Jerry Van Baren wrote:
> > And, um, rats. So, I'm the victim of an aggressive
> > and anti-social IT Firewall poo-poolicy.... Or maybe I
> > am just being dumb and haven't Googled up the Right Magic.
Door number 3, I am dumb.
> > Is there a way to set an HTTP Proxy definition, flag,
> > parameter, environment variable, or other doo-dad that
> > will help me cg-pull/git-http-pull through my firewall?
> It ain't efficient and it is pull-only, but it works:
Good enough....
> $ cg-clone http://www.ozlabs.org/~dgibson/dtc/dtc.git
> defaulting to local storage area
> 17:13:12
> URL:http://www.ozlabs.org/%7Edgibson/dtc/dtc.git/refs/heads/master
> [41/41] -> "refs/heads/origin" [1]
> progress: 40 objects, 59841 bytes
Hmmm... So, I tested this mess again. This time, I did
NOT use our stupid SOCKS proxy, but rather the built-in
HTTP proxy foo sort of like this in an environment variable
sort of like this:
setenv http_proxy http://$user:$password@$proxy_machine:$proxy_port
cashmere.sps.mot.com 894 % socksify cg-pull origin
loeliger@192.88.158.50.1090 sockspassword:
cg-pull: objects pull failed
cashmere.sps.mot.com 895 % cg-pull origin
16:24:36 URL:http://www.ozlabs.org/%7Edgibson/dtc/dtc.git/refs/heads/master [41/41] -> "refs/heads/origin" [1]
FINISHED --16:24:48--
And then it just stupidly worked.
Pay no attention to my questions,
jdl
^ permalink raw reply
* mmap on 440gx
From: Ed Goforth @ 2005-06-16 21:33 UTC (permalink / raw)
To: linuxppc-embedded
I've been struggling with implementing mmap on a 440gx-based custom
board. I have been able to use ioremap(), but we really need a mmap()
for our software. The kernel is 2.4.18 (TimeSys 4.0).
I'm trying to access one of our FPGA's located at 0x50000000. Offsets
0x00000000 thru
0x000FFFFF are control and status registers. Offsets 0x01000000 thru
0x017FFFFF are the QDR SRAM on the FPGA.
Using ioremap_nocache(0x50000000, bytes_to_map) works (so long as
bytes_to_map isn't too large). I can then use in_be32() and
out_be32() to read/write the registers and the SRAM. However, trying
to implement mmap() causes the board to lock up hard. I have tried
iterations both where the driver first does an ioremap(), and where it
doesn't do the ioremap(). Some bits:
In driver module:
static struct file_operations test_mmap_fops =3D {
read : test_mmap_read,
mmap : test_mmap_mmap,
open : test_mmap_open,
release : test_mmap_release,
};
static int test_mmap_mmap (struct file *filp, struct vm_area_struct *vma) {
vma->vm_flags |=3D (VM_SHM | VM_LOCKED | VM_IO | VM_RESERVED);
if (remap_page_range(vma->vm_start, 0x50000000, 4096, vma->vm_page_prot))
return(-EAGAIN);
return(0);
} /* test_mmap_mmap() */
When the test code calls mmap():
unsigned long *mmap_region;
unsigned long data;
mmap_region =3D mmap(0, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
it seems to work. However, dereferencing mmap_region, either thru
data =3D *mmap_region;
or
data =3D mmap_region[0];
causes the board to lock hard.
I would appreciate any suggestions or hints.
Thanks,
Ed
^ permalink raw reply
* Re: map_page() and pinned TLB entries
From: Marcelo Tosatti @ 2005-06-16 16:47 UTC (permalink / raw)
To: Dan Malek; +Cc: linux-ppc-embedded
In-Reply-To: <8efaee2824f500e906c2c05526ea3214@embeddededge.com>
On Thu, Jun 16, 2005 at 05:13:19PM -0400, Dan Malek wrote:
>
> On Jun 16, 2005, at 10:47 AM, Marcelo Tosatti wrote:
>
> >What would be an elegant way of dealing with this? We can insert
> >a conditional there such that only addresses not covered
> >by other mappings (in this case the 8Mbyte entry) get flushed.
>
> I'd like to make _tlbie() a macro on 8xx that simply tests the VA
> and doesn't invalidate anything in the pinned space. Of course,
> the code shouldn't be doing this anyway, and I think this
> should be treated as a bug if it happens.
Well it is expected that mapin_ram() flushes the va for the
PTE's being created.
That is the only well known occurence of _tlbie() on
a possibly pinned region.
I agree that adding a debugging check on _tlbie() to
catch invalidations in pinned space is a good thing.
> If the Linux VM thinks it needs to be doing this, pinned space
> isn't going to work.
Well the VM does that now, but it can be changed to skip the
pinned region.
>The _tlbie() is an exported symbol, I suspect for MOL, so
> we have to accommodate that.
What does MOL stand for?
> Thanks.
There are two separate approaches:
a) Fix mapin_ram() to skip pinned regions
b) Fix _tlbie() to skip pinned regions and warn about such
misusage.
If b) is chosen alone, which is what you seem to suggest, we
will get tons of warnings (or traps) anyway from mapin_ram().
So having that said, isnt the correct way out of this to change
both a) and b)?
^ permalink raw reply
* Re: [newbie]: mpc8260 kernel opps sig 7 and 11 please help!
From: Ricardo Scop @ 2005-06-16 21:59 UTC (permalink / raw)
To: eagle keeper, linuxppc-embedded
In-Reply-To: <74499824050616065835741324@mail.gmail.com>
Hi eagle ;)
On Thursday 16 June 2005 10:58, eagle keeper wrote:
> 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.
Are you sure your board is a 100% hw compatible with ADS8260? Particularl=
y in=20
the CPM and peripherals configuration session in the kernel compilation=20
parameters?
You should check this and make the proper modifications in .config.
HTH,
Ricardo Scop.
\|/
___ -*-
(@ @)/|\
/ V \| R SCOP Consult.
/( )\ Linux-based communications
--^^---^^+------------------------------
rscop@matrix.com.br
+55 51 999-36-777
Porto Alegre, RS - BRazil
--
P. S.: "If you don't have time to do it right, when will you have time
to do it over?" -- Penny Hines =20
^ permalink raw reply
* Re: map_page() and pinned TLB entries
From: Dan Malek @ 2005-06-16 22:17 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20050616164717.GA1915@logos.cnet>
On Jun 16, 2005, at 12:47 PM, Marcelo Tosatti wrote:
> Well it is expected that mapin_ram() flushes the va for the
> PTE's being created.
>
> That is the only well known occurence of _tlbie() on
> a possibly pinned region.
Crap ... no, it's not. It's map_page() that does the flush,
which happens on ioremap() as well. When we pin
entries, we also pin some IO space as well. We need
to update ioremap() to be smart about pinned entries
like it does BATs and CAMs. I wonder if we can just
make this a generic test in ioremap(). It doesn't have
to know how the spaces are "pinned", just that they are
and how they are mapped.
> What does MOL stand for?
MacOS on Linux. I don't think 8xx will run this any
time soon :-)
> If b) is chosen alone, which is what you seem to suggest, we
> will get tons of warnings (or traps) anyway from mapin_ram().
It's from more than just mapin_ram(). As I said, we also
use some of the entries to pin IO space. We used to pin only
8M of instructions, which is more than sufficient, then various
8M windows of data space. I think we used to pin 24M of
data and 8M of IMMR (plus anything above that, which could
be flash or other IO).
> So having that said, isnt the correct way out of this to change
> both a) and b)?
We certainly have to implement b) to catch all pinned spaces,
then update accordingly to ensure none of the wired entries
get evicted.
Thanks.
-- Dan
^ permalink raw reply
* Re: mmap on 440gx
From: Matt Porter @ 2005-06-16 22:55 UTC (permalink / raw)
To: Ed Goforth; +Cc: linuxppc-embedded
In-Reply-To: <75b39f0105061614333199ec37@mail.gmail.com>
On Thu, Jun 16, 2005 at 05:33:44PM -0400, Ed Goforth wrote:
> I've been struggling with implementing mmap on a 440gx-based custom
> board. I have been able to use ioremap(), but we really need a mmap()
> for our software. The kernel is 2.4.18 (TimeSys 4.0).
There are some special things done for handling [io]_remap_page/pfn_range
on other vendor kernels and the current mainline kernel. I'm not sure
if your vendor kernel addressed them since it would be a vendor-specific
patch in that timeframe. The special things are due to 36-bit
addressing.
> I'm trying to access one of our FPGA's located at 0x50000000. Offsets
Let's start at the beginning. How do you have FPGA's at 0x50000000?
that address falls with the fix DDR SDRAM area on the 440GX memory
map. All peripheral and EBC space is mapped by 4GB. You lost me
right here. Oh wait, are you referring to the least significant 32-bits
of the physical mapping. It's not really at 0x50000000.
You need something like the bigphys_remap patch for 2.4 that can be
found at ftp://source.mvista.com/pub/linuxppc/
It does the same fixup for remap_page_range() that happens for
ioremap(). In 2.6 this stuff is all in the mainline kernel but
you use io_rename_[page|pfn]_range() there.
-Matt
^ permalink raw reply
* Re: Adding RapidIO to Linux
From: Matt Porter @ 2005-06-17 0:20 UTC (permalink / raw)
To: Avni Hillel-R58467
Cc: Kardonik Michael-R58108, 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <D39C8B3D64A0D511A61E00D0B7828EEA0C076452@zil05exm01.ea.freescale.net>
On Thu, Jun 16, 2005 at 01:44:48PM +0300, Avni Hillel-R58467 wrote:
> 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.6.12-rc6 is the latest release that you can apply these against.
Or they can go against the linux-2.6 git tree.
> 2. Are there any more patches that are relevant to RIO?
Several sets of patches were posted after this set, and then
there were several additions posted against the -mm tree.
Check the list archives, I cced this list on everything.
You could get the 2.6.12-rc6-mm1 patch which has a later version
of these patches. There are additional changes in the -mm tree
but there isn't a unified patch of them until another -mm patch
is released.
-Matt
^ permalink raw reply
* Re: More dtc changes
From: David Gibson @ 2005-06-17 0:45 UTC (permalink / raw)
To: Jon Loeliger
Cc: linuxppc-dev list, u-boot-users, linuxppc64-dev,
linuxppc-embedded@ozlabs.org
In-Reply-To: <1118954956.25372.71.camel@cashmere.sps.mot.com>
On Thu, Jun 16, 2005 at 03:49:16PM -0500, Jon Loeliger wrote:
> On Thu, 2005-06-16 at 02:08, David Gibson wrote:
> > I now have a git tree for the device tree compiler up at
> > http://www.ozlabs.org/~dgibson/dtc/dtc.git
>
> Very Cool!
>
> And, um, rats. So, I'm the victim of an aggressive
> and anti-social IT Firewall poo-poolicy.... Or maybe I
> am just being dumb and haven't Googled up the Right Magic.
>
> Is there a way to set an HTTP Proxy definition, flag,
> parameter, environment variable, or other doo-dad that
> will help me cg-pull/git-http-pull through my firewall?
>
> Alternatively, any chance we can convert it to, or add,
> an rsync tree?
Oh, oops, I meant to set up an rsync tree, but forgot. It's now done,
and you can also pull it from:
ozlabs.org::dtc/dtc.git
--
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: MPC5200/Lite5200 and ethernet
From: Dale Farnsworth @ 2005-06-17 3:37 UTC (permalink / raw)
To: Andrey Volkov; +Cc: linuxppc-embedded
In-Reply-To: <42B1CB13.3060107@varma-el.com>
On Thu, Jun 16, 2005 at 10:55:15PM +0400, Andrey Volkov wrote:
> Grant Likely wrote:
> > On 6/16/05, Andrey Volkov <avolkov@varma-el.com> wrote:
> >
> >>AFAIK almost all patches from http://www.246tnt.com/mpc52xx/ now in
> >>vanilla kernel. Except, bestcomm, certainly :(.
> >
> > FEC is missing too.
> >
> > Is anybody even working on bestcomm at the moment?
> It may be Dale Farnsworth or smb. quietly in Freescale.
I sent patches to Sylvain in August 2004 with 5200 FEC support,
including my rewrite of the bestcomm FEC code. I've bugged him
about it a few times, and I don't know why he hasn't made it available.
I haven't done much with the 5200 since then. I'm traveling now and
have some other pressing issues, but I'll try to post what
I have in the next couple of weeks.
-Dale
^ 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