Hello Cristophe.
> On Sep 10, 2018, at 7:34 AM, Christophe Leroy wrote:
>
> On the powerpc8xx, handling 16k size pages requires to have page tables with
> 4 identical entries.
Do you think a 16k page is useful? Back in the day, the goal was to keep the
fault handling and management overhea
Hello Christophe.
I’m surprised there is still any interest in this processor family :)
On Jun 8, 2016, at 12:03 AM, Christophe Leroy wrote:
> MPC 8xx has several page sizes: 4k, 16k, 512k and 8M.
> Today, 4k and 16k sizes are implemented as normal page sizes and 8M is used
> for mapping line
Hi Ben.
On Jun 7, 2013, at 5:34 PM, Benjamin Herrenschmidt
wrote:
> The question is whether this is still relevant ?
The only answer I could provide is that it's dependent upon the libraries and
how the distributions are built. It's also dependent upon processors with
hardware FP that don'
On Jun 7, 2013, at 4:30 PM, Benjamin Herrenschmidt
wrote:
> Right, looking more, the code really sucks.
Hey! :)
> …. Either you use the existing
> apparent ability for MATH_EMU to operate in minimal mode, ie,
> load/store/fmr only (which seems to do exactly the same thing as the
> code in s
Hi Joakim.
On May 30, 2012, at 12:43 AM, Joakim Tjernlund wrote:
I have tested this briefly with BDI2000 on P2010(e500) and
it works for me. I don't know if there are any bad side effects,
therfore
this RFC.
We used to have MSR_DE surrounded by CONFIG_something
to ensure it wasn't set und
On Oct 13, 2011, at 7:00 AM, Joakim Tjernlund wrote:
ehhm, do the fun stuff first? :)
Need to pay the bills, first :-)
Thanks for the other information.
-- Dan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlab
Hi Joakim.
On Oct 12, 2011, at 2:36 PM, Joakim Tjernlund wrote:
Dan, where did you go? I figured you would throw yourself at this as
this is
something you been meaning to do yourself for years :)
Too many things to do :-) I did have the wired page version that I've
been using now and then
On Oct 10, 2011, at 9:45 AM, Joakim Tjernlund wrote:
That is an easy port but I will have to do that blind. Would you
mind take this for a spin on 2.4 first?
My current system is running 2.6, so I don't have much
interested in testing 2.4
The more interesting part is if one should use other
Hi Joakim.
On Oct 10, 2011, at 4:38 AM, Joakim Tjernlund wrote:
This adds Large page support for 8xx and uses it
for all kernel RAM
- Dan, what do you think :)
Since you asked, yes it looks great :-) Now, can we
get this into a more contemporary kernel? I'm
actually working on an 8x
Hi Joakim.
On Jun 14, 2011, at 11:00 AM, Joakim Tjernlund wrote:
I don't have a mpc850, do you?
I have to say I do :-)
Probably but that is another matter. You could continue with that
if you like but I am stopping here ATM.
Oh, come on... I've been thinking about this for years, wouldn
Hi Joakim.
On Jun 14, 2011, at 6:54 AM, Joakim Tjernlund wrote:
I know 2.4 is in strict maintenance mode and 8xx is obsolete
but as it is still in use I wanted 8xx to age with grace.
Thanks for your continued support. I have recently become
involved in some 8xx development again, and have n
Hi Joakim.
On Jun 14, 2011, at 6:54 AM, Joakim Tjernlund wrote:
Various kernel asm modifies SRR0/SRR1 just before executing
a rfi. .
I'm going to argue we can easily visually inspect for this
since the code is static with just a couple of RFIs in these
exception handlers.
Some 8xx proce
On Feb 24, 2011, at 6:43 AM, John Linn wrote:
It seems like this also depends on that fact that __GFP_COLD will
work,
otherwise some of the data could
already be in the cache such that you're not guaranteed to get
everything out of the cache.
I wouldn't count on GFP_COLD as a guarantee the
Hi John.
On Feb 23, 2011, at 5:04 PM, John Linn wrote:
Any thoughts?
I can come up with two methods, but before I describe them
ensure you consider the actual implementation of your 405 core.
My comments are based on the "standard" ppc405 processor,
but since you can configure the embedded c
On Feb 4, 2011, at 6:04 PM, Tabi Timur-B04825 wrote:
I guess I'm not clear. I was wondering why an API called
"dma_alloc_coherent" (that has the word "dma" in it) needs to be
told to allocate DMA-safe memory.
I understood your question, and I indicated this is used in a
platform specific
On Feb 4, 2011, at 4:14 PM, Timur Tabi wrote:
Is there any official statement on what the minimum alignment is for
memory returned by dma_alloc_coherent?
This is dependent upon the particular implementation.
There have been several over the history of this API,
and some would work out of a DM
On Sep 21, 2010, at 2:49 PM, Scott Wood wrote:
On Tue, 21 Sep 2010 16:43:12 -0500
Timur Tabi wrote:
Since we don't DMA the descriptors themselves, I just don't see how
this patch does anything.
Look in dmaengine.c, there are calls to dma_map_single() and
dma_map_page(), using what I assum
Hi Grant.
On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
I've been doing a bit of work on some introductory level documentation
of the flattened device tree.
Wow, I feel empowered to create device trees now :-)
Seriously, I never understood this well and this is a
great document.
I have o
On Nov 14, 2009, at 2:42 AM, Joakim Tjernlund wrote:
. Avoid this by always pinning
kernel instruction TLB space.
You may as well map the data space, too, since you have
reserved the entries. Take advantage of that performance.
Also, some processor variants have very few TLB entries,
and
On Oct 26, 2009, at 3:47 PM, Benjamin Herrenschmidt wrote:
This whole thing would be a -lot- easier to do from C code. Why ?
Simply
because you could just use get_user() to load the instruction rather
than doing this page table walking in asm,
Just be careful the get_user() doesn't regenera
On Oct 8, 2009, at 3:23 PM, Benjamin Herrenschmidt wrote:
<<
• Reference and change bit updates—The MPC850 does not generate an
exception for
an R (reference) bit update. In fact, there is no entry for an R
bit in the TLB.
The change bit (C) is bit 23 in the level-two descriptor,
desc
On Oct 8, 2009, at 1:37 PM, Joakim Tjernlund wrote:
Hi, been a long time since I heard from you :)
Yeah, hiding among other projects :-)
Anyhow, you are welcome to have a look at the patches I have been
tossing out.
I've been looking, but since I'm not familiar with the current
VM implem
Hi Ben.
On Oct 8, 2009, at 1:28 PM, Benjamin Herrenschmidt wrote:
While you are around ... I have a question :-)
I'll try. Many brain cells have been replaced or lost
over the years :-)
Do you happen to remember what the story is with the invalidation of
"unpopulated" (aka invalid) entrie
On Oct 8, 2009, at 12:22 PM, Joakim Tjernlund wrote:
hare are comments in the kernel that dcbst wrongly
generates TLB Errors with store set on 8xx. Is this really so?
Should dcbst always trap as a load?
There are many comments written about 8xx as various
behavior was discovered. Worse, some
On Jan 6, 2008, at 12:07 PM, Benjamin Herrenschmidt wrote:
> It's nice to see somebody digging in that scary math emu stuff. If you
> could also get rid of the warnings, it would be perfect :-)
Yes, it is :-) I didn't think it would have a life beyond MPC8xx.
> that this code was lifted f
On Nov 25, 2007, at 8:18 AM, Vitaly Bordug wrote:
> To prevent using those pointers from within non-GPL modules. kind
> of policy now...
As the original copyright holder of nearly all of this of
this code, I do not wish this be done.
Thanks.
-- Dan
__
On Nov 13, 2007, at 1:59 PM, Grant Likely wrote:
>> Abatron BDI-2000.
>
> Oops, but that's not all that cheap. ($2750USD).
If you place any value on your time or development
schedule, it's a bargain. Just plug it in, and it works.
Choose any of your favorite debugger front ends,
from none with
On Oct 15, 2007, at 7:07 PM, Kumar Gala wrote:
> I was wondering if you cared about the following boards existing in
> arch/powerpc:
>
> * STX GP3
I have GP3 and GP3-SSA for testing.
If you can make a first pass at the changes
I'll debug and finish.
Thanks.
-- Dan
On Oct 7, 2007, at 8:02 AM, Kumar Gala wrote:
> It would seem like we should set the default on 8xx & PReP to
> 0x8000 and not allow it to be modified
For as much as this has been discussed in the past,
I don't know why the 8xx doesn't check KERNEL_BASE
and work properly with the options. T
On Oct 6, 2007, at 6:36 AM, Kumar Gala wrote:
> In a discussion with Hollis over beer he raised the question why
> TASK_SIZE is 0x8000 on ppc32.
Left over from the old days (2.1) of the PReP port when
things were hard coded. We used some of the space
between 0x8000 and 0xc000 for ma
On Sep 5, 2007, at 3:23 PM, Scott Wood wrote:
> The IMMRs I've seen from the bootloader are ff00 (Freescale
> boards)
> and fa20 (Embedded Planet). AFAICT, the number of fixed TLB
> entries
> is fixed at 4 on these chips, so using the fourth for flash
> wouldn't take
> away any gen
On Sep 5, 2007, at 1:59 PM, Scott Wood wrote:
> BTW, it seems I misremembered what the conflict was -- it's not with
> ioremap space, but with the default location of the consistent memory
> pool (at 0xff10).
Change the configuration option to move this somewhere
else, outside of the wired m
On Sep 5, 2007, at 1:53 PM, Scott Wood wrote:
> Where is the code that checks for pinned TLB entries on 8xx when doing
> ioremap?
I don't know. I haven't been the maintainer for the 2.6
changes.
> Why could this not be done with a 512K mapping? How was this
> even tested, given the obvious
On Sep 5, 2007, at 12:27 PM, Scott Wood wrote:
> 1. Only map 512K of the IMMR, rather than 8M, to avoid conflicting
> with
> the default ioremap region.
The original reason to map 8M was so ioremap()
could use the same wired TLB rather than allocate
page table entries. It should also cover al
34 matches
Mail list logo
