* Re: Memory mapping the PHY on CR826
From: Clemens Koller @ 2005-05-24 9:00 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linux-atm-general@lists.sourceforge.net, linuxppc-embedded
In-Reply-To: <20050523145953.3a2044ef.ajz@cambridgebroadband.com>
Hello,
FYI: This is a board based on the Freescale MPC8260 processor.
Greets,
Clemens
Alex Zeffertt wrote:
> Hi all,
>
> Does anyone here have *any* code for memory mapping the PM5350 ATM phy
> on the Microsys CR826 board?
>
> I've just purchased this board from Microsys and I'm trying to get the
> atm8260 ATM device driver to work on it - unfortunately I cannot seem to
> memory map the phy. My current settings are:
>
>
> memctl->memc_or8 = 0xe0400ef4; // base 0xe0400000; default timings
> memctl->memc_br8 = 0xffff8821; // min banksize; 8bit port; GPCM local;
> // bank valid
>
> Has anybody done this already?
>
> TIA,
>
> Alex
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Memory mapping the PHY on CR826
From: Wolfgang Denk @ 2005-05-24 9:09 UTC (permalink / raw)
To: Clemens Koller; +Cc: linux-atm-general@lists.sourceforge.net, linuxppc-embedded
In-Reply-To: <4292ED43.8060607@anagramm.de>
In message <4292ED43.8060607@anagramm.de> you wrote:
>
> FYI: This is a board based on the Freescale MPC8260 processor.
Actually it's a 8270 in Alex' case.
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
Of course there's no reason for it, it's just our policy.
^ permalink raw reply
* Re: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (v3)
From: Jon Loeliger @ 2005-05-24 15:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc64-dev, Tzachi Perelstein, u-boot-users,
linuxppc-dev list
In-Reply-To: <1116909286.4992.17.camel@gaston>
On Mon, 2005-05-23 at 23:34, Benjamin Herrenschmidt wrote:
> Hi !
> David and I are still working on sample code & tools. We have a
> prototype of a device-tree "compiler" that can build the flattened blob
> from a textual representation. We'll release that soon, hopefully this
> week.
Hi Ben,
This is most excellent. In particular, I won't start to
do just that step too... :-) So, can you put me on the
beta tester list for those tools? Or are you just going
to post it all here?
Thanks,
jdl
^ permalink raw reply
* [PATCH] add machine state register support
From: Geoff Levand @ 2005-05-23 23:40 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
This patch adds routines to get and set the machine state register. These
are needed by power management code on some platforms.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF
--
Index:linux-2.6.11/arch/ppc/kernel/misc.S
===================================================================
--- linux-2.6.11.orig/arch/ppc/kernel/misc.S 2005-04-15 14:59:12.408518820 -0700
+++ linux-2.6.11/arch/ppc/kernel/misc.S 2005-04-15 14:59:34.005586781 -0700
@@ -1160,6 +1159,14 @@
addi r1,r1,16
blr
+_GLOBAL(_get_msr)
+ mfmsr r3
+ blr
+
+_GLOBAL(_set_msr)
+ mtmsr r3
+ blr
+
/*
* This routine is just here to keep GCC happy - sigh...
*/
^ permalink raw reply
* Re: [PATCH] add machine state register support
From: Geoff Levand @ 2005-05-24 17:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1116892416.30513.10.camel@gaston>
Benjamin Herrenschmidt wrote:
> On Mon, 2005-05-23 at 16:40 -0700, Geoff Levand wrote:
>
>>This patch adds routines to get and set the machine state register. These
>>are needed by power management code on some platforms.
>>
>>Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF
>
>
> Hi Geoff !
>
> Can you tell me more about this power management code ? I tend to think
> that code that wants to do more than just using the existing accessors
> should be written in assembly...
>
> Also, there is already
>
> void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val);
>
> That you can use for manipulating MSR bits.
>
> Finally, I tend to prefer such small register accessors to be written as
> inline assembly in some headers. But then, I don't think you actually
> need to add anything here.
>
Sorry for the trouble, Geert is right, there are already mfmsr() and
mtmsr() in <ppc-asm/reg.h>. I found get_msr in ppc64 and assumed they
were missing for ppc. I should have looked more carefully.
-Geoff
^ permalink raw reply
* Re: MMUCR on ppc440 GP/GX
From: ming lei @ 2005-05-24 18:36 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
what's the latest ppc440 linux code that I can take
look at?
BTW, what's the problem three years ago prompted to
change the code regarding mmucr handling?
Thanks,
Ming
--- Matt Porter <mporter@kernel.crashing.org> wrote:
> On Mon, May 23, 2005 at 01:55:58PM -0700, ming lei
> wrote:
> > Hi,
> >
> > I have problem on running system with linuxppc
> > 2.4.19(ppc440GP/GX) regarding MMU Control
> > Register(MMUCR).
> >
> > I checked the code in arch/ppc/ there is no code
> > setting or unsetting bit 12(DULXE) or bit
> 13(IULXE),
> > but somehow these two bits got changed during boot
> > process.
> >
> > Question 1:
> > Does CPU or other hardware change these two bits?
> If
> > linux code doesnt set these two bits initiallt,
> what's
> > the default value? Or I miss something in the
> code
> > that may change these two bits?
> >
> > Question 2:
> > For current 2.4.19 PPC440 implementation, there is
> no
> > special handling for this kind of DataStorage
> > exception, is it possible for the user code to
> stuck
> > in this exception forever if these two bits got
> set in
> > MMUCR and the user code calls icbi instruction?
> >
> > I did a simple test on head_440.S so whenever the
> > DataStorage exception happens, in DataStorage
> assmbly
> > code, I clear these two bits in MMUCR, but somehow
> > these two bits got set mysteriourly in next
> exception
> > with error_code 0x200000(got from ESR DLK bits).
> > What's happening here?
>
> Your kernel revision is very ancient. The problem
> here is that
> you are trying to use _very_ early PPC440 core code
> I released.
> It's filled with critical bugs that were fixed over
> time. The MMUCR
> issue was fixed almost 3 years ago, in fact.
>
> Your best solution is to run a more recent kernel.
> If that's
> not possible, then I suggest you backport all the
> PPC440
> related code from a more recent kernel into your old
> kernel
> base.
>
> -Matt
>
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
^ permalink raw reply
* Re: [PATCH] add machine state register support
From: Geert Uytterhoeven @ 2005-05-24 17:05 UTC (permalink / raw)
To: Geoff Levand; +Cc: Linux/PPC Development
In-Reply-To: <42926A07.20706@am.sony.com>
On Mon, 23 May 2005, Geoff Levand wrote:
> This patch adds routines to get and set the machine state register. These
> are needed by power management code on some platforms.
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF
>
> --
>
> Index:linux-2.6.11/arch/ppc/kernel/misc.S
> ===================================================================
> --- linux-2.6.11.orig/arch/ppc/kernel/misc.S 2005-04-15 14:59:12.408518820 -0700
> +++ linux-2.6.11/arch/ppc/kernel/misc.S 2005-04-15 14:59:34.005586781 -0700
>
> @@ -1160,6 +1159,14 @@
> addi r1,r1,16
> blr
>
> +_GLOBAL(_get_msr)
> + mfmsr r3
> + blr
> +
> +_GLOBAL(_set_msr)
> + mtmsr r3
> + blr
> +
Please check m[ft]msr() in <asm/reg.h>.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Newbie question about accessing memory in kernel space
From: Niklaus Giger @ 2005-05-24 19:19 UTC (permalink / raw)
To: linuxppc-embedded, rtai
Hi
I am working on a custom PPC405 board where I have a 2.6.10 kernel with RTAI
patches (fusion) running.
I am trying to access some custom CPLD chip hanging at 0x7D000000. In my
intial board (hcu3_map_io) I added a corresponding io_block_mapping.
I can see the CPLD when I access the address via my Abatron BDI debugger.
In a user space test program I did a
map_base = mmap((void *)target, nSize, PROT_READ | PROT_WRITE, MAP_SHARED,
fd, target);
and was able to access the CPLD, too.
In user and kernel space the procedure looks like this:
void sys_set_tick_control_register_value(uint16 value)
{
static uint16 *tickControlRegister = (uint16*)
HCU_TICK_CONTROL_REGISTER_ADDRESS;
*tickControlRegister = value;
}
Now I compiled a module which tries to access the CPLD during the insmod phase
and I get the following output.
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C302B0C4 LR: C302B350 SP: C1DABED0 REGS: c1dabe20 TRAP: 0300 Not
tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 7D000000, DSISR: 00800000
TASK = c1d827b0[27] 'insmod' THREAD: c1daa000
Last syscall: 128
PLB0: bear= 0x04000004 acr= 0x00000000 besr= 0x00000000
PLB0 to OPB: bear= 0xef6007ff besr0= 0x00000000 besr1= 0x00000000
GPR00: C302B348 C1DABED0 C1D827B0 0000002B 00000CAC FFFFFFFF C01C0000 00029030
GPR08: C01CBB30 C3030000 00000000 7D000000 00000000 10075308 01FFBC00 007FFF77
GPR16: 00000000 00000001 10050000 00000002 7FFFFF68 10070000 00000001 C3030000
GPR24: C3030000 C3030000 FFFFFFFF 00000000 C3030000 C3030000 C0189318 C302BEC0
NIP [c302b0c4] sys_set_tick_control_register_value+0x8/0x10 [kTickTest]
LR [c302b350] init_module+0xd0/0x10c [kTickTest]
Call trace:
[c0030954] sys_init_module+0x218/0x328
[c0002900] syscall_dotrace_cont+0x24/0x38
Segmentation fault
What is wrong with my code?
Any hints would be appreciated.
Thanks in advance.
^ permalink raw reply
* Re: Newbie question about accessing memory in kernel space
From: Wolfgang Grandegger @ 2005-05-24 20:17 UTC (permalink / raw)
To: niklaus.giger; +Cc: rtai, linuxppc-embedded
In-Reply-To: <200505242119.29197.niklaus.giger@member.fsf.org>
On 05/24/2005 09:19 PM Niklaus Giger wrote:
> Hi
>
> I am working on a custom PPC405 board where I have a 2.6.10 kernel with RTAI
> patches (fusion) running.
>
> I am trying to access some custom CPLD chip hanging at 0x7D000000. In my
> intial board (hcu3_map_io) I added a corresponding io_block_mapping.
>
> I can see the CPLD when I access the address via my Abatron BDI debugger.
>
> In a user space test program I did a
> map_base = mmap((void *)target, nSize, PROT_READ | PROT_WRITE, MAP_SHARED,
> fd, target);
> and was able to access the CPLD, too.
>
> In user and kernel space the procedure looks like this:
> void sys_set_tick_control_register_value(uint16 value)
> {
> static uint16 *tickControlRegister = (uint16*)
> HCU_TICK_CONTROL_REGISTER_ADDRESS;
> *tickControlRegister = value;
> }
>
> Now I compiled a module which tries to access the CPLD during the insmod phase
> and I get the following output.
>
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: C302B0C4 LR: C302B350 SP: C1DABED0 REGS: c1dabe20 TRAP: 0300 Not
> tainted
> MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> DAR: 7D000000, DSISR: 00800000
> TASK = c1d827b0[27] 'insmod' THREAD: c1daa000
> Last syscall: 128
> PLB0: bear= 0x04000004 acr= 0x00000000 besr= 0x00000000
> PLB0 to OPB: bear= 0xef6007ff besr0= 0x00000000 besr1= 0x00000000
>
> GPR00: C302B348 C1DABED0 C1D827B0 0000002B 00000CAC FFFFFFFF C01C0000 00029030
> GPR08: C01CBB30 C3030000 00000000 7D000000 00000000 10075308 01FFBC00 007FFF77
> GPR16: 00000000 00000001 10050000 00000002 7FFFFF68 10070000 00000001 C3030000
> GPR24: C3030000 C3030000 FFFFFFFF 00000000 C3030000 C3030000 C0189318 C302BEC0
> NIP [c302b0c4] sys_set_tick_control_register_value+0x8/0x10 [kTickTest]
> LR [c302b350] init_module+0xd0/0x10c [kTickTest]
> Call trace:
> [c0030954] sys_init_module+0x218/0x328
> [c0002900] syscall_dotrace_cont+0x24/0x38
> Segmentation fault
>
> What is wrong with my code?
If the physical address is not already mapped an ioremap() is required
in kernel space.
> Any hints would be appreciated.
>
> Thanks in advance.
>
> _______________________________________________
> RTAI mailing list
> RTAI@rtai.org
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>
>
^ permalink raw reply
* Re: Newbie question about accessing memory in kernel space
From: Matt Porter @ 2005-05-24 20:31 UTC (permalink / raw)
To: Niklaus Giger; +Cc: rtai, linuxppc-embedded
In-Reply-To: <200505242119.29197.niklaus.giger@member.fsf.org>
On Tue, May 24, 2005 at 09:19:28PM +0200, Niklaus Giger wrote:
> Hi
>
> I am working on a custom PPC405 board where I have a 2.6.10 kernel with RTAI
> patches (fusion) running.
>
> I am trying to access some custom CPLD chip hanging at 0x7D000000. In my
> intial board (hcu3_map_io) I added a corresponding io_block_mapping.
Is a "corresponding" mapping a 1:1 mapping? Don't do that. You cannot
map stuff that way since it is below TASK_SIZE i.e. it's in user address
space, not kernel address space.
> Now I compiled a module which tries to access the CPLD during the insmod phase
> and I get the following output.
>
> Oops: kernel access of bad area, sig: 11 [#1]
<snip>
> What is wrong with my code?
You mapped the device into user virtual address space. The TLB
replacement code is unable to load a TLB entry for a page outside
of kernel space...so you crash.
Don't use io_block_map()...it allows you to shoot yourself in the
foot very easily (as you just witnessed). Use ioremap() to map
your device.
-Matt
^ permalink raw reply
* Re: MMUCR on ppc440 GP/GX
From: Matt Porter @ 2005-05-24 20:38 UTC (permalink / raw)
To: ming lei; +Cc: linuxppc-embedded
In-Reply-To: <20050524183650.16871.qmail@web61017.mail.yahoo.com>
On Tue, May 24, 2005 at 11:36:50AM -0700, ming lei wrote:
>
> what's the latest ppc440 linux code that I can take
> look at?
Grab the current kernel.org 2.6 release. I suggest you use
dirdiff another recent 2.4 kernel and then analyze the 2.6 stuff
as it is different yet. There are countless bug fixes that have
gone in over the last 3 years. I sincerely hope you aren't
trying to use that old kernel with experimental PPC440 support
for production work.
> BTW, what's the problem three years ago prompted to
> change the code regarding mmucr handling?
The problem was that the initial code would crash apps regularly. I
put the code out in our development tree at the time since it was
taking a long time to find the bug...and you could mostly run a
system. The MMUCR was not having the TID set properly during
a tlbie() and a couple other spots in head_440.S.
-Matt
^ permalink raw reply
* Re: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (v3)
From: Benjamin Herrenschmidt @ 2005-05-24 21:48 UTC (permalink / raw)
To: Jon Loeliger
Cc: linuxppc64-dev, Tzachi Perelstein, u-boot-users,
linuxppc-dev list
In-Reply-To: <1116947474.4720.3.camel@cashmere.sps.mot.com>
On Tue, 2005-05-24 at 10:11 -0500, Jon Loeliger wrote:
> On Mon, 2005-05-23 at 23:34, Benjamin Herrenschmidt wrote:
> > Hi !
>
> > David and I are still working on sample code & tools. We have a
> > prototype of a device-tree "compiler" that can build the flattened blob
> > from a textual representation. We'll release that soon, hopefully this
> > week.
>
> Hi Ben,
>
> This is most excellent. In particular, I won't start to
> do just that step too... :-) So, can you put me on the
> beta tester list for those tools? Or are you just going
> to post it all here?
We'll post it all here :)
Ben.
^ permalink raw reply
* Re: MMUCR on ppc440 GP/GX
From: ming lei @ 2005-05-24 22:30 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
Hi Matt,
At your suggestion, I downloaded the latest
linuxppc_2_4_devel source code and also checked the
online code repository, and found this link:
http://ppc.bkbits.net:8080/linuxppc_2_4_devel/diffs/arch/ppc/kernel/head_440.S@1.4?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/kernel|hist/arch/ppc/kernel/head_440.S
which was submitted 4 years ago with comments as "Fix
MMUCR/tlbsx handling and set TS corrently in TLB
entries".
If this is the one you talked about the fix three
years ago, fortunately my ppc440 code already has the
fix, I compared it with latest linuxppc_2_4_devel
source code and it's the same.
I think the problem I have now is different, it's the
icbi call from user space code that caused DataStorage
exception if the corresponding bit in MMUCR is set,
however, ppc440 code doesnt handle it.
Any thought, or correction?
Thanks
Ming
--- Matt Porter <mporter@kernel.crashing.org> wrote:
> On Tue, May 24, 2005 at 11:36:50AM -0700, ming lei
> wrote:
> >
> > what's the latest ppc440 linux code that I can
> take
> > look at?
>
> Grab the current kernel.org 2.6 release. I suggest
> you use
> dirdiff another recent 2.4 kernel and then analyze
> the 2.6 stuff
> as it is different yet. There are countless bug
> fixes that have
> gone in over the last 3 years. I sincerely hope you
> aren't
> trying to use that old kernel with experimental
> PPC440 support
> for production work.
>
> > BTW, what's the problem three years ago prompted
> to
> > change the code regarding mmucr handling?
>
> The problem was that the initial code would crash
> apps regularly. I
> put the code out in our development tree at the time
> since it was
> taking a long time to find the bug...and you could
> mostly run a
> system. The MMUCR was not having the TID set
> properly during
> a tlbie() and a couple other spots in head_440.S.
>
> -Matt
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Newbie question about accessing memory in kernel space
From: Roger Larsson @ 2005-05-24 23:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200505242119.29197.niklaus.giger@member.fsf.org>
On Tuesday 24 May 2005 21.19, Niklaus Giger wrote:
> Hi
>
> I am working on a custom PPC405 board where I have a 2.6.10 kernel with
> RTAI patches (fusion) running.
>
> I am trying to access some custom CPLD chip hanging at 0x7D000000. In my
> intial board (hcu3_map_io) I added a corresponding io_block_mapping.
>
> I can see the CPLD when I access the address via my Abatron BDI debugger.
>
> In a user space test program I did a
> map_base = mmap((void *)target, nSize, PROT_READ | PROT_WRITE,
> MAP_SHARED, fd, target);
> and was able to access the CPLD, too.
Via 'map_base' I guess?
For kernel try
virt_base=ioremap(target, nSize)
>
> In user and kernel space the procedure looks like this:
> void sys_set_tick_control_register_value(uint16 value)
> {
> static uint16 *tickControlRegister = (uint16*)
> HCU_TICK_CONTROL_REGISTER_ADDRESS;
This indicates that you tries to read directly from an adress (no virt_base?)
You might want to use __raw_readl instead (depending on bus endianess).
/RogerL
^ permalink raw reply
* RFC: Deprecating io_block_mapping
From: Benjamin Herrenschmidt @ 2005-05-25 1:30 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev list
As the subject says ... it's the source of endless headaches, is used in
a way that often prevents moving TASK_SIZE freely, etc etc etc...
What are the good and unavoidable uses of it currently that cannot be
replaced by some sort of ioremap ?
(Note that if the answer to the above is: page tables exist too late, I
already have a reply: our initialisations happen too early, let's move
things around so that ioremap is useable... pretty much everything
needed to setup kernel page tables & have working ioremap can be done
without any HW device access so ...)
Ben.
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Kumar Gala @ 2005-05-25 2:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1116984651.6395.60.camel@gaston>
On May 24, 2005, at 8:30 PM, Benjamin Herrenschmidt wrote:
> As the subject says ... it's the source of endless headaches, is used
> in
> a way that often prevents moving TASK_SIZE freely, etc etc etc...
>
> What are the good and unavoidable uses of it currently that cannot be
> replaced by some sort of ioremap ?
Do you propose to fixup ioremap to allocate large page resources (BATs
and CAMs) going forward?
> (Note that if the answer to the above is: page tables exist too late, I
> already have a reply: our initialisations happen too early, let's move
> things around so that ioremap is useable... pretty much everything
> needed to setup kernel page tables & have working ioremap can be done
> without any HW device access so ...)
Do you have any proposed solution for early console access? I'm
guessing that most of the need for early access is for some sort of
console (serial) for early debug output.
Also does this mean we would drop ppc_md.setup_io_mappings() complete?
- kumar
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Benjamin Herrenschmidt @ 2005-05-25 2:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <2d61cb60140e879d0c8d46e7f51a9f56@freescale.com>
On Tue, 2005-05-24 at 21:17 -0500, Kumar Gala wrote:
> On May 24, 2005, at 8:30 PM, Benjamin Herrenschmidt wrote:
>
> > As the subject says ... it's the source of endless headaches, is used
> > in
> > a way that often prevents moving TASK_SIZE freely, etc etc etc...
> >
> > What are the good and unavoidable uses of it currently that cannot be
> > replaced by some sort of ioremap ?
>
> Do you propose to fixup ioremap to allocate large page resources (BATs
> and CAMs) going forward?
Do we really ever need them for anything but RAM mapping ?
> > (Note that if the answer to the above is: page tables exist too late, I
> > already have a reply: our initialisations happen too early, let's move
> > things around so that ioremap is useable... pretty much everything
> > needed to setup kernel page tables & have working ioremap can be done
> > without any HW device access so ...)
>
> Do you have any proposed solution for early console access? I'm
> guessing that most of the need for early access is for some sort of
> console (serial) for early debug output.
How do we implement io_block_mapping() on CPUs without a hash table ? We
need page tables for these so we can have ioremap working. On CPUs with
a hash, we could just shove entries in the hash... though we may need a
mecanism to bolt them or convert those mappings to page tables once
those are available.
> Also does this mean we would drop ppc_md.setup_io_mappings() complete?
Does it really make sense ? I always disliked it.
Ben.
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Kumar Gala @ 2005-05-25 2:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1116987700.6395.64.camel@gaston>
On May 24, 2005, at 9:21 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2005-05-24 at 21:17 -0500, Kumar Gala wrote:
>> On May 24, 2005, at 8:30 PM, Benjamin Herrenschmidt wrote:
>>
>>> As the subject says ... it's the source of endless headaches, is
> used
>>> in
>>> a way that often prevents moving TASK_SIZE freely, etc etc etc...
>>>
>>> What are the good and unavoidable uses of it currently that cannot
> be
>>> replaced by some sort of ioremap ?
>>
>> Do you propose to fixup ioremap to allocate large page resources (BATs
>
>> and CAMs) going forward?
>
> Do we really ever need them for anything but RAM mapping ?
The only case I could thing of are embedded frame buffers across some
bus like PCI. An example would be a image buffer that a printing
application may use.
>>> (Note that if the answer to the above is: page tables exist too
> late, I
>>> already have a reply: our initialisations happen too early, let's
> move
>>> things around so that ioremap is useable... pretty much everything
>>> needed to setup kernel page tables & have working ioremap can be
> done
>>> without any HW device access so ...)
>>
>> Do you have any proposed solution for early console access? I'm
>> guessing that most of the need for early access is for some sort of
>> console (serial) for early debug output.
>
> How do we implement io_block_mapping() on CPUs without a hash table ?
> We
> need page tables for these so we can have ioremap working. On CPUs with
> a hash, we could just shove entries in the hash... though we may need a
> mecanism to bolt them or convert those mappings to page tables once
> those are available.
I know what I've done in the past is either steal a BAT (83xx) or CAM
(85xx) entry and then free it up when a proper ioremap can be done
later.
>> Also does this mean we would drop ppc_md.setup_io_mappings() complete?
>
> Does it really make sense ? I always disliked it.
No, as far as a can tell doing a quick glance if we drop
io_block_mapping than we can drop setup_io_mappings().
- kumar
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Dan Malek @ 2005-05-25 4:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1116984651.6395.60.camel@gaston>
On May 24, 2005, at 9:30 PM, Benjamin Herrenschmidt wrote:
> As the subject says ... it's the source of endless headaches, is used
> in
> a way that often prevents moving TASK_SIZE freely, etc etc etc...
Why are you so obsessed about this? :-) We all know what it does
and the limitations. If someone wants to use it in addition to other
kernel configuration options, their particular start up code will have
to be modified to accept this.
> What are the good and unavoidable uses of it currently that cannot be
> replaced by some sort of ioremap ?
>
> (Note that if the answer to the above is: page tables exist too late,
That's one reason. The other is to pin BATs or large page table entries
for more efficient access.
> .... I
> already have a reply: our initialisations happen too early, let's move
> things around so that ioremap is useable
In most cases you can't do this. There are boards that have to map
serial ports for kgdb or early console debugging. There are also
boards that need access to local hardware registers to set up that
early. You may need to map a rom or some other non-volatile storage
to get some system parameters.
Thanks.
-- Dan
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Dan Malek @ 2005-05-25 4:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <2d61cb60140e879d0c8d46e7f51a9f56@freescale.com>
On May 24, 2005, at 10:17 PM, Kumar Gala wrote:
> Do you propose to fixup ioremap to allocate large page resources (BATs
> and CAMs) going forward?
That would have to be absolutely necessary, plus we need to ensure we
accommodate the processor cores with more or less BATs (or also variable
number of CAMs). We can't afford to continue to work with the least
common
denominator configurations and waste those resources.
Thanks.
-- Dan
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Dan Malek @ 2005-05-25 5:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <362472e35e6672011614c2710183e778@freescale.com>
On May 24, 2005, at 10:30 PM, Kumar Gala wrote:
> I know what I've done in the past is either steal a BAT (83xx) or CAM
> (85xx) entry and then free it up when a proper ioremap can be done
> later.
This is even more of a hack than io_block_mapping() because it is often
obscure and not documented. Several boards have done this in the past
as well. It's "magic" that occurs, what seems to be minor code changes
often cause this to break and makes debugging more complex :-)
> No, as far as a can tell doing a quick glance if we drop
> io_block_mapping than we can drop setup_io_mappings().
We've got to have something to address the board unique requirements
that are currently satisfied by this.
There is a real problem that we have to solve. Some boards just need
access to mapped hardware before the VM is set up. You can't just
remove a feature or tell them their design is wrong. I don't think
obscure
mapping tricks are the solution, either.
The only solution is to make ioremap() smart enough to properly use
BATs and CAMs that are available to a processor. I suspect this is
going
to lead to a bunch of also undesirable configuration options to address
the customizations necessary.
Thanks.
-- Dan
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Dan Malek @ 2005-05-25 5:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1116987700.6395.64.camel@gaston>
On May 24, 2005, at 10:21 PM, Benjamin Herrenschmidt wrote:
> Do we really ever need them for anything but RAM mapping ?
Of course. We use BATs and CAMs to address a variety of
mapping options.
> How do we implement io_block_mapping() on CPUs without a hash table ?
What does a hash table have to do with anything? The io_block_mapping()
is most important on processors that don't have them, like 8xx, 82xx,
83xx,
and 85xx. The hash table in Linux is just an unfortunate staging area
for PTEs.
The io_block_mapping() simply loads BATs, CAMs, or init's page tables.
> ..... We
> need page tables for these so we can have ioremap working.
The problem is you need more than page tables. We have kernel page
tables very early in the initialization. The problem with ioremap() is
if you
haven't done something (like io_block_mapping()) to set up BATs or CAMs,
it will call vmalloc() to get some VM space. This is where the problem
lies.
> ... On CPUs with
> a hash, we could just shove entries in the hash... though we may need a
> mecanism to bolt them or convert those mappings to page tables once
> those are available.
We don't need anything that complicated. As I said, this already works
on
all processors that don't have hash tables.
We need to make ioremap() much, much smarter, plus we need some kind
of board specific function to set up the BATs or CAMs, like
io_block_mapping()
does today.
Thanks.
-- Dan
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Benjamin Herrenschmidt @ 2005-05-25 5:15 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <99151309fed9dc6d9649e5e9a1299d6e@embeddededge.com>
On Wed, 2005-05-25 at 00:45 -0400, Dan Malek wrote:
> On May 24, 2005, at 9:30 PM, Benjamin Herrenschmidt wrote:
>
> > As the subject says ... it's the source of endless headaches, is used
> > in
> > a way that often prevents moving TASK_SIZE freely, etc etc etc...
>
> Why are you so obsessed about this? :-) We all know what it does
> and the limitations. If someone wants to use it in addition to other
> kernel configuration options, their particular start up code will have
> to be modified to accept this.
We don't "all" know :) It's very easily misused...
> > What are the good and unavoidable uses of it currently that cannot be
> > replaced by some sort of ioremap ?
> >
> > (Note that if the answer to the above is: page tables exist too late,
>
> That's one reason. The other is to pin BATs or large page table entries
> for more efficient access.
True.
> > .... I
> > already have a reply: our initialisations happen too early, let's move
> > things around so that ioremap is useable
>
> In most cases you can't do this. There are boards that have to map
> serial ports for kgdb or early console debugging.
How do they map ? pinning TLBs ? ioremap can do that... ioremap can be
made to work very very early ...
> There are also
> boards that need access to local hardware registers to set up that
> early. You may need to map a rom or some other non-volatile storage
> to get some system parameters.
Ok, well, it's really just requesting for comment here, I don't say I
will kill it, just wondering ...
Ben.
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Benjamin Herrenschmidt @ 2005-05-25 5:20 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <4aa09b6017041c7fe43b9138a19d9c65@embeddededge.com>
On Wed, 2005-05-25 at 01:14 -0400, Dan Malek wrote:
> On May 24, 2005, at 10:21 PM, Benjamin Herrenschmidt wrote:
>
> > Do we really ever need them for anything but RAM mapping ?
>
> Of course. We use BATs and CAMs to address a variety of
> mapping options.
>
> > How do we implement io_block_mapping() on CPUs without a hash table ?
>
> What does a hash table have to do with anything? The io_block_mapping()
> is most important on processors that don't have them, like 8xx, 82xx,
> 83xx,
> and 85xx. The hash table in Linux is just an unfortunate staging area
> for PTEs.
Sorry, I meant BATs or equivalent... (see POWER4 for example who has
none of this)
>
> The io_block_mapping() simply loads BATs, CAMs, or init's page tables.
Ok, that was my point... since init page tables can be loaded by it, why
not make ioremap work that early and do the same ? The problem is of
course allocating the pte pages but how does io_block_mapping() do on
CPUS without BAT/CAMs/whatever ?
> > ..... We
> > need page tables for these so we can have ioremap working.
>
> The problem is you need more than page tables. We have kernel page
> tables very early in the initialization.
We have the pgdir, but not the PTE pages...
> The problem with ioremap() is if you
> haven't done something (like io_block_mapping()) to set up BATs or CAMs,
> it will call vmalloc() to get some VM space. This is where the problem
> lies.
No, we have a trick with ioremap_bot, we don't need to get vmalloc space
for ioremap to work early. In fact, it would be nice to just have
io_block_mapping be able to "dynamically" allocate virtual space using
the same mecanism instead of beeing passed a virtual address. That would
fix most of the problems with hard coded 1:1 mappings.
>
> > ... On CPUs with
> > a hash, we could just shove entries in the hash... though we may need a
> > mecanism to bolt them or convert those mappings to page tables once
> > those are available.
>
> We don't need anything that complicated. As I said, this already works
> on
> all processors that don't have hash tables.
>
> We need to make ioremap() much, much smarter, plus we need some kind
> of board specific function to set up the BATs or CAMs, like
> io_block_mapping()
> does today.
Well, my problem is with hard-coded v:p mappings... If we can simply
have io_block_mapping take, for example, 0 for v (or -1) and use the
ioremap_bot trick to "allocate" virtual space, that would make me happy
(it needs to return the allocated address too).
Ben.
^ permalink raw reply
* Re: RFC: Deprecating io_block_mapping
From: Dan Malek @ 2005-05-25 5:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc-embedded
In-Reply-To: <1116998427.6395.86.camel@gaston>
On May 25, 2005, at 1:20 AM, Benjamin Herrenschmidt wrote:
> Ok, that was my point... since init page tables can be loaded by it,
> why
> not make ioremap work that early and do the same ?
Because you lose the efficiency of mapping with BATs or CAMs.
> ... The problem is of
> course allocating the pte pages but how does io_block_mapping() do on
> CPUS without BAT/CAMs/whatever ?
It just loads init's page tables directly.
> We have the pgdir, but not the PTE pages...
The PTE pages are allocated as they are needed. The PTE pages
are there :-)
> No, we have a trick with ioremap_bot, we don't need to get vmalloc
> space
> for ioremap to work early.
That's only if you have already done something to already allocate BATs
or CAMs. On processors that don't have these, ioremap() would fail
because
it would think it has to allocate VM space.
> .... In fact, it would be nice to just have
> io_block_mapping be able to "dynamically" allocate virtual space using
> the same mecanism instead of beeing passed a virtual address. That
> would
> fix most of the problems with hard coded 1:1 mappings.
I think we should make ioremap() smarter and have some board
initialization
that helps it by setting up BATs, CAMs, or unique page table mappings.
There is also an interdependence between ioremap() and other IO
initialization. In the past some of the fixed addressing was necessary
due
to assumptions built into IO setup, mapping functions, or macros. I
don't
know how much of this is still present.
> Well, my problem is with hard-coded v:p mappings... If we can simply
> have io_block_mapping take, for example, 0 for v (or -1) and use the
> ioremap_bot trick to "allocate" virtual space, that would make me happy
> (it needs to return the allocated address too).
Somewhere, at some point, prior to VM setup, we need to forcibly map
virtual to physical addresses. These are going to be "hard coded"
mappings, that's exactly how ioremap_bot is set. This is why
io_block_mapping was created in the first place. Somehow you have
to specify this mapping before you have a VM allocator to give it to
you. :-)
Even if you don't call it io_block_mapping(), you are going to need
a function that does exactly this.
Thanks.
-- Dan
^ 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